The importance of human-centered design in software development

Human-Centered Design (HCD) is yet another lovely-sounding buzzword that is thrown around casually in boardrooms 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 who claims to ignore the human element in the systems and tools they build. However, if we look at most technology-driven applications and products, it is clear that the human was an afterthought rather than the starting point for their design.

Consider for a moment that you've been asked to create a new system for approving time off requests. A typical tech 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, trying to determine what data is needed, what is most important, and what information might need to be acquired from whom. A third shop could begin by considering existing systems and tools and determining whether one of their technical capabilities could be used to create a new time-off request function.

All of these different approaches likely ask for input from users or help from designers to create technology that is visually appealing and easy to use. However, none of these approaches started with the user, which is the crucial differentiator of human-centered design.

Instead of starting with systems, processes or data, a true HCD approach could ask why time off requests should be completed. Is this how a resource can be scheduled to fill in for someone taking time off? Have there been frequent incidents of people abusing their time off allowance and should controls be implemented? Is there a more effective way for the humans involved to manage their time off, or a more effective way to speed up approvals?

We are all Designers

Starting with humans is complex, especially for many technology organizations. Our bread and butter is systems, processes and data, not messy and often nuanced human beings. However, there is a significant benefit to HCD: if you design something for the human who uses it, it is much more likely to be adopted. Therein lies the most significant benefit of adopting HCD: it avoids delivering what amounts to a successful failure, a well-delivered system that no one uses as intended.

Often, leaders confuse HCD with visual design, with the latter focusing on aesthetics and appearance. While well-designed systems and products are often visually appealing, many beautiful products are terrible to use.

Consider for a moment the products and tools you use and love. In some cases, it may seem like someone has read your mind and the product adapts perfectly to your use. Aesthetics and visuals often take a backseat, as every button and interaction is exactly 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 being and can identify when something is complicated and counterintuitive to use. As with many solid concepts, we over-engineered HCD and made it seem like a highly specialized discipline that requires new people and tools.

There are certainly unique design and research skills that can accelerate your HCD efforts. However, why not start with what you have today and take advantage of the fact that we all understand the difficulties caused by poorly designed systems? With a little focus and practice, anyone should be able to start with the human problem rather than the technical problem.

A simple experience

Instead of trying to retool your teams around HCD, identify a small project that has not yet started design or requirements gathering. Your internal team or development partner likely has a few individuals interested in HCD, or perhaps has formal experience in related disciplines, from visual or product design to anthropology or ethnographic research.

Present HCD to project stakeholders as a means of creating a better, more usable product. Convey that the initial design phase will be longer and may look very different from typical process mapping and requirements gathering meetings. It will probably be difficult to stay focused on the human problem, but as long as you try to get back to the human being using your system, rather than the technologies, data, or processes, you'll be fine. You should always strive for success and not perfection.

As you transition to testing and deploying your new tool, evaluate whether HCD has been beneficial. Was user testing more successful? Was less training and support needed for the new tool? Have users adopted the tool and found it useful in carrying out their work? 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 of HCD is that it reduces unproductive debate during the design process. Consider how much time your teams spend speculating about what end users want or how they will use a system. Issues often turn into a battle of wills, with the loudest or most experienced person in the room imposing their hypotheses on everyone else.

With HCD, the answer to these debates can often be found by observing and talking to real users. You and I can debate whether one design is better than another, but it's difficult to debate what future users of the system told us through a combination of interviews and observation.

Widely adopting HCD

Just as a hammer doesn't solve all carpentry problems, the HCD shouldn't 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 this element as important a consideration as 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 guide you on how they are leveraging HCD.

Like most new approaches, if you start small and try to apply HCD to the problems it is best equipped to solve, you will learn the merits and shortcomings of the approach quickly and with little risk. When applied to the right problems, HCD can deliver better programs, accelerate adoption, reduce costs, and even allow your team to better understand and connect with the people who are the ultimate recipients of their efforts.