Public sector sales
High stakes public sector work should not feel like enterprise software.
GovTech
Platform Design
Role
Product Designer
Timeline
4 weeks
team
Individual Contributor
platform
Web
The Real Problem
Selling into the public sector is slow, procedural and unforgiving. Budgets are published months ahead, decisions are made in meetings that are a matter of public record, and the person with the authority to sign is rarely the person you first spoke to.
There is an enormous amount of signal in all of that. There is also far too much of it for anyone to read.
The platform had to carry genuinely sophisticated work, mapping institutions, budgets, meeting activity and the people attached to them, while being usable by someone who sells for a living and has no interest in learning a data tool.
What sellers kept saying came down to three things:
"I know the information exists. I do not know where it is or whether it is current."
"By the time I understand the account, the window has moved."
"Every tool I have gives me more to read, not more to do."
Complexity was not the problem to remove. It was the problem to hide until the moment it becomes useful.
Finding the Fix
I mapped what a seller actually needs to do at each stage, from identifying an institution worth pursuing, through understanding its buying context, to reaching the person who can act.
Three core problems emerged:
Everything arrived at once.
The platform could surface budgets, meetings, people and history simultaneously, which left the user deciding what to read rather than what to do.
The sophisticated parts were the least explained.
Where the platform inferred something, it showed the conclusion without the reasoning, which is exactly the moment a commercial user stops trusting it.
There was no obvious next step.
Users could learn a great deal about an account and still close the tab without doing anything.
Based on those insights, I focused on three solutions:
Progressive disclosure by stage.
Each step of the workflow shows only what that step needs. Depth is available, but it is never the first thing on screen.
Reasoning shown alongside the result.
Where the platform draws a conclusion, the interface shows what it drew it from. Credibility is a design problem before it is a data problem.
A single dominant next action.
Every account view resolves to one clear thing to do, with alternatives available but visually subordinate.
The goal was to make a complex platform feel simple without making it shallow.
What Actually Happened
The first structure followed the data model, which meant institutions, budgets, meetings and contacts each got their own equal area. It was logical and it made every session start with navigation instead of work.
I restructured around the seller's sequence rather than the data's shape. The account became the container, and everything else became context inside it.
Density was the second fight. Early account views showed everything known about an institution, on the theory that more context is better. In testing it read as homework. I cut the default view down to what changes a decision and moved the rest behind a deliberate action.
The recommendation surfaces went through the most revision. The first version simply asserted priority. It tested badly, not because users disagreed with the ranking, but because they had no way to argue with it. Adding the basis for each recommendation, in plain language, did more for adoption than any amount of visual work.
I also documented the system as I went rather than at the end. A four colour core palette, a six step type scale with tracking and line height specified, and a component library the team could keep building on. That decision cost time in week one and saved it every week after.
What Changed
The platform ended up carrying high stakes public sector workflows without feeling like enterprise software:
A workflow the user moves through rather than a dataset they browse
Recommendations that explain themselves at the point of use
One clear next action on every account, with depth available on request
A documented design system covering palette, type and components
The shift was from a platform that showed a seller everything it knew to one that told them what to do about it. I owned the strategy, the design and the system documentation; the business results belong to the team who took it to market.
What I Had to Work With
The engagement began with product strategy rather than screens, which is unusual and turned out to be the reason the rest of it worked.
That framing set the constraints:
The domain was genuinely complex and could not be simplified away. Public sector buying really does involve budget cycles, committees and procurement rules.
The audience was commercial, not analytical. Sellers work in short sessions between meetings.
Trust in the underlying data mattered as much as the interface. A recommendation nobody believes is worse than no recommendation.
The product was early enough that the interface would keep changing, so anything I designed had to be a system rather than a set of screens.
I had access to the product thinking and the domain, but not to a body of existing usage data, since much of the platform did not exist yet. The work relied on mapping the seller's real workflow first and designing against that, rather than designing against a feature list.
What I'd Do Differently
I would get the recommendation surfaces in front of working sellers earlier. That was the part where my instincts were most confidently wrong, and it was the part that mattered most.
I would also extend the system to cover:
Team level views, since public sector accounts are rarely worked by one person
Longitudinal tracking, so a user can see how an account's buying context moved over a quarter
Explicit confidence framing, so a weak signal is visibly weak rather than quietly presented as fact
What I Learned
Strategy before interface changes what gets built.
Starting with the workflow rather than the feature list is the difference between organising a product and designing one.
Explaining a conclusion is part of delivering it.
In a domain where the user is accountable for the decision, an unexplained recommendation is not a shortcut. It is a thing they have to go and verify anyway.
Document the system while you build it.
A palette and a type scale written down in week two are a system. The same information reconstructed in month six is archaeology.