Design thinking in healthcare is a way of deciding what to build before anyone writes code. It starts with the people inside a care process, frames the problem they actually have, and tests cheap versions of a solution until one earns the right to be engineered.
The method is well known outside healthcare. Inside it, the people are busier, the stakes are higher and the data is protected, so each stage needs adjusting. This guide walks through the five stages for care software, who should take part, how to frame the problem, which prototypes clinicians can judge and where sessions go wrong.
What is design thinking in healthcare?
Choosing what to build next?
A healthcare fractional CTO from Agnotic can run problem framing and prototype rounds with your team and turn the result into a build plan.
Design thinking in healthcare is a problem-solving method that moves through five stages, empathize, define, ideate, prototype and test, to shape care software around the clinicians, patients and staff who use it. Its purpose is to confirm the right problem and a workable solution before engineering money is committed.
The method is different from interface design. Interface work makes a chosen solution usable. Design thinking comes earlier and asks whether software is the answer at all, and if so, which part of the care process it should change.
A good outcome is often smaller than the original idea. A request for a new patient app can end as a better discharge text message and a change to one nurse workflow, which costs less and helps more patients.
How do the five stages map to care software?
Each stage keeps its usual purpose, but in a care setting it produces a specific artifact that the next stage depends on. Treat the artifacts as the deliverables, not the workshops.
- 1. Empathize: Observe the care process where it happens and talk to the people in it. The artifact is a journey map that shows each step, handoff, system and workaround.
- 2. Define: Turn what was observed into one problem statement with a named user, a moment and a measurable harm or delay. The artifact is that statement plus the constraints the solution must respect.
- 3. Ideate: Generate many ways to address the problem, including options that involve no new software. The artifact is a short list scored on value, effort and risk.
- 4. Prototype: Build the cheapest version of the top options that a real user can react to. The artifact is a paper flow, a clickable mockup or a scripted service test.
- 5. Test: Put the prototype in front of the people from stage 1 and watch them use it. The artifact is a decision: build, change or drop.
The stages loop. A test that fails sends the team back to define or ideate, and that return trip is cheap compared with discovering the same flaw after launch.
Set a time box for each loop before it starts, and agree who makes the build, change or drop call at the end. Without both, a promising idea can sit in prototype rounds for months while the original problem keeps costing staff time.
Who belongs in the room?
The people who do the work and the people who carry the risk both belong in the room. A session with only managers and designers produces a solution that the front line works around.
- Front-line clinicians: Nurses, medical assistants, therapists and physicians who run the process today. Schedule them around shifts and pay for their time.
- Patients and caregivers: People who live the other side of the process, recruited to match the population, including older adults and people who use assistive technology.
- Operations staff: Schedulers, billers and front desk staff, who often hold the steps nobody else sees.
- Clinical safety lead: A clinician who can say whether a proposed change could harm a patient and what checks it would need.
- Privacy and security: Someone who can rule early on what data a solution may use and where it may live.
- Engineering: A senior engineer who knows the EHR and integration limits, so ideas that cannot connect to existing systems are caught in stage 3, not stage 5.
Keep the group small enough to talk, and run separate sessions for groups that will not speak freely together, such as patients and the clinicians who treat them.
How do you frame the problem before sketching?
Frame the problem as one user, one moment and one consequence, written so it could be proven true or false. Vague statements such as "improve the patient experience" let every idea look like a fit.
A stronger statement reads: "Home health nurses spend part of each first visit re-entering medication lists that the hospital already sent, and errors in the re-entered list are not caught until the next visit." It names the user, the moment and the harm, and it points to data the team can check.
Next to the statement, list the constraints. They save weeks in ideation because they rule out options before anyone gets attached to them.
- Systems: Which EHR, portal and devices are in use, and what each can accept through its interfaces.
- Rules: Which privacy, billing or licensing rules touch the process, confirmed by the people responsible for them.
- People: Staffing, shift patterns and training time available for any change.
- Patients: Language, literacy, device access and disability needs in the population served.
- Evidence: What the team would need to see in a test to believe the problem is solved.
Then turn the statement into a few "how might we" questions, each aimed at a different part of the problem, and use those to start ideation.
Prototypes clinicians can judge
Clinicians judge a prototype by whether it fits a real case, so it needs realistic content even when it is rough. A clickable screen with placeholder text tells a nurse nothing about whether it would help on a busy shift.
- Paper or whiteboard flow: Fast and cheap, good for testing the order of steps and who does what.
- Scripted service test: A person plays the software, for example by sending text messages by hand, to test whether patients respond before anything is built.
- Clickable mockup: Screens linked in a design tool with realistic fictional cases, good for testing layout and wording.
- Wizard of Oz build: A working front end with a person doing the back-end work, good for testing a workflow under real timing.
- Thin technical spike: A small coded test of the riskiest integration, such as reading a medication list from the EHR sandbox.
Use synthetic or fictional patient cases in prototypes. If a session must use real records, or a research tool records patients describing their care, that tool will hold PHI. HHS cloud computing guidance treats a provider that holds ePHI as a business associate even when the data is encrypted and it has no key, so sign the agreement before the first session.
Run each test as a task, not a tour. Give the participant a realistic case and a goal, such as reconciling a medication list after discharge, then watch where they hesitate or work around the design. Record what they did, not only what they said they liked.
When should accessibility enter the process?
Accessibility should enter at stage 1, by recruiting people with disabilities into research, and stay through every test. Adding it after the prototype is approved means redesigning the parts users liked.
There is a legal reason as well. For organizations that receive HHS federal financial assistance, 45 CFR 84.84 sets WCAG 2.1 Level AA as the standard for their websites and mobile apps. A May 2026 interim final rule set the compliance dates at 11 May 2027 where the recipient has 15 or more employees, and 10 May 2028 otherwise.
In practice that means testing prototypes with a screen reader user and a keyboard-only user, checking color contrast in mockups, and writing patient content at a reading level the population can use. Each of these is cheaper at the paper stage than in code.
Language access belongs in the same early check. If the population includes patients who prefer another language, test translated prototype content with them, because a flow that works in English can break when labels grow longer or instructions read differently.
Where design sprints go wrong in healthcare
- Solution in the brief: The sprint is asked to design "the app", so define and ideate become formalities.
- No front-line voice: Managers describe the process, and the workaround that matters most never comes up.
- Interviews instead of observation: People describe the process as it should run, not as it does on a short-staffed night.
- Placeholder content: Prototypes use lorem ipsum, so clinicians cannot tell whether the design fits real cases.
- Integration found late: The winning idea needs data the EHR cannot send, and the team learns this after the test.
- No exit decision: Testing ends with positive comments but no build, change or drop call, and the idea drifts into the backlog.
- Handoff by slide deck: Engineering receives pictures instead of the problem statement, constraints and test findings.
The last point decides whether the work pays off. Hand engineering the journey map, problem statement, constraints, chosen prototype and test notes together, so they build the thing that was tested and know why each choice was made.
How Agnotic can help
Design thinking pays off when the people who framed the problem also shape the build plan. As a healthcare fractional CTO partner, Agnotic Technologies runs problem framing and prototype rounds with the client's clinicians, patients and staff, checks each idea against EHR and integration limits, and turns the tested option into an engineering plan.
Agnotic engineers can then build the chosen solution, starting with the thin technical spike that proves the riskiest integration.
Plan your next care software build
Start with a healthcare fractional CTO, or browse more articles in the guides hub.
Related reading on Agnotic
Continue with interface research, clinic screen habits, digital experience design and accessible technology.
