BrandVue

Built around our data, not the people using it

The problem was never the data. BrandVue holds some of the best brand data Savanta produces. It was the route to it that failed people.

It had been built to mirror how we work internally, all the depth on show from the first screen. That suited the analysts who live in the detail, and even they took months to get comfortable. Everyone else was stranded, asking their account manager what to look at rather than exploring the product they'd bought.

It was also held together by hand. Monthly reports produced manually, insights assembled for clients rather than found by them. If we lost a few key people, we wouldn't really have had a product. For something this central to the business, it added up to one uncomfortable number.

The product assumed knowledge it never taught

The biggest thing we found was an assumption nobody had noticed making. Two problems, tangled together.

• It expected fluency it never taught. Users had to arrive already knowing market research, the funnel, the terminology, what a healthy score even looks like. Miss that hidden bar and you were lost from the first screen. We'd built a tool that quietly required a qualification to use.
• It was built for one user, and there were four. The business recognised the data-savvy analyst who wanted the full toolkit. Research found four types, and the analyst was the minority. The majority wanted a clear answer quickly and the confidence to act on it, without becoming a specialist. We were serving the few and turning away the many, including the clients we'd lost and never won.
• The navigation was 100+ items, and every one was a metric. No workflows, no "I want to do X" routes in, just an exhaustive list of everything the data could show. It mapped the database, not a single job anyone came to do.

Complexity first was backwards

The product led with complexity and asked users to make sense of it themselves. We turned that around. Lead with clarity, and let complexity be there for the people who go looking for it.

The rule I set for the redesign was simple: someone with no data background should be able to pick this up and get value from it. Learnability came first. Not by stripping the product back and losing what made it powerful, but by changing the order in which it revealed itself, and by building in the teaching the old product assumed you didn't need.

That started with navigation. Rather than list every metric, I built the product around workflows drawn straight from the four user types, the actual jobs people came to do. The hundred-plus metrics didn't go anywhere, they just stopped being the way in.

Clarification, not scale back.

The principle behind the redesign

Four themes that set the direction

The research resolved into four patterns, each with a clear implication for the design.

• Fast answers before deep analysis. Even power users wanted immediate value before engaging with depth. Insight had to come before configuration.
• One dashboard, two mental modes. People switch between quick daily checks and deeper strategic work. The product needed to support both without making them switch tools.
• Interpretation builds confidence. Numbers alone didn't feel safe to act on. Every key metric needed a clear "what this tells you".
• Simplicity increases trust. Too much choice damaged credibility. Fewer visible options made the product feel more trustworthy, not less capable.

Three levels, from headline to deep dive

The core of the redesign is a model of clarification in three layers. Each one answers a different depth of question, so a user only goes as deep as they need.

• The metric card. The headline. A number or a small chart, a reference point for whether it's good or bad, and a hint of the trend. Concise by design.
• The story panel. Click any card and a side panel explains what you're looking at in plain language. What is brand love, what a good score looks like, how you compare. This is the teaching layer the old product never had, the interpretation that used to live in an account manager's head.
• The full builder. One more click into the deep view, where an analyst can filter, add comparisons and build on the metric. The complexity is still there, it just isn't the first thing you meet.

The clearest expression of the whole thesis is the headline on every dashboard. The old product said "Look at your brand love" and handed you a complex chart. The new one says it for you.

AI that speeds the work up, without taking the pen

I designed AI's role against the four user types, rather than bolting on one generic assistant. For the analyst it handles analysis at scale, so they spend their time interpreting, not compiling. For the time-poor user it summarises and answers before they have to ask.

Most of it is small, quiet help rather than a chatbot in the corner.

• Plain-language headlines on every dashboard, generated from the data.
• Auto-named dashboards and metrics, so nobody starts at a blank field, and every name can be changed in a click.
• Drafted explanations behind each metric, the "what this tells you" written for you.

Two rules held throughout. Every AI output carries the reasoning behind it, never a number on its own. And the person always keeps the pen, the AI just gives a head start they can override anywhere. Nowhere was that harder to honour than the headline.

The hardest call: a headline you can trust when the news is bad

Letting AI write the headline raised a question I couldn't dodge. When the data is good, easy. But what happens when a client's brand is sliding? Flatter them and the dashboard becomes a liar, and the first time someone catches it, they never trust a headline again. Tell them cold bad news every morning and they stop opening it. Either way, the product loses.

The answer wasn't a cleverer algorithm, it was a principle: truth, but framed well. The headline never goes below the truth to manufacture good news. But brand metrics are always market-relative, and that's the way out. "Falling, but slower than the category" is both genuinely reassuring and completely true. Honest framing almost always meets the client's need without bending anything.

To keep that consistent, the system follows a ladder. It leads with the highest statement that is true, significant, and as positive as the facts honestly allow.

• Growing, ahead of the market. Say it plainly.
• Falling, but less than the market. Reframe to relative strength, "holding firmer than a falling category".
• Stable while the market drops. "Holding position while the market slips."
• Genuinely bad, and significant. Tell the truth plainly. Rare, and the rung that matters most.

That last rung is the whole point. A system willing to deliver bad news when it counts is one you believe the rest of the time. It never reaches for a higher rung than the data earns. That's the difference between a dashboard people trust and one they quietly stop believing.

Reusing one pattern to fix onboarding too

A big part of that 5% was onboarding. Winning a new client meant months of bespoke development to stand up their portal, even though we already held their data.

The dashboard builder we'd designed for users could do this job too. Same pattern, same backend, pointed at a different problem. Instead of hand-building each portal, we could generate it.

The mechanism pairs our data with an LLM. Someone writes one prompt, "Our client is Guinness, they care about standing out in a crowded market and winning younger drinkers", and it proposes a starting dashboard and a plain-language tagline drawn from the data. Automated, but the person always has the final say and can change any of it in a click.

Months of setup became minutes. It also reframes what a client's homepage is for: the client decides what matters most, and everyone at their company opens the product to that same shared view.

Running the room, and growing a designer

This was a genuine 50/50 with a mid-level designer. She's research-strong and started the discovery. I picked it up and ran a stakeholder design day, problem framing, assumptions, crazy 8s and prioritisation, to turn a room that knew the product's complexity intimately into one aligned on simplifying it.

Her growth edge was a common one. She wanted users to make the design decisions for her, worried about getting the complexity wrong. Part of my job was showing her that the designer makes the call from the research, then validates it, rather than handing it to the user. Watching her move into confident, testable design decisions was one of the better parts of the project.

The design system meant close work with marketing, and a real tension to solve. Our brand guidelines are strong, but strong brand rules don't automatically make good product rules. The brand itself was going through its own change at the same time, so I was aligning to a moving target, and pushing back where a branded choice would have cost us accessibility. Getting the product to feel unmistakably ours while staying legible and usable for everyone was a design problem in itself.

Winning over the people with the most to lose

The hardest room was internal. Our stakeholders knew every corner of BrandVue's depth, and they were anxious that simplifying it would strip out what made it valuable. We tested the new approach with them and walked them through the thinking. Once they saw that clarifying the route to the data didn't mean losing the data, the resistance turned into support.

The next test is external, and it's the one I'm most keen to run. We're putting the redesign in front of existing clients and ones we've lost, ahead of an October release. Internal testing already surfaced the problems we're carrying in to fix. Going in, my assumption is that the first two levels, the headline and the story panel, will land with every user type. The open question is level three: how much clarification the deep builder still needs before it's genuinely usable for the less technical users, not just tolerated by them. That's what external validation is there to answer.

What I took from it

• Complexity is where product value goes to hide. The data was never the problem. The route to it was, and that's a design problem, not a data one.
• If your product assumes knowledge, it has to teach it. Expecting users to arrive fluent is a decision, usually an accidental one, and it quietly locks most of them out.
• Design patterns are leverage. The same builder that made the product learnable for users also cut client onboarding from months to minutes. One good pattern, two problems solved.
• A component library is for speed, not identity. We built on Material UI and spent hundreds of hours bending it to feel like our brand. Light-touch use is where it shines; fighting it for brand fidelity cost more than it saved.