Beyond just talking about human-centered design

This week the DC Tech Salon, a monthly conversation at the intersection of technology and development, tackled the subject of how design thinking can improve development. Perhaps unsurprisingly, the consensus seemed to be that principles of human-centered design – focusing on users from the start, prototyping and failing rapidly, iterating toward success (more fully summarized here) – could be quite useful in the development context; at the very least, it seemed that design thinking could improve many development programs, and at the very most it could save them from all-too-common sources of failure. There was even some optimism that donors might be starting to foster better incentives for solutions that actually succeed and scale (vs. fulfill some prescribed requirement in an RFP).

The designers in the room did a great job articulating the value-add of designers, design firms, and their profession overall, and they made very clear that design is a serious business: while the principles sound simple enough, actually putting them into practice requires hard work and, often, skilled designer-facilitators. But how many in-country teams can realistically afford to engage a U.S.-based design firm, fly them out to prototype and facilitate, etc.? This question seemed to hang over the entire event, and the implicit answer seemed to be: good design can be expensive, but it’s worth it. (And good news: you don’t have to necessarily hire design firms, you can directly staff designers on your team instead!)

But given our focus here at Dobility, I got to thinking about how existing project and in-country teams might be empowered to put the principles of human-centered design into use themselves, without having to spend lots of money or re-imagine their team compositions. After all, good design can make or break a survey instrument as easily as it can make or break a mobile app, and the fact is that more and more organizations are using our SurveyCTO platform for applications that are less like surveys and more like mobile apps anyway (e.g., for food aid registration and distribution, health facility inspections and mHealth applications, focus group facilitation, crowd-sourcing of sign-language dictionaries, you name it). So how can our users do more than just talk or dream about human-centered design? How can they really put it into practice?

It turns out that there are some fantastic resources available for teams that want to adopt the core principles and processes of human-centered design (like IDEO’s toolkit), but one key technical difficulty involves prototyping: how on earth are you supposed to quickly prototype and iterate a solution? For cases where mobile technology is being used, wouldn’t this require a crack team of developers on standby to prototype, revise, and iterate? That sounds really expensive and basically impossible for all but a few projects.

But then I realized that many teams in fact have the internal capacity to prototype and iterate themselves – including every one of our SurveyCTO users. For them, the process might look something like this:

1. Learn. Go out and spend time in the target community, to get to know potential users, their needs, their constraints.
2. Brainstorm. Come back and brainstorm design for the survey, app, or overall activity. Identify key elements of the workflow.
3. Prototype. With SurveyCTO, this can be literally an hour or two of form design in Excel or Google Sheets: don’t worry about field validation or how the data will be organized, focus on the overall workflow and on key tasks. For example, if you need to scan a barcode or take a picture, when, where, and how does that happen?
4. Test. Take your prototype to the community and test it out. Does the workflow work at a basic level? Where does it break down? And are there circumstances in which different workflows might be a better fit? Ultimately, whether users are enumerators, inspectors, nurses, or community health workers, does the prototype seem to meet their needs?
5. Iterate. Revise and elaborate the prototype. Add more intelligent skip patterns to handle different cases, hyperlinks when you want users to have more control over the sequence of things. Start to think and care more about the specifics, including the data that gets captured: is it the right data in the right format? Starting with SurveyCTO v1.40, revisions to existing forms are easy – so take advantage. Use as many test-feedback-revise cycles as your problem requires and your timeline allows.

Obviously, no project has a blank check and an open-ended timeline – so the ideal of iterating as much as required is just that, an ideal. Even just a single iteration of this process can be a huge improvement over the alternative of designing something in one go, largely in a vacuum. Just one honest test of a survey, form, or app can provide a wealth of learning and a tremendous opportunity to improve. Surely every team can at least aspire to that much.

And here at Dobility, we’ll aspire to get better and better at designing SurveyCTO as a platform that empowers teams to better design their surveys, tools, and apps. It’s a kind of meta-design challenge: to design for designers. We’ve already taken care of some of the fundamentals (like the ability to more easily revise existing forms), but there are many ways that we can still make prototyping and monitoring feedback easier and more rapid. We’re on the case, but we can always use your feedback. Let us know your ideas for how our platform can better facilitate your efforts at excellent design. We want to help you to get beyond just talking about human-centered design.