A Design Diagnostic for Clinical Software

Surfacing Design Risk Before It Reaches the Clinician

The design problems that cause clinical software to fail are almost never discovered after launch. They are discovered during it. Workflow mismatches that weren't visible in the demo. Alert patterns that trained the pilot group to ignore warnings. Onboarding assumptions that didn't survive first contact with a real clinical environment. The evidence was there, but the review that would have found it wasn't.

GoInvo's design diagnostic is meant to fill this gap. Over 4-8 weeks, senior clinical design experts review your product and share their findings directly with leadership. You get a clear answer: either your design is ready, or it needs work, along with specific steps for improvement. This way, decision-makers get useful insights before clinicians run into problems.

What the Diagnostic Delivers

A GoInvo design diagnostic offers three important deliverables that most pre-launch processes miss:

• Actionable findings for leadership: A ranked, evidence-based assessment of the design failures most likely to influence clinician adoption.
• An independent perspective: GoInvo has no prior involvement with design decisions, vendor relationships, or interests beyond providing an accurate assessment.
• Implementation-ready design: For high-priority issues, GoInvo delivers designs that engineering teams can use immediately.

This diagnostic has helped prevent failed launches and, when needed, has advised clients not to launch. Both results are valuable. The cost of a design diagnostic is much less than the cost of releasing a product that isn’t ready.

What a Pre-Launch Audit Finds

Across clinical software categories, from EHRs to clinical decision support, imaging platforms, patient-facing tools, and AI-assisted workflows, the same failure patterns show up before launch and often become expensive problems later:

• Task completion failures under time pressure: Workflows that function in demos but fail when physicians manage multiple patients simultaneously.
• Trust signal gaps in AI-generated content: Recommendations that are technically accurate but presented with insufficient context for a clinician to evaluate in the time available.
• Mobile interaction breakdowns: Desktop-oriented interfaces that require multiple steps for tasks clinicians must perform one-handed between patient rooms.
• Onboarding assumptions that don't survive first use: Products that assume a level of familiarity or training that the average clinician will not have on day one.
• Alert patterns that lead clinicians to ignore warnings: Systems that generate frequent low-relevance alerts, causing users to disregard important notifications.

These are not edge cases. They are the norm. For example, a national study found that U.S. physicians gave EHRs a failing usability score of 45.9. (1) Clinicians override about two-thirds of system warnings, not due to carelessness, but because the design hasn’t earned their trust. ⁽³⁾ At the University of Washington Medical Center, physicians overrode 95.1% of drug-drug interaction alerts, with higher alert volumes leading to more overrides. ⁽²⁰⁾ All of these problems can be identified before launch.

The Review Was Right. The Decision Was Wrong.

The HealthCare.gov launch is the most documented example of clinical software failure in American political history, and the most instructive, because the evidence was overwhelming, the reviewers were credible, and the warnings were delivered to the right people. None of it mattered.

In late spring of 2013, McKinsey & Co. delivered a risk assessment to senior White House and CMS officials. The findings were unambiguous: evolving requirements, insufficient testing, no single decision-making authority, and a plan to launch in all 50 states simultaneously with no phased rollout.⁽²¹⁾ TurningPoint, brought in for independent verification and validation, flagged the same problems.⁽²²⁾ MITRE, serving as CMS's independent security contractor, completed its own assessment in August and September and documented that complete end-to-end testing had never occurred. When the development team sought to have the report changed, MITRE refused, with its lead tester stating in writing that the findings accurately described the assessment.

On October 1, 2013, HealthCare.gov went live. Six people successfully enrolled on day one.

A Senate investigation concluded that officials “ignored countless red flags to launch a website with thousands of defects” and that the breakdown “was not a surprise to dozens of high-level officials within CMS and HHS, nor to hundreds of individuals working for the contractors who had developed the code.”⁽²²⁾ The red team findings were accurate. The independent reviewers had documented exactly what would happen. And at no point did anyone with the authority to stop the launch say it was not ready.

This work aims to prevent failures caused not by missing evidence, but by the lack of a clear, senior voice turning evidence into action. GoInvo’s approach solves this by giving findings and recommendations straight to the people making launch decisions.

The Pattern Repeats

The VA's Oracle Cerner EHR modernization repeated this pattern a decade later. Independent review teams documented patient safety events, medication errors, and scheduling failures in live deployments. The design problems, including workflows that didn't match how VA clinicians worked and medication-ordering interfaces that introduced new error pathways, were identifiable before they led to adverse events. The rollout was paused in 2023 after documented harm reached patients.⁽⁶⁾

A similar dynamic occurs in medical device development. Infusion pumps often meet pre-market technical requirements but still contain design defects, such as dosing errors in confirmation screens and alarm patterns that encourage users to ignore warnings. These issues are visible in pre-launch usability testing and have significant clinical consequences. Technical compliance does not guarantee design adequacy; a product can meet all regulations yet still fail clinicians in practice.

GoInvo performed this type of review for the NIH All of Us research program, conducting rapid participant experience audits and consent design testing focused on return-of-information flows. Comprehension failures were identified before reaching a large participant population. As a result, findings were addressed, the product was improved, and the launch was successful.

The Cost of Shipping the Wrong Product

The case for pre-launch design review is clear. Design changes made during the concept stage require minimal time, while changes at the code stage take weeks and post-launch changes take months. The later you find a problem, the more it costs, not just in engineering, but also in lost trust if clinicians find the product hard to use.

Clinicians spend an estimated one-third to one-half of their workday interacting with health IT systems, adding to more than $140 billion in lost care capacity annually.⁽²⁾ A systematic review found that in 53% of the studies examined, health IT problems were associated with patient harm or death.⁽⁵⁾ The VA Oracle Cerner failure resulted in over 11,000 clinical orders that failed to process and at least 149 documented cases of patient harm.⁽⁶⁾

A product that gets abandoned doesn’t get another chance to make a good first impression. Clinicians who struggle on day one often keep that negative view. Regaining their trust after a failed launch costs more than doing a diagnostic review up front.

Why Build Teams Cannot See Their Own Design Failures

Clinical design failures are not random; they follow patterns grounded in cognitive science and are often systematically overlooked by the teams that created them.

Cognitive load theory holds that clinical task performance depends on the relationship between sensory input, working memory, and long-term memory. Working memory has a hard ceiling. When it is exceeded, through excessive information, unclear hierarchy, or workflow interruption, performance degrades, and errors increase. A 2024 narrative review confirmed that EHR-related cognitive overload is directly linked to physician burnout and increased error rates.⁽⁷⁾ A 2026 study from researchers at Duke, Case Western, and Vanderbilt found that interface complexity, navigation burden, and workflow misalignment are the primary drivers of cognitive load, not the underlying data architecture.⁽⁸⁾

Build teams often miss these failures because they are too close to the product and too familiar with its workflows. They haven’t used it like a physician would on day one, under pressure and needing things to work smoothly. A design diagnostic creates that real-world test on purpose, with the right people watching, before users face it in practice.

How Design Failure Shows Up in Clinical Software

The symptoms are specific and consistent:

• Alert fatigue. When clinical decision support systems generate too many low-relevance alerts, clinicians begin to ignore them. One study found that tightening the criteria for a subset of medication alerts improved acceptance rates not just for the edited alerts, but for all alerts in the system. The presence of poor alerts degrades the effectiveness of every alert in the system.⁽⁹⁾
• Workflow workarounds. When software doesn’t fit how clinicians really work, they find ways around it: using notebooks, spreadsheets, skipping steps, or going back to old habits. These aren’t user mistakes; they’re design problems that often go unnoticed after launch.^(2)(10)
• Documentation overload. Physicians spend an average of more than 16 minutes interacting with the EHR for every patient encounter, more time than many visits last.⁽¹¹⁾ Within that time, clinicians average 1.4 task switches per minute, a pace of fragmentation that signifies a fundamental misalignment between what the software demands and what care delivery requires.⁽¹²⁾
• Shadow IT. When systems don’t work for clinicians, they turn to other tools. This is the last sign of design failure, and it often isn’t noticed until months later when analytics reveal it.⁽¹³⁾
• Burnout. A national physician survey found that 45.2% of U.S. physicians reported at least one symptom of burnout in 2023-2024.⁽¹⁴⁾ A systematic review and meta-analysis of over 66,000 healthcare professionals found that those who spent more time on EHR-related tasks outside of work had more than double the odds of burnout compared to those who didn't.⁽¹⁵⁾ This is a design-driven outcome. It is measurable and preventable.

Why Credibility Is a Design Problem

The part of a design diagnostic that tends to surprise clients is the explicit focus on clinical credibility, the design patterns that answer the question every clinician asks when they encounter a new clinical tool: "Why should I trust this?"

Most UX work treats trust as a byproduct of good design. GoInvo treats it as a specific, targetable problem with identifiable solutions. A clean interface isn’t enough. Clinicians need to see where the data come from, how confident the system is, and the reasoning behind the recommendations. If these signals are missing or unclear, clinicians rely on their own judgment and ignore the software.

The AI Trust Problem

This problem is acute for AI-powered clinical tools. The "black box" nature of many AI models creates a fundamental barrier to clinical adoption. Research published in the Journal of Medical Internet Research identified system transparency, usability, and the ability to contest or customize AI recommendations as the factors most consistently associated with clinician trust in AI-based clinical decision support, while algorithmic opacity and inadequate training were cited as the most common barriers.⁽¹⁶⁾

Regulations are moving in the same direction. The EU AI Act’s Article 13 requires that high-risk AI systems, including medical AI, be sufficiently transparent for users to understand their output.⁽¹⁷⁾ The FDA’s 2026 guidance requires that clinical decision support software let clinicians review the reasons behind any recommendation. If software hides its reasoning or works in situations where review isn’t possible, it doesn’t meet the standard and is regulated as a full medical device.⁽¹⁸⁾ Explainability isn’t just a design choice; it’s required for compliance.

What Evidence Visibility Requires in Practice

A design diagnostic audits the current product for clinical credibility gaps and produces design patterns for:

• Source transparency: Which studies, datasets, and data sources underlie the information being presented
• Confidence indicators and evidence grading: Not just a percentage or a colored dot, but a contextually legible signal that clinicians can evaluate in seconds.
• Clinical rationale explanations: The reasoning behind any AI-generated insight or guideline recommendation, expressed in clinical, rather than algorithmic, language.
• Override pathways: Clear, frictionless mechanisms for clinicians to document disagreement with a recommendation, maintaining both safety and clinical autonomy.

These aren’t just surface-level choices. They are the design patterns that determine whether a clinical tool becomes part of the workflow or is ignored.

The Engagement

GoInvo’s design diagnostic is a focused 4-8 week project led by senior clinical design experts, not generalists new to healthcare. The scope is kept narrow, targeting one or two high-risk clinician workflows and one key clinical credibility pattern, chosen at the start and adjusted each week as needed. Three workstreams run simultaneously because in clinical software they are inseparable:

• Clinical usability: Making workflows intuitive and frictionless for people who have to use the product under real-time pressure.
• Clinical credibility: Strengthening the signals that answer the question: "Why should I trust this?"
• Design execution: Implementation-ready improvements to visual clarity, information hierarchy, and interaction consistency.

Engagement Structure

• Phase 1: Rapid product and workflow audit. What's in scope, where are the clinician friction points, what are the highest-risk usability failures, and what does the onboarding experience actually feel like
• Phase 2: Initial concept designs. This includes interaction models for key elements such as search, guidelines, and AI insights, as well as mobile-first UI concepts for core workflows. Design patterns for evidence display and trust signals. An unbiased point of view from reviewers with no stake in the prior design decisions.
• Phase 3: Refinement. Tighter interaction design, a design and style direction establishing type, color, and component language, and an assessment of key technical considerations for AI and guidelines for interaction.
• Phase 4: Finalization. This step brings together all product flows, includes a second round of user feedback, delivers a Figma or prototype package, and ends with a direct findings session for leadership.

The project uses dynamic prioritization, adjusting the scope each week based on audit findings.

The Mobile-First Imperative

Clinical software is no longer primarily a desktop experience. A 2023 scoping review found that smartphones and mobile apps are consistently used across clinical settings for communication, clinical decision-making, and drug reference lookup, core workflow functions previously anchored to desktop workstations.⁽¹⁹⁾ Yet most clinical software is still designed desktop-first, with mobile as an afterthought.

Mobile-first clinical design is not about making things smaller. It means rethinking how users interact, considering distractions, one-handed use, changing lighting, and time pressure. A doctor checking a screen between patients is different from one at a desk. GoInvo makes mobile-first concepts a core part of the project because this difference is key to adoption.

The Decision

The HealthCare.gov red teams were right. The VA reviewers were right. The infusion pump researchers were right. In every case, the evidence was there and the findings were recorded. But the people who needed to act on them either didn’t get the information, didn’t read it, or didn’t take action.

GoInvo’s design diagnostic is designed to avoid this kind of failure. Findings go straight to decision-makers. The recommendations are clear, the evidence is specific, and the main question is answered: Are we ready to launch this product to the clinicians who will use it?

If the answer is yes, GoInvo will say so. If not, GoInvo will also tell you, along with the design evidence and a clear path to fix the issues.