Unfreezing the busiest screen in the product

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. Power users have tens of thousands of analyses and hundreds of quotes in a single project. And it ran on legacy code, only about half of it built from our design system.

Why it matters: at this scale, every second saved per visit adds up to hundreds of 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 more than 15 years. People had stopped asking for improvements. They took it for granted and worked around it.

I was the lead and only designer, on top of leading 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.

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 and sorting. The limit went from 50 to 5,000, because a customer needed far more.
• 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, where customers use it today.

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.

I ran 7 interviews and logged 66 observations. Instead of customers, I talked to customer success managers and solution architects, the people customers call when something breaks. Secondhand, yes. But each conversation covered many accounts, not one. I showed them the redesigned quote, to validate it and find blind spots.

The pattern was clear: when people didn't trust a quote, they left the product. They exported the numbers to spreadsheets or quoted in other tools. Quotes had no breakdown, and checking a number meant cross-referencing other pages.

One observation reframed the brief. People use this page as a verification tool, not a reading experience. They come to check a number.

Two findings set the direction. Quotes are the trust breaker set the priority. Users think in jobs was a strong insight, and too big for this project. So the quote became the part of the page I took furthest.

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 exploration, Interstellar. A better page soon beat a perfect one later.

BeforeAfter

Hover or tap the numbers to see what changed

1Scan the totalThe quote's price first, then one row per language.2Open your languageEach language pair is its own section, because one person usually owns its budget.3Check each stepSteps as rows, one number per cell, adding up to the language total.4Follow the sourceThe analysis, price list and net rate link to where the numbers come from.

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.

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.

The numbers on the new view follow how people check a quote: scan the total (1), open your language (2), check each step (3), and follow a link back to the source (4).

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. In a two-week workshop on UI debt, we shipped about 60 fixes against a target of 50, roughly 9 in 10 built by an AI coding agent.

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.

On the project page, closed tickets went from a handful a month to about 25, and the new page is about 80% design system, up from about 50%. Across my work, UI fixes I file now ship in a median of one day.

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

There's no user result yet. The new page is in QA, and no customer has used it. I set up analytics before changing anything, so there's a baseline to measure against.

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.