I left Clinia before a lot of my work shipped and, given that I was working on complex products in the health-tech space, there’s a lot I can’t share until/if it goes public. This case study is gonna be pretty vague.
Search is often reduced to a field, a button, and a list of results.
But underneath that simple interaction is a surprisingly complex set of problems. People rarely know exactly how to phrase what they want. They refine their intent as they go. They change their minds. They search for one thing, realise they’re kinda shit at knowing what to search for, then refine until they get what they need.
Health-grade search was a core offering at Clinia, and it boiled down to treating search as a conversation. A very niche, jargon-loaded, academic conversation—about things like hemoglobin or comorbidities or fuckin’ angioplasty—but a conversation nonetheless.
You have all these weird, institutional terms and phrases to navigate. Seemingly every practice, practitioner and patient has a different word for the same thing (medical codes are an absolute clusterfuck of attempted standardisation for anyone interested in a blazing headache with their morning coffee), and when you’re limited to giving an extremely complex system exactly what it needs to produce a desired output, you’re always going to be fucked.
A big part of my role was helping define what a modern search experience should feel like when the underlying system is capable of understanding more than a simple keyword match.
Clinia offered semantic search across health data. A very technical solution to a really gnarly problem space. Instead of ‘good luck guessing what keyword this particular system needs to hear to give you this particular information’, an ever-groing corpus allowed folks to ask natural language, cross-discipline questions and get reliable results.
One of the central design challenges was balancing this system complexity and perceived intelligence with user control and a more seamless experience, without treating it as some absolute wasteman Dr. Chatbot UI that was depressingly common in the health tech space at the time.
The more a search system can infer, rank, recommend, and personalise, the more important it becomes to help people understand what’s happening. If a result is relevant, users should be able to trust it. If it isn’t, they should have a clear path to course-correct.
This meant that we had to design around search as a complete journey unto itself. For the most part, search was the product, we weren’t slapping an Algolia front-end on top of a medical database and calling it done, we were building a search–instigated user journey from the ground up.
The goal was to make search feel less like issuing a command and more like having a productive conversation (again, I must stress, not a fucking chatbot) with a system that could help you get somewhere useful.
I explored a wide range of ways for people to express intent, comprehend results, and progressively refine searches. Every search experience is slightly different. Some people are looking for factual answers, some for credible sources and deep dives, others simply for whatever magic, imaginary code their specific system has for ‘this patient is very fucking dizzy’.
This led to search results essentially being a fluid UI of different resources and stateful ‘widgets’. The more someone refined a query, the more their results would shift and adapt to meet that inferred intent. Which sounds really cool, and it was, but we also had to find some semblance of consistency and predictability in all this fluidity.
Clinia’s search product needed to work across different contexts rather than forcing every user into the same linear ‘ask question; get results’ workflow.
That created an interesting design tension. The system needed enough flexibility to support different content models, visual languages, and business needs, while still providing a coherent set of patterns and behaviours.
I worked on the foundations behind those experiences: the components, states, interaction models, and principles that could be adapted without being reinvented every time.
This was less about creating a single perfect search interface and more about defining the building blocks for many good ones.
Search experiences are often designed around the happy path: someone types a query, finds a result, and moves on.
In reality, some of the most important moments happen when that doesn’t work.
The query might be too broad. The wording might be ambiguous. There might not be an exact match. The result set might be technically relevant but practically useless.
I spent a lot of time thinking about these moments and how the product could respond constructively.
An empty state shouldn’t be a dead end. A poor result shouldn’t require a complete restart. A refinement shouldn’t erase the context that helped someone get there.
These states became opportunities to guide people toward a better search rather than simply reporting that the system had failed.
As Principal Product Designer, I worked across the full range of the product design process.
That meant helping shape the product direction, exploring fundamental interaction models, prototyping complex flows, working through detailed states, and collaborating closely with engineering and product.
A lot of the work involved making invisible decisions visible.
What should the system handle automatically? What needs to be exposed to the user? Which behaviours should be configurable? Where does flexibility help, and where does it create unnecessary complexity?
Designing at this level often meant moving back and forth between the big picture and the smallest interaction detail. A strategy only becomes real when it survives contact with the interface.
I helped built the Clinia design system from scratch, working with some of the most fabulous front-end folks I’ve had the privilege of collaborating with.
As Clinia evolved to further product lines, both code-based and ‘traditional’ product-led launches, we switched to a multimodal approach to design. Building out different designed models on top of the same system model allowed us to ship persona-specific experiences and build out engaging demos on top of highly technical foundations.
This culminated in a shift away from an imperative design system based on components, screens and patterns, and towards a declarative UI system based on a registry/manifest model. This allowed us to explain chunks of UI (or entire screens) as structured data, allowing for adaptive, themable and modular interfaces, all powered by a design system that we maintained complete control over.
The most interesting product design work is often the work you can’t immediately see.
At Clinia, that meant designing the relationship between intent and interpretation, between system intelligence and user control, and between a flexible platform and a coherent experience.
The final product isn’t public yet, so I can’t show the screens or talk about the outcomes in detail. But the work was fundamentally about making a complex system feel simple without making it simplistic.
That’s still one of my favourite design problems: taking something powerful, abstracting away the parts people shouldn’t have to think about, and preserving the parts that make the system genuinely useful.
I spent the tail–end of my time at Clinia designing some really quite innovate solutions around multimodal, agentic ecosystems. I’m not looking for a role that goes that deep into AI weirdness any time soon. If you’re checking Clinia out you’re going to see a tonne of ‘agentic’-ness in their materials. Please don’t ask me to do this work for you.