Design Thinking

Before the Backlash, Let’s Redefine User-Centered Design

We must better understand user-centered design’s limitations—not just its strengths—in the context of international development. And we must adapt it from its original uses designing commercial products to solving for social good.

In the social sector, many are hailing “user-centered design” as a revolutionary advance. It is the first of the Principles for Digital Development (defined in consultation with nearly every major global development institution) and high-profile leaders like Melinda Gates are lauding the methodology. Amid all this buzz, commercial design firms are increasingly winning international development contracts ...

...  and development practitioners are increasingly disappointed with the results.

There is a backlash on the way, and for good reason. I have too often seen people use design principles about discarding assumptions as an excuse for ignorance of historical context. I have seen designers championing “creativity” as if it compensates for their lack of experience in developing countries. User-centered design was born out of the private sector, and many in my field are starting to wonder if the methodology just isn’t right for the complex global challenges staring us down.

But: I know that user-centered design can revolutionize development work. The problem is in how we apply it. To make sure design is useful for thorny problems, we must better understand its limitations—not just its strengths—and adapt it from its original uses designing commercial products.  

If user-centered design is going to contribute to a revolution, we need to start with a redefinition.  

“User-Centered” is a Misnomer

The first step to making design useful in development practice is doing away with its myopic focus on “the user.”  

A few perceptive critics and designers have pointed out the limitations of user-centered design in recent years. My colleague Lauren Weinstein and her co-author of “Social Design and Neocolonialism,” Cinnamon Janzer, have put forth a strong argument for why focusing on the “user” is a vestige of commercial applications, inappropriate for public sector work. In their article, they argue it is an “object-centric” practice, created to design products. In contrast, development challenges usually require us to design interventions—a much more complicated category that requires the involvement of government policymakers and bureaucrats, nonprofit and development workers, business owners, service administrators, communities, ordinary citizens, and others. To encompass this broader milieu, Weinstein and Janzer call for a “situation-centered” design practice that is grounded in an understanding of the “user” as more than just one homogenous demographic.  

Consider: If you’re designing a computer mouse, your “user” is a person with two hands. But if you’re trying to design better public health services for the poor in even a single small village, your “user” includes not only “poor people,” but also the local health care providers, community leaders, the state and national governments, businesses, families, and—the most oft-forgotten—the implementing organization that will take your designs into the world.

A Less-Catchy Title, but a Better Approach

To account for this heterogeneous “end-user” in our work at Reboot, we use the following working definition for “user-centered design,” with key words in bold:  

A multi-stage problem-solving process that optimizes solutions based on users’ needs, behaviors, constraints, and operating contexts. Solutions are repeatedly tested and refined throughout the design and development process before implementation.

This definition, which may differ from others you’ve seen, tries to get at several misconceptions about user-centered design and the mistaken ways in which we have seen it applied in development. To break down those key words:

Multi-stage problem-solving: Design in development often follows a linear process, from research to design to implementation. Development practitioners recognize that this approach doesn’t work. After all, once you intervene in a system to address a problem, the system may change (and the problem may too—ideally decreasing in severity, but not always). Design provides a structured process and set of tools for continually reassessing the relevance and efficacy of the design concept at each stage; the challenge is to ensure that design follows this process even when bureaucratic processes throw up hurdles to doing so.  

Users: As discussed above, the “users” in development projects aren’t as straightforward as in commercial ones. While “citizens” or “beneficiaries” may spring to mind, it’s important to understand the diverse perspectives of all who have influence over the target issue.

Constraints: Many laud user-centered design for its consideration of user “constraints” but forget institutional constraints. This leads to “innovative” solutions that look great in a PowerPoint but that organizations simply cannot implement. A solution has to be feasible—and, better yet, easy and attractive—for the people who have to put it in place: the frontline health workers who will deliver improved health care services or the civil servants who will administer the program supporting them.

Contexts: User-centered design helps researchers zoom in on the individual. But it’s more powerful in combination with other approaches—such as macroeconomic or political economy analysis—that zoom out to understand broader systems, trends, and power dynamics.

Repeatedly tested and refined: Getting value from user-centered design requires tight feedback loops that inform regular iterations on the intervention. Our field has a lot to learn in this area: Often, we determine development “solutions” without sufficient research into the problem and context, at which point contract structures and byzantine procurement processes prevent organizations from changing course, even when it becomes clear that the solution was based on false assumptions. By contrast, design calls for research to constantly inform an evolving understanding of the problem and its possible solutions. Learning happens throughout the project cycle, while it can still affect outcomes, not just at the end of the project.

The Tools for a Revolution

There is another common criticism of user-centered design as a tool for development: that it simply isn’t new. Development practitioners are accustomed to donor- and government-led trends that promise to change everything; the parade of buzzwords begins to wear thin.  

But design really does carry the potential of revolutionary change—not because of its principles and lofty goals, which development practitioners have long known. Rather, design can contribute a set of useful tools and structured rigor that can translate these theoretical tenets into action.

Indeed, the ethos of user-centered design has much in common with the participatory/bottom-up/community-led development movements that began in the 1970s. More recently, leading practitioners have articulated some of these same ideas through Problem-Driven Iterative Adaptation, Thinking and Working Politically, and the Doing Development Differently community. The critical thought undergirding these movements is strong, yet they have struggled to articulate how development practitioners can operationalize their concepts. Practitioners often know what needs to be done, but end up not doing it. Design can teach us how to work across this gap.

We know how to agree on a set of principles. Design, judiciously applied, can help us learn how to put them into practice.

Tracker Pixel for Entry
 
 

COMMENTS

  • BY Isabelle Y

    ON August 26, 2015 01:06 PM

    Great article, Panthea! Definitely agree that when user-centered design is applied to development projects, some sort of systems mapping needs to take place in order to uncover the various pathways to ultimately reaching the end-user.

  • Thank you for pointing this out. This is what I have issues with using rapid prototyping for social solutions. They can do more harm than good. After all the road to hell is paved with good intentions.

  • Thierry's avatar

    BY Thierry

    ON August 27, 2015 05:26 AM

    Thanks for this article, which captures some important questions, especially with regards to the operationalisation of design concepts by practitioners. I have found that ‘older’ system methodologies can also very relevant to today’s design challenges; they include Soft System Methodology (SMM); Strategic Assumption Surfacing and Testing (SAST); and Critical System Heuristics (CSH). They are at the core of design thinking.

  • BY Shoshon Tama-Sweet

    ON August 27, 2015 11:34 PM

    Thanks for this thoughtful and inspiring article.  I agree that there is a great deal of difference in designing products and interventions, or in imagining that products are the way to transform social constraints. How do you rapid prototype for investments in Human Capital?  But by far the largest problem is donors- they want proven solutions and defined, accountable metrics.  Who wants to fund an NGO to ‘learn’? Virtually no-one. USAID recently put out a $25 million RFP for Ag entrepreneurs.  They would have done better to fund 10 small orgs and see who knows what they are doing.  Private foundations can be even worse- they have ideologically driven ideas of what Aid should ‘be’ and ‘do’, impervious to feedback.  Until government and foundations truly value ‘learning’ as a valid, necessary, and indispensable product, they will continue to pour resources in ‘proven’ solutions that inevitable fall short. As a small development org that wants to try new models and learn new ‘interventions’ we are in a tough spot.  If we say “We don’t have all the answers, but here are our pilots and here is what we have learned”- we will get out-competed by the org that says “We have the solution.”  Until donors value learning, they will get the same old interventions, and the same outcomes- which includes a lot of ineffective programs.

  • Interesting article that raises some good points. Through building my platform for NPOs, I have focused not only on design, but user interaction, and gamification techniques.

    Of course, there are many different segments of users, requiring a thoughtful approach. I found Nir Eyal’s writing really helpful:

    http://www.nirandfar.com/2012/03/how-to-manufacture-desire.html

    There are many others. Feel free to reach out and I can send more.

    Jason
    bstowapp.com

  • Seems like this is the very shallow end of user centred design. For one, you should never have only one user. The point of user personas is actually the way you should be approaching users, and this way you would avoid being myopic to your ‘end user’. Also, in development, the user is not always the target and the ‘customer’ (the org paying for the solution) isn’t always the user. This is why it’s important to do either a user segmentation or a creation of multiple personas interacting with the system. This way it avoids the issue that you arrive at. By this definition, you are not looking at USER centred design, rather HUMAN centred design, which I think is the important part of this approach, especially in the ICT4D realm, where this often best applies.

    Secondly, multi-stage as you say, is just the combination of user centred with agile approach. So it could then be suggested, that these two approaches should be used together. Rather than one or the other.

    Finally, more often than not, very little is actually and innovation nor is this design centred approach. What is the most important is the parallelism that exists between these practices and long existing development practices. That’s what is the most important. I don’t think this approach is about revolutionizing what we’ve been doing for a long time, rather, just about finding another lense by which we can view it. Especially when i comes to the feasibility and viability aspects of the HCD approach. This is something that is so often missed.

    Overall, the reason design thinking is so valuable, I believe, is that it looks at developing only what is necessary, is human and not feature based, and it can integrate so well into what has been best practice for years. The danger is not that it misses the weaknesses, it’s that it’s implemented by people who think it’s new, with little experience and understanding, but with the right people, using a capacity approach, it has a great deal of value beyond what is so shallowly outlined here.

  • It is very unclear what definition of User-Centered Design (UCD) this author is taking an issue with. As defined by ISO 924-210:2010(en), User-Centered Design “Aims to make systems usable and useful by focusing on the users, their needs and requirements, and by applying human factors/ergonomics, and usability knowledge and techniques.” 

    I think the author should start to look into some historical contexts and the grounding for UCD. Particularly, please gain an in-depth understanding of Human Factors and Ergonomics.  Within Human Factors, we are always gaining insights into our user populations, their capabilities, limitations, operational environment, as well as social environment.  It is not an isolated view of simply looking only at a user, but instead understanding the entirety of the context within which they operate, to include their organizations and cultures. It is only with this full understanding that we can successfully design anything (training, products, etc.). Remember, in this definition from ISO it describes “systems” which is much more inclusive than just a technology.  A system includes the full context of operation, to include the design of the entirety of operations, inclusive of procedures, users’ interactions with others, interactions with technology, and training. Only with a holistic understanding of the full context of use, as well as the user populations themselves, have we practitioners of Human Factors ever thought a “system” can be design appropriately.

    This article points to buzz words being used incorrectly in multiple situations. I implore the author to also evaluate the true meaning behind terminology they take issue with to ensure they accurately understand what they are taking issue with.  It appears as if they are taking more of an issue with an incorrect application of UCD as apposed to UCD itself.  I do not feel that we need to introduce additional “buzz words” within our field of practice (many of us feel we have too many already), but instead more accurately educate practitioners in terms of what these terms mean and how they should actually be applied.

Leave a Comment

 
 
 
 
 

Please enter the word you see in the image below:

 

SSIR reserves the right to remove comments it deems offensive or inappropriate.