Designing a
cloud ecosystem
for tax professionals
The context
Moving a practice,
not a product
A professional software company was moving its tax and accounting products from legacy on-premise software to the cloud. Several products, several teams, three European markets.
The goal was never to port what existed. It was to rethink the experience and build a foundation the company could keep growing on.
Everything a tax professional does in a day, previously spread across separate installations, had to hold together in one place.
02 · The challenge
The hardest thing to move to the cloud was not the software. It was knowing which client you are working on.
On-premise, client context was free. You opened one installation, worked on one client, closed it. The context was the environment. Nobody designed it, nobody thought about it.
In the cloud, a professional moves between clients, firms and tasks continuously and in parallel. Context stops being implicit. It has to be carried, shown, and re-established at every move.
Transferring the on-premise model would have reproduced its limits at scale.
My role
I owned the concept
and the direction
it took
I designed the product concept end to end, working with one mid-level UX designer and alongside designers from the different European regions.
I ran the alignment across Product, Engineering, business and regional stakeholders, which in a transformation this size is not a soft skill. It is the work.
The decisions that were mine: how client context would be modelled, what the concept had to prove before anyone built it, and what the first release would deliberately leave out.
- 01End-to-end product concept, from existing-state mapping to MVP definition
- 02Design direction for how the parts of the product come together in the cloud
- 03Alignment across Product, UX, Engineering and business stakeholders
- 04Concept validation with UK customers and external users
- 05Scope decisions for the first release across three markets
The approach
From complexity
to clarity
Understand the existing complexity
Before designing anything new, we mapped how the existing product actually worked and, more importantly, how users understood it. Workflows, dependencies and market-specific needs, across three regions.
Build the concept
Rather than solving the whole migration at once, I designed an end-to-end concept whose only job was to make the new model make sense: how the parts of the product come together in a cloud environment.
Validate the model, not the screen
We ran concept validation with UK customers and external users. The objective was not to test the interface. It was to find out whether people understood the system and the structure underneath it.
Learn what the model got wrong
Client context was the hardest part of the experience to grasp. Users needed to preserve context while moving across products. The concept had underestimated that, and validation is what told us, before implementation rather than after.
Narrow to an MVP
I narrowed scope to what could be validated in one market first: a dashboard centred on client context, with firm and client filtering. A simpler way to orient yourself inside the new environment.
Scope
What I chose
not to build
The concept explored a broader dashboard with more data, more widgets and advanced insights. Most of it did not ship in the first release, not because it was wrong, but because it could not be validated yet.
The first step
An entry point,
not a destination
The concept was a tool for learning, not the final product. That was the point.
- →Filter by firm and by client, so context is chosen rather than assumed
- →An overview of the work that actually needs attention
- →Quick access to tasks, documents and communication
- →Simple, clear, and possible to act on immediately
Outcome
Validating before
committing
The MVP launched in the UK as the first step in the transition from legacy on-premise software to the new cloud experience, and became the foundation the other markets could build on.
What the project demonstrated was the value of validating a product model before committing to a larger implementation. That let the team reduce complexity and focus the first release around what mattered most to users.
What I took from it
Three things
I kept
Context is a design object
When software changes environment, the things that used to be free, like knowing where you are, become things somebody has to design on purpose.
Validate the model, not the screen
Testing whether people understood the structure told us more than testing whether they could find a button. The finding that changed the direction came from there.
Sequencing is design
Deciding what not to build first, and defending it to three markets at once, did more for the product than any additional feature would have.