Human-Centered Design (HCD) is yet another lovely-sounding buzzword that’s casually dropped in meeting rooms around the world without much understanding of what it means or how radical a departure it is from more familiar design approaches. You’re unlikely to find a developer, designer, or CIO that claims they ignore the human element in the systems and tools they build. Yet, if you look at most applications and technology-driven products, it’s clear the human was an afterthought versus the starting point for their design.
Consider for a moment that you’re asked to build a new system for approving time-off requests. A typical technology shop might approach the problem from a process perspective, determining the workflow and approval stages required for this application.
Another shop might start with data, attempting to determine what data are required, which are most important, and what information might need to be acquired from whom. A third shop might begin by considering existing systems and tools and determining if one of their technical assets could be used to create a new time-off request function.
All of these different approaches likely ask users for input or solicit the help of designers to create a technology that’s visually appealing and easy to use. However, none of these approaches started with the user, which is the crucial differentiator of human-centered design.
Rather than starting with systems, processes, or data, a true HCD approach might ask why time-off requests must be completed. Is it so a resource can be scheduled to backfill someone who is taking time off? Have there been frequent incidences of people abusing their time-off allowance, and controls must be put in place? Is there a more effective way for the humans involved to manage their time off, or a more effective way to speed approvals?
We’re all Designers
Starting with humans is complex, especially for many technology organizations. Our bread and butter are systems, processes, and data, not messy and often nuanced human beings. However, there’s a significant benefit to HCD: if you design something for the human that uses it, it’s far more likely to be adopted. Therein lies the most significant benefit to adopting HCD: it avoids delivering what amounts to a successful failure, a well-delivered system that no one uses as intended.
Often, leaders will conflate HCD with visual design, the latter being focused on aesthetics and appearance. While well-designed systems and products are often visually appealing, plenty of good-looking products are terrible to use.
Consider for a moment the products and tools that you use and love. In some cases, it might feel as if someone read your mind, and the product fits your use perfectly. The aesthetic and visuals often melt into the background as every button and interaction is right where you expect it, and use is so intuitive that you rarely need training.
Even if you don’t have formal design training, you’re still (hopefully) a human and can identify when something is complicated and counterintuitive to use. Like too many sound concepts, we’ve overengineered HCD and made it appear to be a highly specialized discipline that requires new people and tools.
There are certainly unique skills in design and research that can accelerate your HCD efforts. However, why not start with what you have today, and use the fact that all of us understand the difficulties wrought by poorly designed systems? With a bit of focus and practice, anyone should be capable of starting with the human problem rather than the technical one.
A Simple Experiment
Rather than attempting to retool your teams around HCD, identify a small project that has yet to start design or requirements gathering. Your internal team or development partner probably has a few individuals interested in HCD, or perhaps have formal experience in related disciplines ranging from visual or product design to anthropology or ethnographic research.
Pitch HCD to the project’s stakeholders as a means to create a better, more usable product. Convey that the initial design phase will be more prolonged, and might feel very different than the typical process mapping and requirements gathering meetings. It will likely be difficult to maintain focus on the human problem, but as long as you try to come back to the human that’s using your system rather than the technologies, data, or processes, you’ll be fine. You should always strive for success rather than perfection.
As you transition into testing and deployment of your new tool, assess whether HCD was beneficial. Was user testing more successful? Was less training and support required for the new tool? Did users adopt the tool and find it helpful in performing their job? Did your teams enjoy the process of trying to understand a human problem rather than being mere “order takers” capturing requirements?
The other interesting benefit to HCD is that it reduces unproductive debate during the design process. Consider how much time your teams spend speculating on what end users want, or how they’ll use a system. The questions often devolve into a battle of wills, with the loudest or most experienced person in the room imposing their hypothesis on everyone else.
With HCD, the answer to these debates can usually be found by observing and speaking with actual users. You and I might be able to debate whether one design is better than another, but it’s hard to debate what the future users of the system have told us through a combination of interviews and observation.
Adopting HCD Broadly
Just as a hammer doesn’t solve every carpentry problem, HCD should not be the only tool in your arsenal when building new systems. However, there is likely a human component to most of your critical tools, and making that element a consideration that’s just as important as the software selection or security concerns will ultimately increase your team’s effectiveness.
As you explore HCD, don’t be afraid to experiment with HCD principles with the teams you have today. Alternatively, if your partners have HCD capabilities, you can use them to accelerate your HCD efforts. These partners may already be employing HCD techniques and approaches as a natural part of their development process and will likely be happy to walk you through how they’re leveraging HCD.
Like most new approaches, if you start small and try to apply HCD to problems that it’s best equipped to solve, you’ll learn the merits and shortcomings of the approach quickly and with little risk. When applied to the right problems, HCD can deliver better programs, speed adoption, reduce costs, and even allow your team to better understand and connect with the people that are the ultimate recipients of your efforts.
