Making insulin delivery clearer and safer
Making insulin delivery clearer and safer
Making insulin delivery clearer and safer
Product
Insulin patch-pump controller
Mobile software for managing continuous insulin delivery.
Role
Lead UX Researcher & Product Designer
Led research, interaction design, formative testing and delivery documentation for the new controller.
Timeline
2 years · Startup to global medtech
15 months on the new controller for FDA submission, followed by 7–8 months contributing to established insulin-pump products after the acquisition.
scope
Research · interaction design · usability testing · design system · documentation
team
Human factors · product · engineering · QA · risk · testing
Problem Making treatment workflows safer to use
Problem Making treatment workflows safer to use
The controller supported insulin delivery, dose entry, alarms, pump replacement and recovery. A confusing interaction could contribute to a use error and potentially affect patient safety.
The controller supported insulin delivery, dose entry, alarms, pump replacement and recovery. A confusing interaction could contribute to a use error and potentially affect patient safety.
Approach Designing around foreseeable use errors
Approach Designing around foreseeable use errors
I combined domain research, workflow mapping and scenario-based usability testing to understand how people interpreted the system and where important tasks could break down. I translated the evidence into clearer flows, safer interaction rules, error states, alerts and detailed documentation for design, engineering and testing.
I combined domain research, workflow mapping and scenario-based usability testing to understand how people interpreted the system and where important tasks could break down. I translated the evidence into clearer flows, safer interaction rules, error states, alerts and detailed documentation for design, engineering and testing.
Outcome Safety risks identified before release
Outcome Safety risks identified before release
The work identified foreseeable use errors early, informed changes to critical workflows and gave design, engineering and testing one shared implementation reference. The controller later progressed into further user and clinical studies and received positive feedback from the target audience.
The work identified foreseeable use errors early, informed changes to critical workflows and gave design, engineering and testing one shared implementation reference. The controller later progressed into further user and clinical studies and received positive feedback from the target audience.
01 understand
01 understand
What did we need to learn first?
What did we need to learn first?
What did we need to learn first?
Clinical and technical evidence defined what the controller had to do, but it did not explain how people fitted insulin management into daily life. I reviewed the existing evidence and competitor products, then interviewed four experienced pump users before defining the information architecture.
Clinical and technical evidence defined what the controller had to do, but it did not explain how people fitted insulin management into daily life. I reviewed the existing evidence and competitor products, then interviewed four experienced pump users before defining the information architecture.
02 Test
02 Test
Where could foreseeable use errors occur?
Where could foreseeable use errors occur?
Where could foreseeable use errors occur?
The controller was being developed within an IEC 62366-informed human-factors process for FDA submission. Before formal validation, we needed evidence that representative users could complete critical setup and treatment tasks safely and understand where the design still required improvement.
The controller was being developed within an IEC 62366-informed human-factors process for FDA submission. Before formal validation, we needed evidence that representative users could complete critical setup and treatment tasks safely and understand where the design still required improvement.
03 deliver
03 deliver
How I carried the evidence into delivery
How I carried the evidence into delivery
How I carried the evidence into delivery
I translated the research findings into detailed workflows, interface states, terminology and reusable UI patterns. These became shared references for design, engineering and testing, and the UI Design Document formed part of the Design History File.
I translated the research findings into detailed workflows, interface states, terminology and reusable UI patterns. These became shared references for design, engineering and testing, and the UI Design Document formed part of the Design History File.
04 outcome
04 outcome
What changed because of the research?
What changed because of the research?
What changed because of the research?
For the new controller, the most meaningful evidence of progress was not conversion or retention. It was whether testing exposed foreseeable use errors, whether those findings changed the design, and whether the resulting behaviour could be implemented, tested and reviewed as part of the FDA-submission programme.
For the new controller, the most meaningful evidence of progress was not conversion or retention. It was whether testing exposed foreseeable use errors, whether those findings changed the design, and whether the resulting behaviour could be implemented, tested and reviewed as part of the FDA-submission programme.
Research question
What information and functions do experienced pump users depend on during everyday insulin management?
Research question
What information and functions do experienced pump users depend on during everyday insulin management?
Research question
What information and functions do experienced pump users depend on during everyday insulin management?
Research question
Research question
Where could users skip a required step, misunderstand the system or take an unintended action?
Where could users skip a required step, misunderstand the system or take an unintended action?
The first information architecture translated treatment routines and requirements into one shared system model.
The first information architecture translated treatment routines and requirements into one shared system model.
The first information architecture translated treatment routines and requirements into one shared system model.
3
testing rounds
8
participants
2/8
failed pump attachment
1/8
failed to suspend
3
testing rounds
8
participants
2/8
failed pump attachment
1/8
failed to suspend
3
testing rounds
8
participants
2/8
failed pump attachment
1/8
failed to suspend
Feature-by-feature plan
Expectation alignment → design draft → team review → client review
Feature-by-feature plan
Expectation alignment → design draft → team review → client review
Feature-by-feature plan
Expectation alignment → design draft → team review → client review
Why scenario-based testing? Participants completed realistic setup and treatment scenarios using the prototype. This allowed us to observe behaviour rather than rely on opinions or self-report and to improve the design before formal human-factors validation.
Why scenario-based testing? Participants completed realistic setup and treatment scenarios using the prototype. This allowed us to observe behaviour rather than rely on opinions or self-report and to improve the design before formal human-factors validation.
Scenarios covered: initial setup, basal-profile editing, bolus delivery, suspension and pump switching.
Scenarios covered: initial setup, basal-profile editing, bolus delivery, suspension and pump switching.
How we analysed the sessions
Each task was classified as success, success with difficulty or failure. We documented what happened, investigated the likely cause and considered the potential consequence and whether the interface supported recovery.
How we analysed the sessions
Each task was classified as success, success with difficulty or failure. We documented what happened, investigated the likely cause and considered the potential consequence and whether the interface supported recovery.
How we analysed the sessions
Each task was classified as success, success with difficulty or failure. We documented what happened, investigated the likely cause and considered the potential consequence and whether the interface supported recovery.
Finding 01 · Pump attachment
Finding 01 · Pump attachment
Users did not reliably follow the activation sequence
Users did not reliably follow the activation sequence
Finding 02 · Treatment safety
Finding 02 · Treatment safety
Unsupported BG values could not continue into dose calculation
Unsupported BG values could not continue into dose calculation
What happened
What happened
Two of eight participants failed; two more completed the task only with difficulty.
Two of eight participants failed; two more completed the task only with difficulty.
Why it happened
Why it happened
The current pump state and required next action were not explicit enough.
The current pump state and required next action were not explicit enough.
Interpretation
Interpretation
We revised the sequence, instructions and feedback so the safest next action was clearer and missed steps were less likely.
We revised the sequence, instructions and feedback so the safest next action was clearer and missed steps were less likely.
The trade-off
The trade-off
Adding more guidance increased the amount of information on screen, but testing showed that explicit device-state feedback was more important than visual minimalism in this workflow.
Adding more guidance increased the amount of information on screen, but testing showed that explicit device-state feedback was more important than visual minimalism in this workflow.
risk
risk
An out-of-range reading could be unreliable or require immediate attention.
An out-of-range reading could be unreliable or require immediate attention.
What we decided
What we decided
Label it HIGH or LOW, keep it out of the bolus calculation and require a supported reading before continuing.
Label it HIGH or LOW, keep it out of the bolus calculation and require a supported reading before continuing.
Why it mattered
Why it mattered
This prevented uncertain information from being used to calculate insulin and clearly showed the user what to do next.
This prevented uncertain information from being used to calculate insulin and clearly showed the user what to do next.
The trade-off
The trade-off
The user had to stop and enter a supported reading before continuing. This added an extra step, but it was safer than calculating a dose from uncertain information.
The user had to stop and enter a supported reading before continuing. This added an extra step, but it was safer than calculating a dose from uncertain information.
Enter BG flow
Enter BG flow
Enter BG flow
UI Design Document
UI Design Document
UI Design Document
Critical semantic tokens applied to a reusable alert pattern.
Critical semantic tokens applied to a reusable alert pattern.
Critical semantic tokens applied to a reusable alert pattern.
Patient-safety impact
Testing identified use errors, unclear terminology and problems in critical workflows early enough for the team to improve the design.
Patient-safety impact
Testing identified use errors, unclear terminology and problems in critical workflows early enough for the team to improve the design.
Patient-safety impact
Testing identified use errors, unclear terminology and problems in critical workflows early enough for the team to improve the design.
Product impact
The controller progressed into further user and clinical studies and received positive feedback from the target audience.
Delivery impact
The interaction model, design system and UI Design Document gave design, engineering and testing one shared reference for implementation.
Next case →
← All work
← All work
Interface strings unified, versioned and prepared for engineering.
Interface strings unified, versioned and prepared for engineering.
Interface strings unified, versioned and prepared for engineering.
What do you check first after waking up?
What do you check first after waking up?
Measure BG and calibrate the sensor
Measure BG and calibrate the sensor
How often do you check your blood glucose?
How often do you check your blood glucose?
2–10 times per day
2–10 times per day
Which bolus types do you actually use?
Which bolus types do you actually use?
60% quick · 30% dual · 10% long
60% quick · 30% dual · 10% long
How the project progressed
How the project progressed
Existing clinical and product evidence → domain learning and competitive research → user interviews → information architecture and wireframes → formative usability testing → iterative UI design → further testing → implementation documentation and multidisciplinary review.
Existing clinical and product evidence → domain learning and competitive research → user interviews → information architecture and wireframes → formative usability testing → iterative UI design → further testing → implementation documentation and multidisciplinary review.
4
discovery interviews
3
formative test rounds
8
participants in the reported round
3
clear delivery outcomes
Why this approach? Existing evidence defined the clinical and technical boundaries. Competitor research revealed familiar patterns and unresolved problems. Interviews added users’ routines, priorities and language.
Why this approach? Existing evidence defined the clinical and technical boundaries. Competitor research revealed familiar patterns and unresolved problems. Interviews added users’ routines, priorities and language.
What the interviews helped us understand
What the interviews helped us understand
The interviews showed what people checked first, which actions they used most often, what they expected to find in treatment history and which terms already felt familiar.
The interviews showed what people checked first, which actions they used most often, what they expected to find in treatment history and which terms already felt familiar.
How the findings shaped the product
How the findings shaped the product
I used these findings to shape the information architecture, navigation priorities and the scenarios used in formative testing. The proposed structure was then reviewed with the wider team.
I used these findings to shape the information architecture, navigation priorities and the scenarios used in formative testing. The proposed structure was then reviewed with the wider team.
What I personally owned
What I personally owned
Planned and conducted discovery interviews
Facilitated multidisciplinary workshops to align the team
Turned findings into architecture, scenarios and prototypes
Planned and conducted discovery interviews
Facilitated multidisciplinary workshops to align the team
Turned findings into architecture, scenarios and prototypes
Ran formative usability testing and analysed failures, difficulties and likely use errors
Revised workflows and interaction behaviour
Led UI delivery, interface strings, design-system work and documentation
Ran formative usability testing and analysed failures, difficulties and likely use errors
Revised workflows and interaction behaviour
Led UI delivery, interface strings, design-system work and documentation
Testing results
Testing results
Testing results
Client name withheld. The shipped interface remains confidential; selected wireframes, research evidence and system artefacts are shown instead.
Client name withheld. The shipped interface remains confidential; selected wireframes, research evidence and system artefacts are shown instead.
What changed in my practice
What changed in my practice
This was my first medical-device project, and at the beginning I found it difficult. I had to understand the clinical side, the hardware, the software and the safety process at the same time. It taught me to think beyond whether someone could complete a task. I started paying more attention to uncertainty, stress and what could happen when something went wrong.
This was my first medical-device project, and at the beginning I found it difficult. I had to understand the clinical side, the hardware, the software and the safety process at the same time. It taught me to think beyond whether someone could complete a task. I started paying more attention to uncertainty, stress and what could happen when something went wrong.
What stayed with me
What stayed with me
Speaking with people living with Type 1 diabetes made the effect of small interaction decisions feel real. The controller was only one part of their daily treatment, but it could either add to that burden or make it a little easier. With more time, I would have involved a broader mix of users earlier, including less experienced users, older adults and parents managing treatment for children.
Speaking with people living with Type 1 diabetes made the effect of small interaction decisions feel real. The controller was only one part of their daily treatment, but it could either add to that burden or make it a little easier. With more time, I would have involved a broader mix of users earlier, including less experienced users, older adults and parents managing treatment for children.
