Redesigned project list
$6M Unlocked by Redesigning Translation Orders
Product Strategy
Acting PM
End-to-End
Stakeholder Alignment
Unbabel is a B2B translation platform for enterprise clients. We acquired two Language Service Providers representing $6M in annual revenue, but these clients couldn't use our platform. They needed services we didn't support: multi-file projects, proofreading, cost estimates, delivery timelines. Without them, internal teams handled requests manually.
I led the redesign of Portal's translation workflow, owning both design and product management.
The outcome: $6M migrated onto the platform, operational costs dropped, and clients gained self-service capabilities.
My role
Sole designer and acting PM, reporting to the Director of Product. I owned discovery, product requirements, design direction, and engineering coordination across multiple phased releases.
Previous design
Previous translation orders list
Order submission
The real problem wasn't features. It was a business tradeoff.
Portal was built for two narrow use cases: translating FAQs and blog articles. The acquired companies brought subtitle translation, instruction manuals, and a need for control over quality, price, and speed that the platform simply didn't offer.
I ran discovery in three phases: auditing the existing app and its usage data, interviewing the operations teams from the acquired companies to learn their processes and client expectations, and analyzing competitor workflows. That surfaced the full gap.
What was missing
Diverse file format support
Multi-file projects
Translation settings per file (i.e. source and target language, quality and formality targets)
Translation services per file (i.e. proofreading, subtitling)
Translation errors reporting
Cost and delivery estimates per project and per file
Project status tracking
Search, filtering and sorting options
But the central decision wasn't about features. The acquired clients were used to white-glove service: account managers customized everything on request, which piled overhead onto operations teams and engineers. Portal had to scale operations, and scale meant less customization for end users. That was the tradeoff, and it was the point of the whole project, not a compromise I backed into. I designed a system that standardized the most common workflows while preserving meaningful control: choosing a translation flow, selecting services per file, reviewing cost before committing. Users gave up free-form customization; in exchange they got something sustainable for both sides.
Designing a new app, not a new feature
The old app's limits compounded: one file per order, no per-language translation flow, no added services like proofreading, no cost or delivery estimates, no search once a project was submitted, and no way to view translations without downloading files. The new system answered each: users add multiple files to a project, set translation flows and target languages per file, add services, and review cost and delivery estimates before submitting. I introduced search and filtering to make projects findable, and once a project completes, users view original and translated text in the app, report issues inline, and see quality scores.
The hardest part was designing for several technical realities at once. Services were migrating onto our systems one by one, so I mapped the full flow before touching UI, which unblocked engineering discussions and showed where we could phase functionality. In practice I often built two versions of the same screen: one for the immediate release, one for the future state.
The estimates experience was the most complex piece of this system, and the most consequential. I cover it on its own in "92% task success on a new estimates experience."
Redesigned project creation
Add content
Select translation settings
Select source and target languages
Add services per file
What changed
The redesigned app let $6M in revenue flow through Portal. Clients who had relied on manual handling could now self-serve, operational costs dropped, and the platform could scale.
After the full release I ran usability tests and gathered feedback from Account Managers and support teams. I identified 20 improvements, designed them, and shipped them to production in under a month.
Redesigned Projects page
Projects list
Project orders, the files within the project
Order detail
Translation detail
Reflection
The principle I took from this still holds: design decisions are business decisions, and the tension between customization and scale wasn't a problem to smooth over, it was the work.
What I'd change is how I measured success, because migrating all $6M onto the platform only proves the project happened, not that it worked, and this was as much about running a leaner operation as it was about usability. I would track retention, the number of projects and translations requested, the services added per project and the time to complete a task, and above all the time the operations and support teams got back once clients could self-serve instead of routing every request through them by hand, which was the whole business case and the one number I never instrumented before I left Unbabel.
On top of all this I was managing the design team through the same period, and the honest takeaway is about capacity: owning the IC design, the product decisions and people management at once was more than one role should carry on a project this critical, and I'd push for a dedicated PM or added a second designer next time rather than absorbing all three myself.
Redesigned project list
$6M Unlocked by Redesigning Translation Orders
Product Strategy
Acting PM
End-to-End
Stakeholder Alignment
Unbabel is a B2B translation platform for enterprise clients. We acquired two Language Service Providers representing $6M in annual revenue, but these clients couldn't use our platform. They needed services we didn't support: multi-file projects, proofreading, cost estimates, delivery timelines. Without them, internal teams handled requests manually.
I led the redesign of Portal's translation workflow, owning both design and product management.
The outcome: $6M migrated onto the platform, operational costs dropped, and clients gained self-service capabilities.
My role
Sole designer and acting PM, reporting to the Director of Product. I owned discovery, product requirements, design direction, and engineering coordination across multiple phased releases.
Previous design
Previous translation orders list
Order submission
The real problem wasn't features. It was a business tradeoff.
Portal was built for two narrow use cases: translating FAQs and blog articles. The acquired companies brought subtitle translation, instruction manuals, and a need for control over quality, price, and speed that the platform simply didn't offer.
I ran discovery in three phases: auditing the existing app and its usage data, interviewing the operations teams from the acquired companies to learn their processes and client expectations, and analyzing competitor workflows. That surfaced the full gap.
What was missing
Diverse file format support
Multi-file projects
Translation settings per file (i.e. source and target language, quality and formality targets)
Translation services per file (i.e. proofreading, subtitling)
Translation errors reporting
Cost and delivery estimates per project and per file
Project status tracking
Search, filtering and sorting options
But the central decision wasn't about features. The acquired clients were used to white-glove service: account managers customized everything on request, which piled overhead onto operations teams and engineers. Portal had to scale operations, and scale meant less customization for end users. That was the tradeoff, and it was the point of the whole project, not a compromise I backed into. I designed a system that standardized the most common workflows while preserving meaningful control: choosing a translation flow, selecting services per file, reviewing cost before committing. Users gave up free-form customization; in exchange they got something sustainable for both sides.
Designing a new app, not a new feature
The old app's limits compounded: one file per order, no per-language translation flow, no added services like proofreading, no cost or delivery estimates, no search once a project was submitted, and no way to view translations without downloading files. The new system answered each: users add multiple files to a project, set translation flows and target languages per file, add services, and review cost and delivery estimates before submitting. I introduced search and filtering to make projects findable, and once a project completes, users view original and translated text in the app, report issues inline, and see quality scores.
The hardest part was designing for several technical realities at once. Services were migrating onto our systems one by one, so I mapped the full flow before touching UI, which unblocked engineering discussions and showed where we could phase functionality. In practice I often built two versions of the same screen: one for the immediate release, one for the future state.
The estimates experience was the most complex piece of this system, and the most consequential. I cover it on its own in "92% task success on a new estimates experience."
What I shipped
Multi-file projects
Multiple services per file
Cost estimates per project, file and language
Project delivery estimate
Search and filtering made projects easier to find and track
Side-by-side of the original text and translation for faster issue reporting and quality assessment
Redesigned project creation
Scroll horizontally to see all screenshots
Add content
Select translation settings
Select source and target languages
Add services per file
What changed
The redesigned app let $6M in revenue flow through Portal. Clients who had relied on manual handling could now self-serve, operational costs dropped, and the platform could scale.
After the full release I ran usability tests and gathered feedback from Account Managers and support teams. I identified 20 improvements, designed them, and shipped them to production in under a month.
Redesigned Projects page
Scroll horizontally to see all screenshots
Projects list
Project orders, the files within the project
Order detail
Translation detail
Reflection
The principle I took from this still holds: design decisions are business decisions, and the tension between customization and scale wasn't a problem to smooth over, it was the work.
What I'd change is how I measured success, because migrating all $6M onto the platform only proves the project happened, not that it worked, and this was as much about running a leaner operation as it was about usability. I would track retention, the number of projects and translations requested, the services added per project and the time to complete a task, and above all the time the operations and support teams got back once clients could self-serve instead of routing every request through them by hand, which was the whole business case and the one number I never instrumented before I left Unbabel.
On top of all this I was managing the design team through the same period, and the honest takeaway is about capacity: owning the IC design, the product decisions and people management at once was more than one role should carry on a project this critical, and I'd push for a dedicated PM or added a second designer next time rather than absorbing all three myself.
Redesigned project list
$6M Unlocked by Redesigning Translation Orders
Product Strategy
Acting PM
0-to-1 Product Design
Stakeholder Alignment
Unbabel is a B2B translation platform for enterprise clients. We acquired two Language Service Providers representing $6M in annual revenue, but these clients couldn't use our platform. They needed services we didn't support: multi-file projects, proofreading, cost estimates, delivery timelines. Without them, internal teams handled requests manually.
I led the redesign of Portal's translation workflow, owning both design and product management.
The outcome: $6M migrated onto the platform, operational costs dropped, and clients gained self-service capabilities.
My role
Sole designer and acting PM, reporting to the Director of Product. I owned discovery, product requirements, design direction, and engineering coordination across multiple phased releases.
Previous design
Previous translation orders list
Order submission
The real problem wasn't features. It was a business tradeoff.
Portal was built for two narrow use cases: translating FAQs and blog articles. The acquired companies brought subtitle translation, instruction manuals, and a need for control over quality, price, and speed that the platform simply didn't offer.
I ran discovery in three phases: auditing the existing app and its usage data, interviewing the operations teams from the acquired companies to learn their processes and client expectations, and analyzing competitor workflows. That surfaced the full gap.
What was missing
Diverse file format support
Multi-file projects
Translation settings per file (i.e. source and target language, quality and formality targets)
Translation services per file (i.e. proofreading, subtitling)
Translation errors reporting
Cost and delivery estimates per project and per file
Project status tracking
Search, filtering and sorting options
But the central decision wasn't about features. The acquired clients were used to white-glove service: account managers customized everything on request, which piled overhead onto operations teams and engineers. Portal had to scale operations, and scale meant less customization for end users. That was the tradeoff, and it was the point of the whole project, not a compromise I backed into. I designed a system that standardized the most common workflows while preserving meaningful control: choosing a translation flow, selecting services per file, reviewing cost before committing. Users gave up free-form customization; in exchange they got something sustainable for both sides.
Designing a new app, not a new feature
The old app's limits compounded: one file per order, no per-language translation flow, no added services like proofreading, no cost or delivery estimates, no search once a project was submitted, and no way to view translations without downloading files. The new system answered each: users add multiple files to a project, set translation flows and target languages per file, add services, and review cost and delivery estimates before submitting. I introduced search and filtering to make projects findable, and once a project completes, users view original and translated text in the app, report issues inline, and see quality scores.
The hardest part was designing for several technical realities at once. Services were migrating onto our systems one by one, so I mapped the full flow before touching UI, which unblocked engineering discussions and showed where we could phase functionality. In practice I often built two versions of the same screen: one for the immediate release, one for the future state.
The estimates experience was the most complex piece of this system, and the most consequential. I cover it on its own in "92% task success on a new estimates experience."
What I shipped
Multi-file projects
Multiple services per file
Cost estimates per project, file and language
Project delivery estimate
Search and filtering made projects easier to find and track
Side-by-side of the original text and translation for faster issue reporting and quality assessment
Redesigned project creation
Add content
Select translation settings
Select source and target languages
Add services per file
What changed
The redesigned app let $6M in revenue flow through Portal. Clients who had relied on manual handling could now self-serve, operational costs dropped, and the platform could scale.
After the full release I ran usability tests and gathered feedback from Account Managers and support teams. I identified 20 improvements, designed them, and shipped them to production in under a month.
Redesigned Projects page
Projects list
Project orders, the files within the project
Order detail
Translation detail
Reflection
The principle I took from this still holds: design decisions are business decisions, and the tension between customization and scale wasn't a problem to smooth over, it was the work.
What I'd change is how I measured success, because migrating all $6M onto the platform only proves the project happened, not that it worked, and this was as much about running a leaner operation as it was about usability. I would track retention, the number of projects and translations requested, the services added per project and the time to complete a task, and above all the time the operations and support teams got back once clients could self-serve instead of routing every request through them by hand, which was the whole business case and the one number I never instrumented before I left Unbabel.
On top of all this I was managing the design team through the same period, and the honest takeaway is about capacity: owning the IC design, the product decisions and people management at once was more than one role should carry on a project this critical, and I'd push for a dedicated PM or added a second designer next time rather than absorbing all three myself.