The project page was too important and too fragile to touch, until it blocked a contract

The project page is where a translation project lives: files, jobs, analyses (word-count breakdowns used for pricing), and quotes. It's the most-visited page in Phrase's translation management system, opened by about half of all users and viewed millions of times a month.

It's dense, and parts of it are close to money. People come here for one task at a time, like checking a quote or finding the latest job. Beyond the analyses, power users keep hundreds of quotes in a single project. And it ran on legacy code. The design system was only small parts, wrapped by engineers and dropped in.

The trigger: a strategic enterprise client was about to sign, and the page couldn't hold the volume their work needed. The codebase was blocking a contract.

The chicken-and-egg: the code's limits blocked UX improvements, and the page was too important and too risky for anyone to touch the code. Nothing could move first.

The cost of not acting: the rule used to be to make it work and not touch it. But the old technology was hindering how fast we could go, and keeping it running had a cost of its own. Not acting stopped being the safe option.

Why it matters: the page gets millions of views a month, so every second saved per visit adds up to about 770 hours of customer time a month.

The goal was to pay down the technical debt first: move the page off legacy code and onto the design system, so changes to the experience can ship much faster. The quote experience had barely changed in years. People had stopped asking for improvements. They took it for granted and worked around it.

I was the only designer, on top of owning the design system. That meant the whole page: jobs, quotes, analyses, translation memories, term bases and references. The combination was the point: the page had to move onto the design system without breaking how people already work. Research, interaction, and visual design were mine. Engineers owned what sits underneath: APIs, data structure, and the codebase.

The page stacks everything a project needs: jobs, quotes, analyses, translation memories, term bases and references. Each section is a table, and some get very big.

Customers told us the tables were too narrow. The hard question was how to browse a page this long. Full-width sections risk an endless scroll. Tabs or a table of contents are tidier, but they hide content and break habits people have had for years.

1. Boxes2. Side panel3. Full-width tables

Boxes, with only Jobs going full widthChosen

Sections stay as boxes, centered on big screens. Only the jobs table opens to full width, in a focus mode.

I explored three directions for browsing it as Figma prototypes, and gathered feedback across design, engineering, product, customer success and solution architects. We went with the one closest to what's in production: a stack of boxes. The boxes follow the new layout, using as much width as the content needs and no more.

The full-width option lost for a concrete reason: a virtualized table captures the scroll, so getting from Jobs to Quotes meant scrolling through every job. That's why each table now sits in a box, with room beside it.

What changed across the page:

• Wider sections, with an expand toggle that remembers your choice.
• The workflow selector moved out of the jobs table to the top of the page, because it changes every section.
• One table pattern, reused in every section. Rows render only when they're on screen. Each table sits in a box about 90% of the screen high with its own scroll, and leaves room beside it so the page still scrolls. Design it once, and every section gets it, even at tens of thousands of rows.
• Analyses show a meter in the table, with details in a popover when you ask for them.
• References got a real table: previews, bulk actions, sorting and a far higher limit. It's the volume problem behind the blocked contract.
• Translation memories and term bases moved into design-system tables. The assignment flow stays as it is for now.

Most sections moved to the design system as they were, then changed in steps. On the busiest page in the product, breaking everyone's habits at once was the bigger risk.

The page also shows data it doesn't own. It's pulled from elsewhere and drifts at high volume. For translation-memory settings, the accurate interaction was more complex than the simple one. I chose accurate. It shipped first in Project Templates, a related page that reuses the same components. The project page is the wrapper around many components like this one, shared across the product.

The section also adapts to the project, instead of showing every option every time. Pick a setup:

1 language2+ languages

0 workflow steps1+ workflow steps

0 translation memories1+ translation memories

One language and no workflow steps: a single list. There's nothing to batch across, so there's no batch tool.

1. Quotes are the trust breaker.

   When people didn't trust a quote, they left the product: they exported to spreadsheets or quoted in other tools.

   →Led toThe quote got the deepest redesign.

2. People come to verify a number, not to read.

   They use this page as a verification tool, not a reading experience.

   →Led toSummary first, subtotals at every level, links to the source.

3. Users think in jobs.

   It pointed to bringing jobs, analyses and quotes into one view.

   →Led toPrototyped, then left out on purpose ↓

A second goal came out of the research: make quotes clear enough that people check them in Phrase instead of exporting them. It falls out of the new quote view.

What I left out on purpose. "Users think in jobs" pointed to bringing jobs, analyses and quotes into one view. I built that as a more ambitious, vibe-coded prototype and showed it across the team. It was a rework of the whole experience, not a page, and too disruptive to ship. It moved into a separate, longer-term exploration. A better page soon beat a perfect one later.

The old quote view gave every workflow step its own column, so the table grew sideways until it needed horizontal scrolling. Each row stacked word count over price, and only a background color separated a language from its files.

User flow

Checking what one language costs

The old quote showed everything at once. The new one starts with the total and goes one level deeper at a time, only when you ask.

Beforethe old quote, 6 steps

Step 1 of 6

Open the quote

Every language, file and workflow step at once.

Step 2 of 6

Find your language

Only a light blue background tells it apart from its files.

Step 3 of 6

Scroll sideways to the step

Each workflow step is a column, past the edge of the screen.

Step 4 of 6

Read the stacked numbers

Word count over price in every cell, the labels repeated.

Step 5 of 6 · Another page

Cross-check the analysis

By hand. The quote names its sources but doesn't link them.

Step 6 of 6 · Outside Phrase

Export to a spreadsheet

Where people went to trust the number.

Afterthe new quote, 4 steps

Step 1 of 4

Scan the total

The quote's price first, then one row per language.

Step 2 of 4

Open your language

Its own section, because one person usually owns its budget.

Step 3 of 4

Check each step

Steps as rows, one number per cell, adding up to the language total.

Step 4 of 4 · Then the source page

Follow the source

The analysis, price list and net rate link to where the numbers come from.

Six steps and out of the product, or four and back to the source.

6

steps before, ending in a spreadsheet

4

steps after, ending at the source

Before

I turned the table on its side:

• Workflow steps became rows. A long list scrolls naturally. A wide table doesn't.
• Price and word count became columns, one number per cell.
• One section per language pair. One person usually owns a language pair and its budget, so the grouping follows who's responsible for the money.
• Summary first, subtotals at every level, so any number can be checked against its parts.

Every setting that shapes the price, like the net rate scheme, the price list and the analysis, now links to its source. The old page named them but didn't link them, so checking a number meant digging by hand.

Most of the design was done when a reorganization cut design and engineering capacity. Company strategy froze investment in the legacy part of the product, and the project page sat right inside it.

The design was ready. There was no capacity left to build it.

Arguing for more people wasn't going to work. So we changed what the work costs.

The approach was pitched for the project page, then proven across the product. I owned the design side of a two-week UI-debt workshop, with a PM, a product director and two engineers. We shipped 63 fixes against a target of 50, in a median of under a day from ticket to done. An AI coding agent built 60 of them.

AI skills turn design feedback into tickets. An AI agent builds most fixes, then design and engineering review them before they ship. Engineers handle what agents can't yet: APIs, data, and how it fits the codebase. I design with agents on real data, and still use Figma to explore visual variants.

We framed it as maintenance, not polish: moving off legacy code that's expensive to keep alive. That's how a frozen project fit back inside the plan.

That changed what the project page is made of. It used to be legacy code with small design-system parts dropped in. Now it's built design-system-first, with a few one-offs: about 80% design system, up from about 10%. In the seven weeks after the restart, about 60 tickets closed, against 36 in the eight months before. Bugs that waited a median of 50 days during the freeze now close in under a day.

The agent writes code. The engineers who review it and wire it in make it hold.

The restart had to keep moving, on the page every project runs through and where people check what they'll pay. So the release is designed as carefully as the page.

Each piece ships behind a feature toggle, turned on for a few organizations first. Once the page is whole, it's opt-in: early adopters try it and tell us what's off. Then it becomes the default, with a switch back to the old page. If too many issues come up, it goes back to opt-in until they're fixed.

The cost is real: two versions of the busiest page to maintain, until feedback on the new one has been stable for about six months. It's worth it because the old page was too fragile to swap in one go, and a quote people can't trust costs more than a second page to keep alive. Running both means nobody is stuck on a new page that gets their numbers wrong, and every problem reaches us while it's still cheap to fix.

There's no user result yet. Page-level analytics went in before I changed anything, which gives the page as a whole a baseline. The quote-level events below come next. The last two signals come from the rollout itself: if people switch back, or tell us something's wrong, the new page goes back to opt-in until it's fixed.

Time on page is deliberately not on this list. On a page people use to check numbers, less time can mean it works.

Knowing what not to ship. The jobs insight was the most exciting thing the research found, and the hardest to leave out. Leaving it out kept the redesign small enough to restart when capacity came back.

• When you can't get budget for a redesign, make the redesign cheaper than the debt.
• When money is on the screen, accurate beats simple.