Thomson Reuters · 2020

Problem wasn’t the screens.
It was the approach.

A 25 year old product. 6,000 screens. A consultancy rebuilding them one by one. I transformed the approach from redesigning screens to building a system, reducing a team of 12 designers to one.

Context

Why I was invited back

ONESOURCE Global Trade had operated on Gupta Software for 25 years with virtually no front end design. A cloud migration had modernised the infrastructure, but not the user experience.

I was brought back to introduce a scalable design system approach. The challenge was not adding more designers, but changing how design was done.

Before · legacy

  • Gupta software, desktop-only
  • 100% database-driven, no UX layer
  • Cloud via virtual machine only
  • Experience frozen for 25 years

After · redesign

  • 100% web-native application
  • Component-driven design system
  • Dev code-conversion tool built on templates
  • Scalable across 6,000+ screens

Before · legacy

Gupta software, desktop-only

100% database-driven, no UX layer

Cloud via virtual machine only

Experience frozen for 25 years

After · redesign

100% web-native application

Component-driven design system

Dev code-conversion tool built on templates

Scalable across 6,000+ screens

Problem statement

The user’s challenge

Users must validate information, often sourced from SAP, and submit it to the Brazilian government to obtain the required export and import documentation. The legacy system made every step of this process cumbersome, manual, and time consuming.

User journey map

The journey revealed the complexity of preparing Brazilian export and import documentation, with seven stages from Define to Conclude, each loaded with friction, pain points and broken handoffs.

The real challenge

Scale, not screens

When I returned, a 12-person external consultancy was already allocated — rebuilding screens one by one. It looked productive. It wasn’t scalable. With over 6,000 screens in scope, there was no realistic path to completion, and development couldn’t code everything being produced.

1

The impossible brief

12 external designers redesigning 6,000 screens pixel by pixel with no realistic path to completion within the available time or budget.

2

The impossible brief

12 external designers redesigning 6,000 screens pixel by pixel with no realistic path to completion within the available time or budget.

3

The impossible brief

12 external designers redesigning 6,000 screens pixel by pixel with no realistic path to completion within the available time or budget.

4

The impossible brief

12 external designers redesigning 6,000 screens pixel by pixel with no realistic path to completion within the available time or budget.

5

The impossible brief

12 external designers redesigning 6,000 screens pixel by pixel with no realistic path to completion within the available time or budget.

1

The impossible brief

12 external designers redesigning 6,000 screens pixel by pixel with no realistic path to completion within the available time or budget.

2

My intervention: from screens to system

Redirected the entire effort towards components, templates, usage guidelines and documentation, enabling consistency and scalability across the entire product.

3

Building on the existing design system

Created new components on top of Thomson Reuters' DS, with detailed documentation written for designers, business stakeholders, and developers simultaneously.

4

Engineering amplification

The dev team built a legacy-to-web code conversion tool based on my templates — migrating the codebase without manually recoding each interface.

5

Result: the system does the work

Over time, my role shifted to design review. Eventually, I was the only designer left, not because of budget cuts, but because the system had eliminated redundant work entirely.

User flow

Mapping what matters

I worked closely with Product Owners and Product Managers to identify the highest priority modules and workflows. We then mapped the key user flows, starting with the import and export interface module.

The flow diagram defined the decision paths, branching logic, and template types required, giving engineering a clear specification for implementation.

Designing at scale

Components that scale across 6,000 screens

I collaborated with Thomson Reuters’ proprietary design system, adapting existing components and crafting new ones — each documented with usage guidelines, layout specs, interaction rules, and real examples for business, design, and development teams.

High-fidelity prototype

Connected flows, not isolated screens

I created a prototype mapping the entire user journey, allowing the team to validate the workflow and test real tasks before development.

Key flows included the 4 step invoice wizard, bulk item editing and the macro part number system.

Final design

The product in use

The In Out module, one of the most widely used interfaces, manages all planned and processed interface executions integrated with the ONESOURCE Global Trade solution, including data imports and exports, error management, and manual interface configuration.

Outcomes

Impact

I created a prototype mapping the entire user journey, allowing the team to validate the workflow and test real tasks before development.

Key flows included the 4 step invoice wizard, bulk item editing and the macro part number system.

6k+

legacy screens in scope for full redesign

12→1

external designers replaced by a scalable system

87%

reduction in task completion time

25yr

product legacy fully modernized to web-native

40+

new components created and documented

3

teams aligned: business, design & engineering

Reflection

What I learned

The In Out module, one of the most frequently used interfaces, manages all planned and processed executions within the ONESOURCE Global Trade solution. It supports data imports and exports, error management, and manual interface configuration.

Systems over screens

In large legacy products, designing components and templates delivers more value than designing individual flows. The system becomes the product and outlasts any single designer on the team.

Early user involvement

Delivering modules for real users to test in their actual environments surfaced insights that no stakeholder alignment could have anticipated. Always prioritise user interviews over assumptions.

Strategic navigation

Working within an organisation where people had spent decades on the same product required as much strategic thinking as any design challenge. Navigating institutional biases was a design problem in itself.

Design enables engineering

My templates directly enabled the development team to build a legacy to web conversion tool. The design artefacts became part of the engineering infrastructure, which was the clearest sign that the systems approach had worked.

Systems over screens


In large legacy products, designing components and templates delivers more value than designing individual flows. The system becomes the product and outlasts any single designer on the team.

Early user involvement


Delivering modules for real users to test in their actual environments surfaced insights that no stakeholder alignment could have anticipated. Always prioritise user interviews over assumptions.

Strategic navigation

Working within an organisation where people had spent decades on the same product required as much strategic thinking as any design challenge. Navigating institutional biases was a design problem in itself.

Design enables engineering

My templates directly enabled the development team to build a legacy to web conversion tool. The design artefacts became part of the engineering infrastructure, which was the clearest sign that the systems approach had worked.

See the full work

Complete flows, component library, and documentation available in Figma.