Building Design Maturity at X-on Health
When I joined X-on Health, there was no established design practice - interaction decisions were made ad hoc, whichever product manager or developer touched a feature last. This left the product with no shared visual or interaction language, and no design authority to define one.
Act One: Proving the model
I started with Photo Request - where patients send images of their condition to support triage - and used it to define a unifying interaction model rather than a one-off fix. From there, I rolled the model out to the product's core features and windows: calls, voicemails, and forms, each of which had evolved independently and forced users to re-learn interaction patterns depending on what they were viewing, in a high-pressure clinical environment where that friction has real cost. With no tracking infrastructure in place, validation was qualitative - design reviews with pilot users and stakeholders at each stage. Every subsequent feature adopted the model without requiring further design advocacy.
Act Two: Scaling it into a system
As my team grew beyond just me, keeping decisions consistent needed more than one person's judgment holding it together. I built a design system - starting with foundational elements, then expanding it as development requested confirmed, reusable components for new features. The clearest example is the patient block, a component representing a patient across the product. Before the system, it carried inconsistent styles and meaning depending on where it appeared - I standardised it through direct discussion with stakeholders on what it needed to communicate, not just how it should look.
Where it stands now
The system is now standard across the flagship desktop product, extending gradually to web consoles, and has become the foundation for a full UI modernisation now in build.
