Andy WilsonWhitespace’s dashboard had already been redesigned once, on assumptions, and users felt they had lost functionality. As Head of Design I pitched a second redesign, ran sessions with brokers and underwriters, and designed it with two designers from my team. Related support tickets dropped by 40%, and only 0.4% of users gave negative feedback.
The first redesign
The dashboard is where brokers and underwriters start their day. It shows the risks they’re working on and what needs their attention.
Before I joined, it had been redesigned once already. That version was built on assumptions and thin user data. Users saw it as a step backwards and felt functionality had been taken away. In reality, most of it was still there. The experience was simply too poor for people to find or use it.
Support tickets told the same story. The business saw the problem as one feature, actions. The ticket volume suggested something far more fundamental was broken.
Making the case
The hardest part of this project came before any design work. Stakeholders only wanted the actions feature improved, and I believed a partial fix would leave us with a third dashboard that still didn’t solve the problem. A modern design also looked very different from what people knew, and different felt risky. Underneath both was a belief that we should already know what our customers want, and that asking them would make us look weak.
It took several attempts each time. I brought stakeholders into the same room with support ticket data, reports, competitor examples and design work. I argued that we were building complex software for our customers, not for ourselves, so assumptions weren’t enough. I also pointed out that competitors with well-designed software and half our functionality would win customers if we couldn’t deliver either.
Alongside the debate, I got involved in smaller projects to show what designing properly the first time looked like, and how it reduced technical debt instead of adding to it. By the time we got agreement, people had seen it work.
Asking our users
I set up feedback groups with brokers and underwriters, the two sides of the market who use the dashboard every day. Our account managers helped bring customers in. We asked about their concerns, their pain points, what they valued and what they wished it did. These were some of the first sessions the business had run with customers in this way.
Filtering was hard to find and too limited. Some of it was genuinely missing, but much of the problem was that people couldn’t find what was already there. Users also had no way to see at a glance what kind of work was waiting for them, or what their colleagues owned. And the layout wasted space: risk names shrank or were cut off, key information was hidden and statuses weren’t clear.
What we changed
| What users told us | What we changed |
|---|---|
| Filtering was hard to find and too limited | Stronger, clearer filtering, more customisation, and a choice of list or grid views |
| Nothing needing action was grouped | Work needing action is grouped by type, so it’s clear what needs attention first |
| No visibility across teams | Users can see what they own, what their team owns, who owns what, and how many items sit in each category |
| Space was poorly used | Risk names no longer shrink or truncate, key information is visible, the hierarchy is fixed and statuses are clear |
We also used the project to introduce a more modern visual language, which later became the starting point for our design system.
The team
Magda, a senior designer, and Dipali, a designer, did much of the design work, exploring concepts and taking them through to detailed design. I refined the requirements with our lead business analyst, ran the customer sessions with our account managers, made the core design decisions, and worked on my own concepts alongside theirs.
I also coached Magda and Dipali through reviewing engineering’s work before release and feeding back design changes. The business hadn’t done that before. Until then, solutions were largely led by engineering.
The outcome
The redesigned dashboard launched to the full user base. Related support tickets fell by 40% compared with the previous dashboard, mostly fewer questions about how to do things and fewer requests for missing functionality. Only 0.4% of users gave negative feedback.
The project also started our design system, made customer research a normal part of how we work, and made design review of engineering work standard before release. It was the point where design stopped being a downstream service.
Looking back, it took longer than it needed to. I spent too long trying to win the argument in big meetings when one-to-one conversations, and customer data earlier on, would have moved faster. Starting the design system sooner, with stronger examples, would have made modern design feel less risky. We also ruled several things out of scope that came back to cause problems later.