01 · The situation
A UI service desk attached to thirteen products.
Design at Mitratech ran as a UI delivery function. Work arrived already specified, late enough that the only remaining question was what it should look like. The GRC business unit, a ~$100M ARR portfolio of 13 enterprise products, had no design practice of its own at all. Each product had evolved independently, so the same task looked and behaved differently depending on which product you were in.
Four problems sat underneath that, and they compounded. Design was reactive rather than definitional. There was no structured research capability and no governance over what counted as an insight. Customer signal was scattered across support tickets, sales calls and feedback tools. And there were no shared standards, so every screen was a negotiation.
In consumer software that produces a mediocre experience. In GRC, where users are making audit and compliance decisions with legal consequences, it means teams shipping on assumption in exactly the place assumption is most expensive.
02 · What I took on, and what I left alone
Build the system, not the backlog.
The obvious move was to fix the worst screens. There were plenty, and fixing them would have been visible and popular. I did not do that, because a design function that proves its value by clearing a queue is a function that will be measured on queue throughput forever.
Took on
- A research capabilityThe thing the unit had never had, and the only way to stop shipping on assumption.
- People and ownershipHiring, levelling, and giving each designer real product ownership rather than tickets from me.
- Shared standardsSo that the same problem stopped being re-solved from scratch in every product.
Deliberately left alone
- The backlog of broken screensFixing them first would have been visible, popular, and would have locked design into a service role permanently.
- Visual consistency across all 13 productsWorth doing, but it needed a system with a real distribution mechanism, which came later.
- Enforcing the new processMandates create compliance, not adoption. See section 05.
03 · How I got to the truth
Four sources, because one lies.
I did not want a diagnosis built from stakeholder opinion alone, which tends to describe the loudest problem rather than the biggest one. So the picture came from four directions, and the problems I acted on were the ones that showed up in more than one.
Inside the business
Outside the building
What it produced
Stakeholders described bottlenecks. Audits showed fragmentation. Workflow exposure showed the workarounds people had quietly built. Customer signal showed which of those recurred at scale.
04 · The call
Systems for people, process and tools.
Four decisions, in the order I made them. Each one was chosen because it would still be working after I stopped pushing it.
- Decision
- Move design upstream, into discovery.
- Because
- A team that joins after the problem is defined can only improve the execution of someone else's decision. Product, engineering and design needed to be arguing about the user problem, not the mockup.
- Rejected
- Staying downstream and getting faster at it, which would have raised throughput and changed nothing.
- Cost
- Slower visible output at first. Discovery work does not produce screens anyone can point at.
- Decision
- Build one repeatable research framework, not per project research.
- Because
- Contextual inquiry, workflow analysis and a standard way to capture insight, so findings from one product are usable by another instead of dying in a deck.
- Rejected
- Commissioning research per project, which is faster to start and produces nothing cumulative.
- Cost
- Standardisation costs some fidelity. A framework fits most questions well and a few questions badly.
- Decision
- Hire to product ownership, not to capacity.
- Because
- Five designers each owning products scales. Five designers taking work from one manager does not, and it makes me the bottleneck I was hired to remove.
- Rejected
- A pooled team assigned per sprint, which is easier to staff and produces no depth in any product.
- Cost
- Ownership means slower ramp and real coaching. It also means thirteen products and five owners, so coverage is uneven by design.
- Decision
- Put AI in the workflow, then cut what does not hold up.
- Because
- Research, ideation and delivery all had steps that were slow for mechanical reasons rather than thinking reasons. BotDojo came out of this, unifying customer signal that was scattered across four tools.
- Rejected
- Adopting tools because they were new. Judgment stays with people, and a tool that cannot show its working gets removed.
- Cost
- Training and a real risk of over trusting output. Both need active management rather than a policy.
05 · The hard tradeoff
Adoption by pull, not mandate.
I could have had the new process mandated. Leadership support was there, and a mandate would have produced compliance inside a quarter. I chose to make the new way easier than the old way instead, and let teams switch because switching was better.
That is slower, and it is genuinely riskier: voluntary adoption can simply not happen, and then you have spent a year on a system nobody uses. The reason I took it is that a mandated process survives exactly as long as the person enforcing it, and I was building something that had to outlast my attention.
| Option | Speed to adopt | What happens when I stop pushing | Risk | Call |
|---|---|---|---|---|
| Mandate the process | Fast, one quarter | Reverts. Compliance was never belief. | Low short term, high long term | Rejected |
| Make it easier than the old way | Slow, incremental per team | Holds. Teams kept it because it was better. | Real risk of never being adopted at all | Chosen |
06 · What it took to land it
Incremental, inside existing workflows.
Nothing was rolled out as a programme. The research framework and the standards went into workflows teams already ran, so adopting them did not require anyone to schedule adoption. AI tooling shipped with training and explicit use cases, so designers were both enabled and accountable for what they produced with it.
With leadership, the argument was never about design quality. It was about business outcomes, backed by early wins small enough to ship quickly and concrete enough to point at. Design proposals framed in strategic terms got funded. The same proposals framed in craft terms did not.
The thing that actually drove adoption was self service. Once insight was accessible without going through a person, using the new system stopped being a favour to the design team and started being the path of least resistance.
07 · Where it landed
What is proven, and what is not.
Measured
1 to 5
Designers, each owning products in the portfolio
Headcount. The one number here that needs no method.
2 wks to 4 days
Design cycle time, a 60% reduction
Internal figure from the GRC design function.
3 wks to 1.5
Research cycle time, a 50% reduction
Internal figure from the GRC design function.
Observed
Design is in the room when problems are defined rather than after. The request that arrives now is a problem to solve, not a screen to draw.
Research is self serve. Teams retrieve customer signal without waiting on the design function, which is what stopped the same understanding being rebuilt every quarter.
Consistency across the 13 products improved, though the systematic fix for that arrived later with the design system.
Too early to claim
Whether the practice holds without me. Adoption by pull rather than mandate was chosen precisely so that it would, and that is a claim only time settles.
Whether five designers is the right shape for thirteen products, or whether the coverage model needs to change again as the portfolio moves.