Digital health products present a tougher design challenge than most software: the people using them are often ill, exhausted, anxious, or managing a condition alongside a full life, while the clinicians on the other side are short on time between patients. Design choices that create minor friction in a consumer app can become the reason a patient drops a care plan or a provider declines to adopt a tool. We lead the user research and product design work that identifies these issues before engineering builds around them.
The Challenge
Your product must work for people who are not at their best, but most design processes are not made for that
A consumer app can assume a motivated, attentive user with time to explore. A digital health product cannot make that assumption – the patient using it may be managing a new diagnosis, dealing with pain or fatigue, or simply older and less comfortable with technology. Interfaces that rely on discovery, dense navigation, or clever-but-unlabeled icons lose exactly the users who need the product most. Designing for health literacy and cognitive load under stress is a different discipline than designing for engagement, and skipping it shows up as drop-off in the first session.
You are designing for at least three distinct users at the same time, and they do not share the same mental model
A typical digital health product has to serve patients, clinicians or care teams, and often a payer or employer administrator, and each group approaches the same workflow with a completely different frame of reference. A patient wants reassurance and simplicity; a clinician wants speed and wants the tool to fit inside a visit that is already too short; an administrator wants oversight and reporting. Building one interface that quietly assumes a single persona is how you end up with a patient-facing screen that reads like clinical documentation, or a clinician tool that buries the one field they need behind three taps.
Growth-stage teams continue shipping unvalidated features, and the resulting debt compounds into churn
Once a digital health company has funding and a roadmap, the pressure to ship outpaces the discipline to research first. Features get built from internal assumptions or a single loud customer request, then launched without usability testing against the actual patient or provider population. Some of them get used correctly, some get worked around, and some get ignored – but without a research practice, the team cannot tell which is which until adherence data or support tickets make the problem impossible to ignore. By then the fix is a redesign, not a tweak.
Marketing and acquisition budgets are wasted on a product that cannot retain the users it converts
A VP of Marketing can run a flawless acquisition strategy and still watch retention numbers stall because the onboarding flow or core workflow was never usability-tested against real patients or providers. In digital health this is worse than in most categories because acquisition costs are high and the sales or enrollment cycle is long, so a leaky product wastes not just ad spend but months of pipeline work. No amount of demand generation fixes a product that loses users at the first confusing screen.
How We Help
We begin with a research audit to separate what you truly know about your users from what the team assumes. Most digital health companies have some data – support tickets, App Store reviews, a few sales calls with clinicians – but lack a structured research program that connects those inputs to product decisions. We then conduct patient and clinician interviews and usability testing on current screens, basing recommendations on what users actually do instead of what they report in a review call.
The design work follows the research, rather than the reverse. We create information architecture and interaction patterns around health literacy and accessibility, while designing clinician-facing surfaces for speed instead of expecting a busy provider to learn a new system.
During execution, we embed with your product and engineering teams rather than delivering a deck and vanishing. We join sprint planning and design reviews so decisions consider build constraints, and compliance or clinical stakeholders contribute before the design is complete, not afterward.
To measure performance, we monitor the behavioral signals that show whether a design works: task completion rates, onboarding completion, feature adoption by user type, time-to-value, and usability-related support ticket themes.
What distinguishes us is that we approach product design and user research as a single connected discipline, not as a design team creating screens on demand. Success in digital health product requires validation with the actual patient and provider population before engineering time is committed, and that is the work we lead.
What we deliver
- User research program – patient and clinician interviews, contextual inquiry, and usability testing structured around your actual open product questions
- Persona and workflow maps built from real research, distinguishing patient, clinician, and administrator needs rather than a single blended user
- Information architecture and design system built for health literacy, accessibility, and clinical time constraints
- Prototype validation before engineering investment – clickable prototypes tested with real users prior to build
- Embedded collaboration model with product, engineering, and clinical or compliance stakeholders throughout design
- Behavioral measurement plan – task completion, onboarding completion, adoption by user type, and support ticket themes
In digital health, the greatest product risk is not a feature that is missing – it is requiring a stressed patient or time-starved clinician to learn something unfamiliar. Research that identifies this before building begins costs less than redesigning after adherence data confirms it.
Our Methodology
We deliver product design and research through a 90-day sprint that creates an ongoing practice. The first 30 days center on research: interviews and contextual inquiry with patients and clinicians, a review of existing usage data and support signals, and a prioritized list of workflows driving the most drop-off or low adoption. Days 30 through 60 shift into design and prototyping – information architecture, interaction design, and clickable prototypes for the highest-priority workflows, all tested with real users before reaching engineering. Days 60 through 90 concentrate on handoff and measurement – design specifications integrated into your engineering process, plus an instrumented behavioral measurement plan that shows whether the redesigned workflow improves completion and adoption after launch.
The difference from a standard design agency engagement is the sequence: research precedes design, and real patients and clinicians validate the design before it reaches engineering. Screens are not simply approved through internal review and shipped on faith. We also design around constraints unique to digital health – health literacy, accessibility, clinical time pressure, and compliance review – rather than using generic consumer-app patterns for a population that does not fit consumer-app assumptions.
Our Approach
The opening 30 days emphasize research. We recruit patients and clinicians for interviews or contextual inquiry sessions, review existing behavioral and support data, and provide a prioritized list of the workflows creating the greatest costs in drop-off, adoption, or adherence. You receive a candid assessment of which product assumptions the research supports and which fail to hold up.
Days 30 through 60 center on design and validation. We develop information architecture and interaction design for the priority workflows, create clickable prototypes, and test them with real patients or clinicians before anything reaches engineering. We need your team to provide access to users for research, current analytics or support data, and a product or engineering lead who can participate in design reviews so decisions reflect build constraints.
Days 60 through 90 move toward handoff and measurement. We bring design specifications into your engineering workflow and instrument the behavioral metrics – task completion, onboarding completion, adoption by user type – that reveal whether the redesign performs once shipped. Most engagements continue beyond the first 90 days because digital health product roadmaps are ongoing, and a single research pass rarely addresses every workflow that requires attention. Typical continuing engagements last three to six months, with an option to extend.
Our cadence combines a weekly working session with your product and engineering leads with async delivery of research findings, prototypes, and design specs as each becomes ready. We integrate into your current sprint cycle rather than operating a separate design process on an independent timeline.
- Improved onboarding and task completion rates
- Higher provider adoption of clinician-facing workflows
- Better patient adherence to care plans and product-driven protocols
- Reduced support tickets tied to usability confusion
- Design decisions validated before engineering investment, cutting rework
If your digital health company needs product design & research leadership, we should talk.
Expand your marketing team output with our experts
Let us take a custom approach to your growth goals by assembling and leading the best-in-class marketing team to support your next stage.
Frequently asked questions
What does a product design and research engagement cost for a digital health company?
We determine pricing based on the number of workflows, the research depth needed, and whether we must recruit patients and clinicians or can use an existing user base that you provide access to. A targeted engagement covering one or two workflows costs less than a wider research and design practice.
How soon will we see results from a product design and research engagement?
Research insights and a prioritized workflow list generally arrive during the first 30 days. Validated prototypes for the priority workflows come in the following 30, after testing with real users and before engineering begins building.
How does the design and research team collaborate with our current product and engineering staff?
We operate as an embedded partner, joining your sprint planning and design reviews instead of providing a static deliverable when the engagement ends. Your product and engineering leads remain involved throughout, ensuring design decisions reflect actual build constraints, while handoff to engineering uses your current process rather than adding a separate one.
How is Winston Francois different from a standard UX design agency for digital health?
A standard design agency develops screens from a brief and stakeholder review. We first conduct structured research with real patients and clinicians, test design directions through prototypes before engineering builds, and remain embedded during handoff so the final design reflects actual behavior instead of internal assumptions about user needs.
How is ROI measured for a product design and research engagement?
We measure behavioral outcomes directly connected to the workflows we redesign – task completion rate, onboarding completion, feature adoption segmented by patient, clinician, or administrator user type, and usability-related support ticket themes. We compare these with a baseline established before the engagement, allowing improvements to be attributed to specific workflow changes instead of aggregate product metrics that may shift for unrelated reasons.
What type of digital health company is best suited to this service?
This service is suited to digital health companies in roughly the 5M to 100M ARR range that already have a product in market and real usage data or access to users for research – usually companies serving patients together with clinicians, care teams, or payer administrators, where multi-user complexity presents the toughest design challenge. It is not a good fit for a pre-launch concept with no users available to research.
