Human-Centered Design for Public Health: Designing With, Not For Communities
Public health has an adoption problem. Well-designed programs with strong evidence bases fail because people don't use them. Services go underutilized. Interventions are abandoned.
The problem often isn't the science—it's the design. Programs designed by experts for communities frequently miss what communities actually need, want, and can use.
Human-Centered Design (HCD) offers a different approach: start with empathy.
Introduction to HCD in Public Health
The Expert Model Problem
Traditional public health assumes experts know best:
- Epidemiologists identify the problem
- Program planners design the solution
- Communities receive the intervention
This model produces technically sound programs that often fail in practice because they don't fit people's lives, values, or constraints.
The Human-Centered Alternative
HCD flips the process:
- Start with deep understanding of users
- Co-design solutions with community members
- Test and iterate based on real experience
- Prioritize usability alongside effectiveness
The Double Diamond Process
HCD follows four phases, visualized as two connected diamonds:
Diamond 1: Define the Problem
- Discover: Broad exploration of the problem space
- Define: Narrow to specific, actionable problem statement
Diamond 2: Develop the Solution
- Develop: Broad generation of potential solutions
- Deliver: Narrow to refined, tested solution
Each phase alternates between divergent thinking (exploring widely) and convergent thinking (focusing narrowly).
HCD and CBPR: Complementary Approaches
Human-Centered Design and Community-Based Participatory Research (CBPR) share values but emphasize different aspects:
| CBPR Focus | HCD Focus | |------------|-----------| | Power and equity | Usability and experience | | Community ownership | User needs | | Research ethics | Design iteration | | Policy change | Product/service design |
Integrated Approach: Use CBPR principles to ensure equitable partnerships while applying HCD methods to create usable solutions.
Empathy Mapping
Walking in Users' Shoes
To design for users, you must understand their experience. The Empathy Map is a tool for organizing this understanding across four dimensions:
Says: What users express verbally
- Quotes from interviews
- Stated preferences and concerns
- Questions they ask
Thinks: What users believe (may differ from what they say)
- Assumptions and mental models
- Concerns they don't voice
- Motivations driving behavior
Does: Observable behaviors
- Actions taken or not taken
- Routines and habits
- Workarounds and adaptations
Feels: Emotional experience
- Fears and anxieties
- Frustrations and satisfactions
- Hopes and aspirations
Finding Contradictions
The most valuable insights come from contradictions between quadrants:
"The user SAYS health is their top priority, but they DON'T get regular checkups."
This contradiction points to something interesting:
- What barriers prevent action aligned with stated values?
- What unstated factors influence behavior?
- What would make it easier to act on priorities?
Data Sources for Empathy Maps
Build empathy maps from:
- Interviews with target population members
- Observation of behaviors in context
- Focus group discussions
- Survey open-ended responses
- Social media analysis
- Existing qualitative research
Persona Development
From Data Points to People
Aggregated data obscures individual experience. Personas are fictional characters that bring data to life:
Weak Persona:
"Maria is a 45-year-old Hispanic woman with diabetes."
Strong Persona:
"Maria, 45, works two jobs to support her family—the early shift at a hotel and evenings cleaning offices. She was diagnosed with Type 2 diabetes three years ago but struggles to manage it. She knows she should eat better and exercise, but by the time she gets home at 9 PM, she's exhausted, and fast food is the only thing open. Her mother had diabetes and lost her leg to complications, which terrifies Maria. She wishes she could take better care of herself, but she doesn't see how it's possible with her schedule. She doesn't trust doctors much—her mother followed doctor's orders and still got sick."
Evidence-Based Personas
Personas must be grounded in data, not stereotypes:
Building from Evidence:
- Identify patterns in assessment data
- Create persona skeleton from common characteristics
- Add specific details that humanize without stereotyping
- Validate with community members
- Revise based on feedback
Avoiding Stereotypes:
- Base on actual data, not assumptions
- Include counter-stereotype details
- Represent diversity within segments
- Have community members review for accuracy
Using Personas in Design
Personas guide design decisions:
"Would Maria be able to use this service? Can she get there with her schedule? Does the language resonate with her concerns? Does it address her fear about her mother's experience?"
Journey Mapping
Health Behaviors in Sequence
Health behaviors don't happen in isolation—they occur within the context of daily life, across time and touchpoints. Journey Maps visualize this experience.
Current State Journey Map
Map the user's experience as it currently exists:
Components:
- Phases: Major stages of the health journey
- Actions: What the user does at each phase
- Touchpoints: Where they interact with services/systems
- Thoughts: What they're thinking
- Emotions: How they feel (often shown as emotional curve)
- Pain Points: Barriers and frustrations
- Moments of Truth: Critical decision points
Example: Diabetes Screening Journey
| Phase | Action | Touchpoint | Emotion | Pain Point | |-------|--------|------------|---------|------------| | Awareness | Sees screening poster | Community center | Curious but skeptical | "Is this for people like me?" | | Consideration | Asks friend about experience | Social network | Uncertain | Friend had bad experience | | Decision | Looks up clinic hours | Website | Frustrated | Website hard to navigate | | Access | Tries to schedule appointment | Phone system | Annoyed | Long hold times, no evening slots | | Arrival | Goes to clinic | Clinic waiting room | Anxious | Forms in English only | | Service | Gets screened | Exam room | Vulnerable | Rushed interaction | | Follow-up | Receives results | Phone call | Confused | Medical jargon, no next steps |
Identifying Intervention Opportunities
Journey maps reveal:
Pain Points: Where experience breaks down
- These are opportunities to remove barriers
Moments of Truth: Where decisions get made
- These are opportunities to influence choices
Emotional Peaks and Valleys: Where feelings are strongest
- These shape memory and future behavior
Ideation and "How Might We"
From Problems to Possibilities
Having understood users deeply, it's time to generate solutions. But problem framing matters.
Closed Problem Frame:
"People don't get screened for diabetes."
Opportunity Frame (How Might We):
"How might we make diabetes screening fit into Maria's 9 PM schedule?" "How might we reduce Maria's distrust of healthcare providers?" "How might we make the screening experience feel less clinical and more supportive?"
The "How Might We" Format
Transform pain points into opportunities:
Pain Point → HMW Question:
- Long hold times → "How might we eliminate the need to call for appointments?"
- Forms in English only → "How might we communicate without language barriers?"
- Rushed interaction → "How might we make the screening experience feel unhurried?"
Divergent Thinking Techniques
Generate many ideas before judging any:
Brainstorming Rules:
- Defer judgment (no critiquing during ideation)
- Encourage wild ideas (they spark practical ones)
- Build on others' ideas ("Yes, and...")
- Aim for quantity (more ideas = more raw material)
Structured Techniques:
- SCAMPER: Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Reverse
- Analogies: How do other fields solve similar problems?
- Extremes: What if we had unlimited budget? Zero budget?
- Reversal: How might we make this problem worse? (Then reverse)
Convergent Thinking: Prioritization
After generating many ideas, prioritize:
Impact vs. Feasibility Matrix:
- High impact, high feasibility → Do first
- High impact, low feasibility → Plan for later
- Low impact, high feasibility → Quick wins if resources allow
- Low impact, low feasibility → Don't do
Dot Voting: Give team members limited votes to distribute across ideas
User Desirability: Which ideas would Maria actually want?
From Ideation to Design
Selecting Ideas for Development
The best ideas:
- Address real user pain points
- Are feasible with available resources
- Align with organizational capacity
- Build on existing community assets
- Have potential for sustainability
Preparing for Prototyping
Before building, clarify:
- What specific user need does this address?
- What would success look like?
- What are the riskiest assumptions?
- What's the simplest version we could test?
Next week's content covers prototyping and testing—turning these ideas into tangible interventions that can be validated with real users.
Continue Your Learning
This article is part of an 8-week course on Adaptive Program Planning in the Digital Age. Learn systems thinking, AI-augmented assessment, Human-Centered Design, and Agile implementation for modern public health practice.