Equip Health Workers

Software tools are used by large organizations supporting thousands of frontline health workers, as well as local organizations and clinics. Learn more about your deployment options.

Explore the Tools

Learn more about the latest software for community health.


Are these 5 myths stopping you from using human-centered design?

IMG 2683

May 12, 2015

Author: Dianna Kane

As Human centered-design (HCD) has become a frequent topic of conversation in the global development world, many program managers are left wondering how to operationalize such an open-ended and iterative approach. Many express feeling like they can't do HCD without their donor's blessing or having it explicitly defined in a scope of work, budget or timeline.

HCD has always been intrinsic to the way that Medic works, but it hasn't always been easy. Over the years, we've struggled with many obstacles to making space for design in our projects and product development.

While it's ideal to have a donor that gives you the flexibility to iterate and refine your intervention as you learn, HCD methods can be integrated into all phases of a program to add value to your existing activities, whether you are designing a product, service, or delivery mechanism.

MYTH 1: Design isn't critical for my software project.


Design is absolutely necessary to make sure you're building the right thing.

Design is a part of software development. Designers generate user stories to translate needs into technical requirements in a language the developers can understand. Design considers important questions pertaining to who is using the product and why, which often elicits hidden requirements that may affect developer timelines and budget. At times, we've packaged design work within the software development budget, rather than calling it out explicitly.

Method: User Stories (think Mad Libs). From the perspective of your user, generate as many of these statements as possible:

As a _________ [Nurse, Community Health Worker, Ministry of Health Official], I need __________ [state what this person is trying to accomplish], so that ____________ [state why accomplishing this task matters to this person].

Your developers will understand what the widget you have asked them to build needs to do, and may even come up with time- and cost-saving solutions to help you achieve your stated goals.

MYTH 2: I can't afford to change my intervention or project.


In reality, you and your donor can't afford not to change your project. You can't afford to build or implement the wrong things.

Pro tip: Be impact-oriented. Get on the same page with your partner or funder about the change that you're working towards together. Instead of championing the app or program you are creating, focus on the impact and health outcomes you have committed to achieving. This creates some space for iteration as to the details of the intervention. Partners will relax knowing that the solution you design will help them reach their goals. It also positions your team as thought-partners who are invested in the community's success.

Methods: Current System Sketches. Draw out the system the way it is currently operating, marking pain points along the way. Do not jump to conclusions immediately. For example, if your goal is to increase skilled attendance at deliveries, your intervention should address the greatest barrier to this. System sketching provides a map for where to invest your energy. In the case of skilled birth attendance, it could be to register and develop birth plans for all pregnancies in the community, improve emergency transportation services, or develop a network of home-based midwives.

MYTH 3: Design is a perfectionist's game and only helps with nice-to-have, superficial changes.


Drawing by Katherine Haugh of TechChange

Great design makes technology usable and ensures that interventions have the intended impact.

From user insights, designers establish design principles that contextualize a product or service within a user's environment that position it to be successful. Is a nurse logging on to your system at the end of the day when she is tired? Is she doing so to close out her work for the existing day or plan for the next? Is the room well-lit? How likely is it that her computer screen is low-resolution? Is her glasses prescription out-of-date? Designer translate these insights into tangible improvements that make the product or service easier and friendlier for the user to use.

Methods: User Personas, Design Principles. A user persona is a character that epitomizes your target audience. Understanding this person, including their preferences, motivations, and priorities yields important insights into how your product or service can best fit their daily workflow and lifestyle.

In turn, design principles are rules that your intervention must abide by to satisfy your users. For example, we know that our "Nurse Mary" persona is often scared of accidentally deleting important information in health technology systems. As such, "I feel safe using Medic Mobile" is a design principle we strive to achieve, and we build many checks and safeguards into our user experience as a result.

MYTH 4: This all sounds great, but we can't do design because we didn't budget for design activities.


If you have budget for a meeting, you have budget for a design workshop.

Every meeting with potential users or stakeholders in an opportunity for design. Rather than presenting a project plan to stakeholders in a didactic manner, reframe your meeting to invite participants into helping solve the challenge at hand. Use this as a chance to test your ideas, look for gaps or potential pitfalls, and strengthen your product or intervention.

Methods: Role-playing, Sketch cards. We love role playing because it lets us see our product in action in a range of situational environments. Asking users to act out your product's use or your program's service journey in the context of their daily lives provides insights into the challenges they may encounter beyond the interaction with your intervention.

Users will often try to "break" the design and introduce challenges into the storyline, such as power outages, rain-logged roads, and familial power dynamics. This is a great opportunity to get ahead of those challenges and troubleshoot or redesign together. Medic has created a deck of "design cards" to achieve this purpose as well. The cards allow users to walk through storylines and co-create solutions by adding or removing elements to the workflow.

MYTH 5: The project is over; we missed our chance.


Not so fast. You can still package your insights to inform future design.

So many pilots are shared with the details pertaining to their specific context only. Those of us who are embarking upon similar projects often have to design from scratch because we don't how to apply these lessons to our setting. If we think like designers and open up our thought processes, we would include how the particularities of a place or user group caused us to make certain decisions about an intervention, stories of where we were disproven along the way, and clues as to how other designers might adapt the intervention to fit a different kind of context or user group.

Methods: Personas, Iteration Documentation. As described above, personas are an important tool for designers. They ground us in who an intervention is intended to serve. If we can share how the values, workflow, or preferences of our persona influenced the design of our intervention, other designers can quickly see how changes to that persona might require a different design to achieve the same end goal.

Using the example above, if your Nurse Mary is not afraid of technology but rather prioritizes ultimate flexibility to access the data for her needs, you might choose to ease up on the confirmation steps built into your platform and rather give her an expanded set of export and analysis options. However, you might not have understood this dimension of your user at all had our project not identified it as an area worthy of consideration. By sharing our processes and insights, we can all make each other better designers, and we'll produce stronger projects and products as a result.

Dianna Kane is Medic Mobile's Senior Designer. She can be found asking "What Would Nurse Mary Do?" on product calls, running design workshops with our users and field teams under a tree, or gazing at the Golden Gate Bridge from her desk. This presentation was given at the CORE Group on best practices for managing HCD programs.

No. 79 of 83