Originally written Nov 2025

We were in a stakeholder session with a group of legal professionals from a UK law firm. Fee earners, partners, legal secretaries – people who spent their days moving between Proclaim, Outlook, and several other systems dozens of times an hour. Faris, a fee earner, was talking about a billing approval. Something she did every day.

"It should take a second," she said. "But I have to go to Proclaim for the case details, then Outlook to find the client's email, then SharePoint for the original agreement, and then back to Proclaim to actually approve it. By the time I've gathered everything, I've sometimes forgotten why I started looking."

I'd heard versions of this before. That day, I wrote it down differently: fifteen minutes for a task that should take one second. Not a UX problem. A system fragmentation problem.

What it actually meant

The distinction matters. A UX problem suggests the interface is confusing or inefficient – add clearer labels, reduce clicks, and improve the flow. A system fragmentation problem is different. The interface isn't the issue. The problem is that the information Faris needs is in four different systems, and no single screen shows her all of it.

UX solutions don't fix system fragmentation. Feature additions don't fix it either. The only thing that fixes it is consolidation – bringing the information together so the task can happen in one place.

I went back to the research. Across 110+ legal professionals and a 193-person survey, the same pattern appeared in different words: people weren't slow because the interface was bad. They were slow because they kept having to leave it. That's one finding. But it's not a small one.

How it reshaped everything

The finding changed five things before we built a single screen.

The first was the product's purpose. Action Desk stopped being a feature-rich dashboard and became a consolidation engine. Every widget, every card, every integration had to earn its place by reducing the need to go elsewhere. Features that didn't connect to the 15-minute problem went on a different list.

The second was the card design. If every case card needed to show enough context to act without opening the full view, the minimalist instinct – show less, hide more – was directly at odds with the finding. Cards needed to be denser. Not cluttered, but complete.

The third was integration priority. Outlook, Proclaim, Teams, and the document management system – these weren't nice-to-have additions. They were the findings in product form. The email Faris needed was in Outlook. If CaseMatters Evo hadn't brought it into the case view, we wouldn't have solved the problem.

The fourth was grouping. Fee earners managing forty active matters can't scan a flat, undifferentiated list. The grouping structure – by urgency and by category – was the finding applied to information architecture.

The fifth was what we removed. A toggle that lets users flatten the grouped view had been planned. We removed it. Grouping isn't a preference – it's the product's answer to the 15-minute problem. Making it optional would undermine the reason for building it.

What it killed

The harder discipline was what didn't get built.

The original brief had more ambition: a comprehensive search, embedded AI suggestions across every workflow, and a broader set of widgets covering more of the legal process. None of it touched the 15-minute problem directly. A comprehensive search helps if you know what you're looking for – Faris's problem was that she had to check four systems just to build enough context to know what she needed. An AI suggestion is useful when the information for acting is already visible. It isn't when you still have to go to Outlook to find the email.

The finding gave us a filter. Not "is this a good feature?" but "does this reduce the 15-minute problem?" Most features fail that test. The ones that pass are the ones that actually changed how quickly fee earners could act. Having a filter makes decisions faster. It also makes them lonelier.

What it changed

Most research ends up in a report. The findings get synthesised, presented, discussed – and then the team builds roughly what they were going to build anyway, with slightly more justification. That's not what research is for.

Research is for finding the one thing that should reshape everything else.

Not the list of things users said they wanted. The structural insight underneath the list – the real problem hiding inside the feature requests. Faris didn't ask for a unified case view. She described her day. The translation was the work.

The discipline isn't in the research. It's in the willingness to follow the findings all the way through – to let it kill scope, restructure architecture, and remove features that felt important before the research ran. That's where most designers stop. The finding gets presented. The roadmap stays the same. Finding the north star is the easy part. Navigating by it is harder.

A note on North Stars

Not every research programme produces one. Most produce useful signals scattered across multiple pain points, none dominant enough to reorganise everything around.

When you find one, treat it differently. Not as a finding to present, but as a constraint to enforce. Something every feature proposal has to pass before it makes the roadmap. Something that gives you the standing to say "this doesn't connect" – and be right.

The 15-minute problem did that for CaseMatters Evo. The product is simpler than it might have been, more focused. The fee earner's day is faster. Not fixed – Faris would still recognise friction in the current version, but better in the direction the research pointed. That's the best outcome research can produce.