One enterprise platform, designed twice: before and after the pause
Contoso ran its project portfolio in India on a legacy tool that people from the CTO down to project managers used to track projects worth millions, including resourcing and budgets. I worked on its replacement twice. The first time it was a regional revamp built on research, tested with 13 stakeholders. Then an executive decision put it on hold. Two months later it came back as a platform for three continents, with a new team, and I was reassigned to design the flows and screens from scratch in seven Scrum sprints. The research from the paused project settled the arguments in the new one. The first launch, in the Americas, was celebrated, and the impact reached the C-suite.
The stage
The tool was where senior people ran their portfolio. A CTO looked at it to see which projects were at risk. A project manager used it every day to update status, people and spend. Both had to trust the same numbers.
That made small details expensive. A missing column, an unclear status or a budget figure in the wrong place was not cosmetic. It changed what a leader decided about a project worth millions.
Act one: India, built on research
The brief was to revamp the legacy tool for the India region.
Before redesigning anything, we tested with 13 different stakeholders to map the user personas. The range was wide, from executives who wanted a view across the portfolio to project managers who lived inside individual projects. The aim was a platform that accounted for every small detail of how each group tracked, monitored and managed work, including resourcing and budgeting.
Act one had a second character. It was led by a solution architect who was not easy to work with, and who kept putting technical functionality ahead of the experience. The question in most reviews was what the system could do, not whether the people using it could find and trust what they needed.
That tension did not resolve in act one.
Intermission: two months on hold
After an executive decision, the project was put on hold. Act one stopped there.
Act two: three continents, built on Scrum
Two months later the project restarted with a much bigger scope. It was no longer a regional revamp. It was to become the platform for three continents. A new team came in, and I was reassigned to it to create the flows and designs from scratch.
The second act ran on a different engine. A 20-member team was appointed to drive it, working in Scrum, with releases planned every three to four weeks across seven sprints. It was far more technical than research-led. There was no time to repeat the discovery work.
The research came back
So I used act one's research as the knowledge base. The personas and pain points mapped with 13 stakeholders told me where the old tool failed people, and they shaped the new flows from the first sprint. Work that had stopped when the project paused became the foundation of the bigger version.
The same tension, now with evidence
The solution architect and I clashed again, on three things:
- How tables should work. Dense tables are the heart of a project management tool. How much to show, and how people scan and act on rows, decided whether the platform felt usable.
- How the dashboards should be built. What a CTO needs to see first is different from what a project manager needs.
- Which features to show. Not every capability the system had deserved space on the screen.
This time I had something act one lacked: what the research said about the people who would use it. Arguments that would have stalled as my view against his moved when they were about what the users needed.
Testing the build myself
Designs and code drift apart fast in short sprints. I did not wait for formal QA. Alongside the design work I tested the live code myself to find bugs, issues and mismatches with the designs, and took them back to the developers.
It was not in my job description. It kept the developers on track and stopped small mismatches from piling up into a release that looked nothing like what was agreed.
Curtain: the Americas launch
- A platform for three continents. A tool first planned for one region became the platform for three continents.
- A first launch in the Americas after seven sprints of releases every three to four weeks.
- Recognition up to the C-suite. The launch was celebrated as a success, and the impact was visible to the C-suite.
- Research that outlived its project. The 13-stakeholder persona work from a paused project became the knowledge base for its larger successor.
My part in a 20-person production
- Owned: the flows and designs for the platform from scratch in act two, and the use of act one's research as the evidence base.
- Influenced: decisions on tables, dashboards and which features to show, through evidence rather than authority.
- Partnered with: the solution architect and the developers, sprint by sprint.
- Did on the side: testing the live build against the designs and reporting mismatches.
Notes for the next production
- Package research as a living document from day one. It saved act two. It would have been easier to use as personas and pain points anyone on the new team could read, not only knowledge I carried.
- Agree how design and architecture settle disagreements before the first review. Evidence worked, but it worked late.
- Make design QA a planned step in every sprint, not something done on the side.
What I still use: no research is wasted if you keep it. Evidence beats seniority in a design argument. And the design that matters is the one in production, so check the build, not only the file.
Want the longer version of this story?
I can walk you through the decisions, the trade-offs and what I would do next.