The Layer Users Never See: How Health Data Shapes the User Experience
Why carefully designed health apps and clinical tools still frustrate people, and how to design with the real data in mind from the start.
Suhina Singh
Founder & CEO, Jonda Health
October 7, 2026
·
9 min read
In short
In healthcare, much of what people experience as “bad design” is really a data problem: duplicates, inconsistent names and units, information locked in documents, and missing context.
These problems sit in a layer users never see, so they are easy to miss in design reviews and expensive to fix after launch.
Artificial intelligence (AI) features make the layer more important, not less, because they turn inconsistent data into confident answers.
Design with real, messy records from the start, and plan how the data will be made usable before the build.
Picture a well-designed patient app. The layout is clean, the colours are calm, and the team tested every screen with real users. A patient opens their results and sees a chart of their blood sugar control that jumps sharply from one test to the next. Nothing changed in their health. The two results came from different laboratories that report the same test in different units, and the chart simply plotted both numbers on the same line.
The patient worries and calls the clinic. The clinic's staff lose confidence in the app. In the review that follows, the design team is asked to rework the chart, when the real cause sits a layer below the screen.
This guide is for digital health product teams, hospital and clinic digital leads, pharma teams running patient support programmes, and insurers and employers running health programmes. It looks at the layer users never see, the six data problems that most often surface as poor user experience (UX), and how to design with real data in mind from the start. It builds on our earlier guide, Six Reasons Healthcare Software Stalls After Launch, where data people cannot trust was one of the two areas we recommend fixing first.
The layer users never see
Every health product has two layers. The first is the one people see and touch: timelines, charts, summaries, reminders and alerts. The second is the one underneath: where the information comes from, what shape it arrives in, and how much work has been done to make it consistent and reliable before it reaches a screen.
Design teams spend most of their time on the first layer, which is natural, because that is where users give feedback. But in healthcare the second layer is unusually complex. A single person's record might be assembled from laboratory reports in several formats, scanned discharge summaries, medication lists typed by different clinicians, imaging reports written in free text, readings photographed from a home device, and messages from other systems in standards such as Health Level Seven version 2 (HL7 v2) or Fast Healthcare Interoperability Resources (FHIR). Often it is in more than one language.
What people see depends on work they never see. When the lower layer is skipped, the problems surface in the upper one.
When this lower layer has not been dealt with properly, the problems do not stay hidden. They surface in the upper layer, where they look like design faults.
Six data problems that show up as bad UX
1Duplicates and gaps make the record look broken
What people experience
The same result appears twice. A medication list shows a drug that was stopped months ago. A patient’s timeline has a year-long gap where they know they saw a specialist.
What sits underneath
The same information arrived through more than one route, such as a laboratory feed and an emailed report, with nothing to recognise it as the same event. Other information never arrived at all because it sits with another provider or in a paper file.
What to fix
Decide how duplicates will be recognised and merged before data reaches the product, and design the timeline to show where history comes from, so gaps are visible and explained rather than silently missing.
2The same thing appears under different names
What people experience
A trend chart shows only half the results for a test the patient has had many times. A medication appears three times under a brand name, a generic name and an abbreviation. Summaries count the same condition more than once.
What sits underneath
Different laboratories, clinics and clinicians capture the same test, medication or diagnosis in different ways, and some institutions maintain their own local code sets. Without resolving these variations, the product cannot tell they are the same thing.
What to fix
Resolve variant captures and map them to consistent medical coding standards, while keeping the institution’s own codes where they matter. This is what makes trends, filters and summaries work.
3Mixed units and reference ranges produce misleading charts
What people experience
A chart spikes or drops for no clinical reason. A result is flagged as high in one report and normal in another. This is the scenario we opened with.
What sits underneath
The same test can be reported in different units. Glycated haemoglobin (HbA1c), a common measure of blood sugar control, is reported either as a percentage aligned with the National Glycohemoglobin Standardization Program (NGSP) or in millimoles per mole using the International Federation of Clinical Chemistry and Laboratory Medicine (IFCC) reference method. A result of 7.0% corresponds to about 53 mmol/mol.1, 2 Plotted on the same axis without conversion, those two numbers look like a dramatic change. Reference ranges also differ between laboratories, depending on their methods and populations.
What to fix
Store the original value and unit, convert to a consistent unit for display, and show the reference range that came with each result. Charts should never plot values in different units on the same line.
The same two results, before and after the data underneath is made consistent. The design of the chart did not change; the data did.
4Information locked in PDFs and scans cannot do anything
What people experience
Search does not find a result the patient knows is there. A reminder for a follow-up test never fires. A clinician has to open and read a document to find one number.
What sits underneath
The information exists, but only as a document or image. A PDF laboratory report, a scanned discharge summary or a photograph of a blood pressure monitor can be displayed, but the product cannot read it, so it cannot sort, search, trend or act on it.
What to fix
Extract the information into structured data, check it, and keep a link to the original document so people can always see the source.
5Free text and local codes break filters and reporting
What people experience
A coordinator filters for patients with a particular condition and misses half of them. A programme report undercounts the people it is meant to track. An imaging finding mentioned in a clinical note never appears in a summary.
What sits underneath
Important information is written in narrative text, abbreviations or a local shorthand that makes sense to the author but not to a system. Products built on structured fields simply do not see it.
What to fix
Identify which pieces of narrative information matter for your product, extract them into structured form with clinical review, and design filters and reports around what the data can reliably support.
6Missing context makes people doubt what they see
What people experience
A result has no date, or only the date it was uploaded. Nobody can tell which laboratory produced it or who ordered it. A clinician hesitates to act because they cannot judge how current or reliable it is.
What sits underneath
Context such as collection date, source, ordering clinician and reference range was lost as information moved between systems, or was never captured.
What to fix
Treat context as part of the data, not decoration. Capture it on the way in and show it on screen, because it is often what turns information into something people are willing to act on.
For quick reference, here are the six problems in one view.
Problem
What people experience
What sits underneath
What to fix
1. Duplicates, gaps
A record that looks broken
Multiple routes, missing sources
Merge rules, visible gaps
2. Different names
Incomplete trends, repeated items
Variant captures, local code sets
Resolve variants, map to standards
3. Mixed units
Misleading charts and flags
Different units and ranges
Convert, keep original, show range
4. Locked documents
Search and reminders fail
PDFs, scans, photos
Extract, check, link to source
5. Free text
Filters and reports miss people
Narrative and shorthand
Structure what matters, with review
6. Missing context
Doubt and hesitation
Dates and sources lost
Capture and show context
Why AI makes this more urgent
Many teams are now adding AI features: a summary of a patient's history, an assistant that answers questions about results, or support for coordinators managing large caseloads. These features can be genuinely helpful, but they do not remove the lower layer. They depend on it.
A plain screen with inconsistent data at least shows the inconsistency, so an attentive clinician may notice it. An AI summary built on the same data can smooth over the inconsistency and present a confident, well-written answer that happens to be wrong. That is harder to spot and does more damage to trust when it is discovered.
This is why the lower layer needs checks and balances, including review by people with clinical training, before AI features are built on top of it. Asking a language model to tidy messy records inside the product is not a substitute. It adds cost with every request, and it rarely includes the review and audit trail that clinical information needs.
How to design with real data in mind
None of this means designers need to become data engineers. It does mean that the data belongs in the design process from the beginning. These five practices make the biggest difference.
Bring the data into discovery
Alongside user interviews, ask where the information will come from, in what formats, and how consistent it is likely to be. Invite someone who knows the data into early design sessions.
Prototype with real, messy records
Clean dummy data makes every design look good. Use a set of real, pseudonymised records with their duplicates, mixed units and gaps intact, and see how the design holds up.
Design for missing and uncertain states
Decide what the screen shows when a value is missing, a date is unknown or a result could not be confirmed. These states will be common, so they deserve the same care as the ideal one.
Show the source and date
Let people see where each piece of information came from and when, with a route back to the original document. This single choice does a great deal for trust.
Plan how the data will be made usable before the build
Agree how records will be structured, cleaned, reviewed and mapped to standards before screens are finalised. Fixing this after launch is far more expensive and far harder to explain to users.
What this looks like in practice
When the lower layer is handled properly, product teams can spend their time on the experience rather than on cleaning data. Two examples from teams using JondaX show what that can mean.
About 2 months
for a digital health startup to reach a working product using JondaX for all its clinical data, instead of the year and a half or more it expected to spend building this itself.
Around 80%
reduction in manual effort for a European longevity platform whose clients send laboratory reports from many different countries.
In both cases, the benefit showed up in the experience. The product teams could design trends, summaries and reports knowing the data underneath was consistent, and their users could trust what they saw.
How Jonda Health can help
Whether you are designing a new product or fixing one that is already live, there are two ways we can support you, and they work best together.
JondaX: make the data usable
A single application programming interface (API) for every source, from PDFs, scans and device photos to HL7 v2 messages and FHIR.
Records made usable across formats and languages: cleaned, with variant captures resolved, reviewed by clinically trained reviewers, then mapped to medical coding standards, including your own code sets where needed.
99% field-level accuracy with expert review.
ISO 27001 certified and designed to comply with the Health Insurance Portability and Accountability Act (HIPAA), the General Data Protection Regulation (GDPR) and the Personal Data Protection Act (PDPA).
Jonda Health Services: design, build and prove
Discovery that brings users and data into the same conversation from the start.
Prototyping and testing with real, pseudonymised records.
Design of the states most products forget: missing, uncertain and conflicting information.
A review of an existing product to separate design problems from data problems.
Not sure which layer is holding you back?
Tell us what your users are experiencing. In a free 30-minute conversation, we will help you work out whether the problem sits in the design, the data or both, and where to start.
Consensus Committee (American Diabetes Association, European Association for the Study of Diabetes, International Federation of Clinical Chemistry and Laboratory Medicine, International Diabetes Federation). Consensus statement on the worldwide standardization of the hemoglobin A1C measurement. Diabetes Care. 2007;30(9):2399-2400.
National Glycohemoglobin Standardization Program. IFCC standardization of HbA1c: conversion between NGSP (%) and IFCC (mmol/mol) units. ngsp.org.
