What is UI/UX design for health technology?
UI/UX design for health technology is the discipline of designing and engineering interfaces that communicate clinical or health data accurately, support clinical workflows reliably, and meet the accessibility and regulatory expectations of the healthcare environment. Unlike consumer product design, health technology UX cannot prioritise engagement or conversion at the expense of accuracy. A clinical dashboard that makes data easier to misinterpret — through ambiguous labelling, misleading aggregation, or poorly designed error states — is a patient safety issue, not a usability issue. Health technology interface design starts from a precise understanding of the data being displayed, the clinical context in which it is used, and the decisions the user will make based on it. Devsort designs and implements interfaces as part of integrated wearable and clinical software product development, with particular experience in clinical data visualisation and device companion apps.
How does health technology UX differ from consumer product design?
Consumer product design optimises the path to a desired user action — a purchase, a subscription, an engagement metric. Health technology design optimises for decision support: giving the user the right information, in the right format, with the right level of confidence context, so they can make a correct clinical or operational decision. These are different design objectives and they produce different design outcomes.
The most common failure mode in clinical interface design is data presentation that is technically correct but clinically misleading. An accelerometer score displayed without its confidence interval, a trend chart without its missing-data gaps marked, a patient status flag without its last-updated timestamp — each of these is a design error with potential clinical consequences. Good health technology UX requires the designer to understand the data model well enough to know what information is essential to accurate interpretation.
Devsort's design work is grounded in our data science practice. Because we build the pipelines that produce the data the interface displays, we design interfaces with a precise understanding of what the values mean, where they come from, and how they should and should not be interpreted.
How do we approach a UI/UX engagement?
- 1
Understand the data and the user
Before producing any design artefact, we understand two things: what data the interface must display and who will be using it. For clinical interfaces, this means reviewing the data model, the algorithm outputs, and their precision and reliability characteristics. It means understanding whether the user is a clinician, a coordinator, a patient, or an operations manager — each of whom has different domain knowledge and different tolerance for complexity.
- 2
Wireframe and validate
We produce low-fidelity wireframes for primary user flows and validate them against the requirements before investing in visual design. For clinical products, we pay particular attention to data display accuracy in wireframes — how values are labelled, how units are displayed, how missing or low-quality data is surfaced. These decisions are easier to catch at the wireframe stage than after visual design is complete.
- 3
Visual design and component specification
We produce high-fidelity visual designs and a component specification that the engineering implementation can be built directly from. For projects where Devsort also implements the front end, the specification and the implementation are owned by the same team, eliminating the handover gap that is a common source of design-implementation divergence.
- 4
Implementation and QA
Where we own the implementation, we build the interface components from the design specification and QA the result against the design intent. Where we are delivering design artefacts to an external engineering team, we provide the assets, specifications, and annotation needed for accurate implementation without requiring ongoing design involvement in the build phase.
What we design and build
Frequently asked questions
Do you deliver Figma files or production code?
Both, depending on the engagement scope. For design-only engagements, we deliver Figma files with full component annotations, a design token specification, and asset exports ready for engineering handover. For full-stack engagements where we own the front end, we implement the design directly in React and TypeScript, eliminating the handover step entirely. We are clear about which mode an engagement is in from the scoping phase.
Can you design clinical dashboards for wearable device data?
Yes — this is a specific area of experience. Clinical dashboards for wearable data present specific design challenges: data collected at irregular intervals, gaps from off-wrist periods, algorithm outputs with confidence characteristics that must be communicated without overwhelming the clinical user. We design for these challenges explicitly, having worked on the data pipelines that produce the values the dashboard displays.
Do you conduct user research?
We conduct targeted user research when the engagement scope requires it and the client can facilitate access to representative users. For clinical products, user research is most valuable at the wireframe validation stage — before visual design is finalised — where feedback can change layout and information architecture decisions at low cost. We do not conduct generative research or large-scale usability studies as a standalone service; we embed targeted research into the design process where it is most impactful.
How do you handle accessibility requirements for health technology interfaces?
We design to WCAG 2.1 AA as a baseline for all health technology interfaces. For clinical products deployed in healthcare settings, accessibility is not optional — clinicians use interfaces across a wide range of conditions, and patients interacting with health apps may have visual or motor impairments relevant to their condition. We test contrast ratios, focus management, screen reader compatibility, and touch target sizes as part of the standard design and implementation process.