Reframing “data loss” as a visibility problem in a primary healthcare app
A recurring wave of support complaints looked like a database failure. A structured research initiative showed it was a UX problem — and led to a 91.5% drop in complaints within a year.
- UX Research
- Healthcare
- Product Design
- Discovery
- Evidence Triangulation
reduction in complaints related to perceived data loss — from 20% of all support tickets (Apr 2023) to 1.7% (Apr 2024).
Project snapshot
A quick overview of the product, the team and the shape of my contribution.
- Product
- Primary Healthcare Management App
- Sector
- Public Healthcare
- Primary users
- Healthcare professionals in primary care — physicians, nurses and administrative staff
- My role
- Product Designer & UX Researcher — sole designer leading the research initiative
- Methods
- Stakeholder interviews · Persona survey · Semi-structured user interviews · Support ticket analysis · Evidence synthesis · Prioritization workshops · UX Research · Interaction Design
- Team
- 1 Product Manager · 1 Product Owner · Engineering (1 tech lead, 3 developers) · Customer Experience Manager · Me (sole Product Designer)
- Duration
- April 2023 – April 2024
The signal
Support was receiving a growing volume of tickets about “disappearing records” and “lost data”. Users were frustrated, resorting to paper notebooks and spreadsheets, and losing trust in the platform.
The natural first instinct across the team was to look at the database. The engineering team investigated and found no evidence of actual data loss — records existed and were intact. The complaints were real, but the diagnosis pointed elsewhere.
The reframe
Once engineering confirmed the data was intact, the question changed shape. It was no longer “why is the system losing data?” but “why do experienced professionals believe the system is losing data?” — a UX question, not a database one.
Records disappearing, work being lost, mistrust in the platform, duplicated work in paper and spreadsheets.
Engineering had verified there was no actual data loss. Records existed and were correctly stored.
Why users were consistently interpreting the system's behaviour as loss, and what part of the workflow triggered that perception.
I proposed a structured research initiative to reduce uncertainty. The PO and PM supported it and gave me the space to lead the discovery end-to-end.
The perception of data loss was created by the system, not by the data. A visibility problem — the absence of feedback about what was happening to a record when other professionals interacted with it — was being read by users as loss.
Discovery strategy
The research was designed as progressive uncertainty reduction: each method was chosen for what it could rule in or rule out, not for method completeness.
- 01
Stakeholder interviews
Map existing knowledge across Support, Product, QA and Engineering before spending research budget on the field.
Reduces the risk of researching what the company already knows.
- 02
Persona survey (152 respondents)
Characterise who the users actually are: routines, devices, connectivity, workarounds and constraints.
Turns internal assumptions about users into evidence.
- 03
Alignment workshop
Surface the team's remaining uncertainties and convert them into concrete research questions.
Ensures the interviews investigate what will actually inform decisions.
- 04
Semi-structured interviews
Explore real workflows, decision-making and the moments where trust in the system breaks.
Explains behaviour and mental models behind the complaints.
- 05
Support ticket analysis
Read a corpus of tickets to trace recurring language, triggers and affected workflows.
Grounds interview findings in the volume and frequency of real reports.
- 06
Evidence triangulation
Only act on findings confirmed across at least two independent sources.
Prevents design decisions being driven by a single loud signal.
What the persona survey revealed
I ran a structured online survey with 152 healthcare professionals to characterise the users, identify recurring pain points and shape the research questions.
- Understand who our users actually were.
- Identify recurring pain points across the field.
- Build initial research hypotheses to test in interviews.
- Evidence-based personas.
- Prioritised list of initial pain points.
- Research questions for the interview phase.
- Work routines and responsibilities
- Technology use and connectivity
- Pain points, frustrations and workarounds
- Motivations and goals
- Accessibility needs
Evidence triangulation
No decision was made from a single source. A finding only entered the recommendation set if at least two of the four sources reinforced it.
Support ticket analysis
Frequency, language and affected workflows.
Persona survey (n=152)
Context, devices, workarounds and recurring pain points.
Semi-structured interviews
Mental models, decision-making, moments of broken trust.
CX leadership support
Operational impact and pattern recognition across support.
All four sources pointed to the same root: users were losing access to records they had previously edited, without any feedback from the system. What looked like “loss” was actually a silent transfer of responsibility.
Root cause
The regulation itself was necessary — but the interface never communicated it. That silence was the root cause.
Data-protection regulations required that only one professional could be responsible for a given citizen's record at a time.
When another professional re-registered the same citizen under their own login, responsibility transferred and the previous professional lost access to that record.
The system provided no feedback: no notification, no history, no visible actor, no dedicated view for records that had been transferred. Users had no way to distinguish “moved” from “lost”.
Visibility of system status
Users must be kept informed about what is happening through clear and timely feedback. The absence of this principle turned a compliant technical behaviour into a perceived critical failure.
Design principles that guided the solution
Before ideating screens, I defined a small set of principles derived from the evidence. Every proposal had to pass through them.
Make the invisible visible
If the system changes the state of a record, the user responsible for it must know.
Attribute every action
Never leave a change without an author. Silent changes read as loss.
Give control back to the user
Provide a way to find, review and act on records that were transferred — not just a notification and dead end.
Close the feedback loop
Every meaningful user action needs an immediate, contextual response.
Prioritization
Prioritization was collaborative with the Product Owner. Each problem was assessed across four axes so the roadmap was defensible, not just intuitive.
How much does the problem damage trust or block work?
How frequently is it happening in the field right now?
How much engineering and design effort does it require?
How much would resolving it move the metric that matters?
Perceived data loss
High severity, high urgency, feasible effort, highest expected impact. Chosen as the focus of this case study.
Workflow friction
Recurring friction in daily tasks. Addressed after the urgent tier.
Improvement opportunities
Lower-severity issues surfaced during research, kept in the backlog for future iterations.
Solution
A set of research-backed improvements focused on visibility, feedback, control and transparency — each traceable to a principle and a source of evidence.
Re-registered patients page
A dedicated view for records that were deactivated because another professional re-registered the citizen. Turns silent transfers into a place to go.
Smart notifications
Contextual alerts when records are deactivated, deleted or re-registered by other professionals.
Action attribution
Clear identification of who performed each action inside the system.
Change history
Action history and synchronization logs so users can reconstruct what happened to a record.
Synchronization status
A persistent visual indicator of the current data-saving state, so users always know where they stand.
Contextual feedback
Immediate response for every meaningful action, closing the loop between user intent and system reaction.
Validation & results
Impact was tracked across two channels — support ticket volume and a structured user satisfaction survey — and reported honestly: measured, observed and expected outcomes are separated.
Supported by quantitative data.
- Complaints down 91.5%
Tickets classified as “data loss” dropped from 20% of all support requests (Apr 2023) to 1.7% (Apr 2024).
- Feature satisfaction: 3.54 / 4
Post-release satisfaction survey for the re-registered patients page.
Consistently reported by Product, Support and stakeholders, but not formally measured.
- Support team spending less time on “data loss” explanations and reorientations.
- Users regaining a clearer understanding of what happens to their records.
- Fewer escalations coming from the field on the same topic.
Anticipated business and operational impact, not directly validated with metrics.
- Lower operational cost across Support and Product on this topic over time.
- Higher long-term retention of trust in the platform.
A secondary finding: adoption, not only interface
During interviews it became clear that some usability issues were driven by users' unfamiliarity with parts of the product, rather than by interface problems alone. This shifted a portion of the recommendations from “redesign” to “training, onboarding and internal enablement”, and reinforced that visibility work has to be paired with adoption work to hold over time.
Reflection
The most valuable outcome of this project was not a screen — it was a reframing. Turning “the database is broken” into “the system is silent” changed what the team built, how support explained it, and how users experienced it. Research paid for itself in the number of engineering hours it made unnecessary.
This case study has been anonymized. The company, product name, screens and internal data have been omitted. The methodology, decisions, evidence classification and measured outcomes are accurate.