As the saying goes: “if you think technology is the solution, you don’t understand the problem”. The same goes for technologies for civic or public service purposes. In fact, many argue that a common trait of good professionals working in the digital space is their capacity to, whenever necessary, politely convince their counterparts that their new “app” idea sucks.
Over time, practitioners will develop their own intuition and tricks of the trade to assess what should be built or not, and if so, how. That knowledge is mostly shared within networks of practitioners, sometimes through a few humorous tips, such as: “If building a dashboard is the first thing a government official asks you, run for your life!”
But this kind of tacit knowledge remains mostly contained and fragmented across small groups, and it is rarely translated for the benefit of others in an accessible manner. And these others are often the ones who come up either with the ideas, the money to fund the ideas, or both.
Construct a monstrous building in the middle of nowhere and movies might be made about you; build a pointless app that no one uses and you will just need to cite a misleading metric in a donor report and no one will care. Conversely, construct a good building in a sensible place and no one will think it worthy of notice; build a not-terrible app that people use for longer than the launch press release circulates, and you will immediately be nominated to half a dozen “X under X” lists.
So, by far the best method is to adopt a simple principle: Don’t build it.
When someone says, “We should build some tech for that”, just say no. When an investor or donor says, “Why don’t you build some technology”, just say no. When you read another article or see another TEDx talk about someone pretending their app achieved something, while citing numbers that are both unverified and meaningless, and a voice inside says, “why don’t we also build technology”, just say no.
Does that mean that the rest of this guide is pointless? Hopefully so. But in reality, at some point some idea may gather such momentum or such force of conviction that the “do not build it” ethos will start to falter. At that point, ask these questions…
I will stop here. In short, this guide is a must-read for anybody designing, implementing, funding or just coming up with “disruptive” ideas on technologies for civic engagement and public service delivery.
Ps.: The teaser for the guide, is itself priceless:
Have you ever found yourself in a situation where you’re pulling on a door marked “pull” only to realize that you have to “push” to open it? These ubiquitous poorly designed doors are called “Norman doors” that both confuse and embarrass door openers.
Online, certain experiences are not so different from physical Norman doors. Imagine that you are trying to accomplish a task online, such as requesting a service or paying a bill, but you just cannot understand what you have to do to get it done. It’s not your fault: you have just been victim of bad user experience (UX) design.
Less visible to the public, civil servants themselves are also victims: software developed to conduct simple and menial tasks are so poorly designed that training to use them is required. In the worst, and unfortunately common scenario, civil servants refuse to adopt a new piece of software, despite training that often substitutes for real change management to usable digital processes. And behind narratives of “resistance to change” and “poor ownership” of software, often hides poor UX design; something that cannot be solved by decrees or dollars alone.
In the private sector, poor UX gets you out of business. In the public sector, exceptions apart, users are blamed for low uptake. But it doesn’t always have to be this way.
Enter UX research and design
The term user experience was coined in 1993 by the famous cognitive psychologist and designer Don Norman, while conducting human interaction research and application at Apple Computers. As put by Norman, going beyond human-computer interaction, user experience covers “all aspects of the person’s experience with a system, including industrial design, graphics, the interface, the physical interaction, and the manual.”
In the private sector, the concept of user experience has been operationalized through user research. In general, the term user research refers to a continuous research process, that allows to learn about users and create services that increasingly meet their needs. Focusing on understanding users’ behaviors, needs, and motivations, user research employs a number of methods, such as card sorting , task analysis, and usability testing. Companies like Google, Netflix and Airbnb take user research seriously, dedicating sizeable budgets to these activities. There are good reasons for this: research estimates that on average, every dollar invested in UX brings 100 in return , an ROI of 9,900%, with firms considering UX capacity “a matter of survival”.
A growing number of governments are starting to give UX research the attention that it deserves, such as the UK’s Government Digital ServiceUnited States Digital Service Unit, and Team Digitale in Italy, to cite a few. A smaller number of governments in lower- and middle-income countries are also starting to embrace this approach. For example, Argentina’s government created a new digital driving license, replacing physical cards with a digital document stored on users’ smartphones. Through a combination of user research and agile software development, the government delivered the new license in 65 days. In a similar vein, in Moldova, the combination of user research and process reengineering led to the elimination of several steps for parents’ enrollment in the country’s child care benefits program: workload for enrollment and processing benefits were reduced by 70%, dramatically reducing the time for benefits to reach the families.
Service design and the empathy gap
Studies by cognitive scientists and psychologists consistentlyreveal an empathy gap where decision-makers overestimate the similarity between what they value and what others value. Part of this effect stems from decision-makers’ natural incapacity to put themselves in someone else’s shoes. In this respect, one of the core functions of user research is precisely bridging this empathy gap, allowing the researcher to better capture the user’s perspective.
If by now user research should be a prerequisite for the design of any services, this is even more true for services in developing countries. This is so because, the more different the realities of two individuals, the larger the empathy gap between the two of them. This includes socio-economic background, including age, gender, ethnic background, or disabilities, as well as digital literacy. And all else equal, the less developed a country the less likely public services are designed by people who use them, or who share experiences that are closer to that of the end-users. In that case it is common to find, for instance, designers of public transport systems who use private drivers and health experts who never received treatment in a public hospital. The result are services built on a larger empathy gap, conceived by people whose frame of reference is even more distant from everyday users.
If governments are willing to deliver digital services that truly add value to their users, they will have to start paying significantly more attention to user research than they currently do. In practice, closing the empathy gap requires a number of steps that are worth highlighting. First, governments should be directly employing public servants who have skills in user research, combined with professionals with additional Internet-era skills such as digital design and agile project management. Second, governments should adopt a “users’ needs” first approach when prioritizing which services are digitized. That is, instead of relying on a checklist approach to ‘eServices’, governments let user research guide them on which services should be digitized. Finally, governments should abandon the number of services provided as a measure of success and instead, focus on the number of users who get services that are faster, cheaper and more efficient.
We are cognizant that for some government and development professionals, these three steps may be considered a tall ask. But that’s the only way forward if we want to avoid reproducing digital Norman doors, wasting resources and further frustrating public service users.