“It was a cool idea but way too confusing to use”. Every engineer has probably heard one or another variation of the same story at some point in their careers. The story of an engineer who designed a product on their own or on a client’s request, only to find that really, what they designed only works for them. Maybe they had their own unique mental model of the problem, or they assumed everyday users would have the same level of expertise as them. Oftentimes these products or applications fail, or simply serve to offer weird quirks to users who end up becoming experts in this one product’s specific interface. Other times there are disastrous, potentially deadly, consequences to poor interface design choices. Engineers working on the Therac-25 cancer radiation treatment machine failed to consider how quickly an experienced user could enter commands into their software to use the machine. This led to a race condition in the code that gave six people fatal or seriously injuring doses of radiation between 1985 and 1987.

Incidents like the Therac-25 combined with the success of highly usable interfaces has led to a shift in recent years, and companies have begun to recognize the value of usable products. Consider the iPhone, touch screen phones existed well before the iPhone but lagged behind in usability. The iPhone’s immense success wasn’t due to the technology, but the effort gone into making the most usable product possible. To try and capitalize on usability, many companies have design teams that implement Human Centered Design (HCD) principles to work on interfaces in tandem with software engineers. Thanks to this, software interfaces today tend to be more usable than ever before! But even if you’re not a designer, knowing the basics and having a human centered mindset can be an excellent tool in a software engineer’s toolbox.

So, what exactly is HCD? ISO 9241-210 defines it as an “approach to systems design and development that aims to make interactive systems more usable by focusing on the use of the system and applying human factors/ergonomics and usability knowledge and techniques.” In essence, HCD is about designing our products and systems around users and stakeholders, their abilities, their mental models, and their environments.

Some HCD decisions may seem obvious, like making your delete button red instead of green. Others may not make intuitive sense to us without research and user testing. Consider a sleep button on a phone; Will placing it on the top, bottom or side lead to the least accidental clicks? What location for the button is the easiest to reach given how people typically hold their phones? What location are the users expecting it to be located? Designers try and empirically determine these answers, to make the most usable products possible. For example, this study tested the common finger placement and ergonomics of grasping a smartphone, to better understand how controls on the back of the phone could be best used. That being said, HCD is a philosophy, not a methodology. It’s about shifting the way we think about the things we build by focusing on the humans they will impact.

[2] Which button feels more natural to you ?

There are plenty of tools and methodologies in a designer’s bag of tricks that align with HCD philosophy. Personas, for example, tend to be one that many people are familiar with. A designer will conduct research on the users and stakeholders that will be impacted by a product. Often this can take the form of focus groups, fly on the wall observations, and various types of user interviews. Once designers feel they have knowledge about who their users are, what problems they have, and how they like to interact with products, they will create archetypical  profiles of these users called personas. A designer can use these personas to run different activities and exercises with a team to try and better understand the individual impact of their design decisions on their archetypical users and stakeholders.

Even when many software companies have tried to separate out their designers from their engineers, it’s undeniable that software engineers still make design decisions that affect users and stakeholders every day. A software engineer working on a microservice is creating something to be consumed. Even if it’s another backend team that is planning on using your API or service, the decisions you make are going to impact their ability to use your code. Indeed, for many software engineers that work on distributed systems, the immediate users of their code are often other software engineers in the company working on different aspects of the same product. The decision to include a certain field in the output of an API is a design decision that is best considered on the impacts it could have on the consumers of that API.

Consider that things like consistent and conventional naming can have a huge impact on your consumers. Another developer should be able to easily understand what resource they are getting or modifying from a REST API based on the path alone. When deciding whether to make an API synchronous or asynchronous, thinking about the experience of the developer consuming the API alongside your technical requirements can make a difference in your decision. Of course, all of this is moot if your API isn’t properly documented and that documentation is accessible to your consumers. A good developer experience is crucial to creating effective APIs, and HCD philosophy can help you get there.

Learning more about HCD and trying to maintain a HCD mindset can have a big impact on the quality of products you produce. To begin making a positive impact on usability, you don’t need to be an expert, you don’t need to run fancy tests and exercises with your users, and I promise that you don’t need to draw up personas. Here are some simple suggestions that align with HCD philosophy anyone can do:

• Learn to identify your stakeholders. Who is consuming your work? Is it meant for end users or coworkers on a different team? Who is impacted by your work? You don’t have to be a user to be a stakeholder.

• Understand the problem before you begin solutioning. Sometimes you might get stories that already have a solution in mind. Before implementing that solution, talk to the relevant stakeholders and understand what problem the solution is trying to fix. This will allow you to adapt and change to meet the needs of your stakeholders, you may even find the suggested solution won’t solve the actual problem.

• Check in with stakeholders. Design is iterative; often we don’t understand things as well as we thought we did, or changing circumstances impact requirements. Designing an MVP and then checking in with people impacted by your work can allow you to quickly pivot and iterate necessary changes before refactoring becomes difficult.

• Practice Empathy. At its core, HCD methodologies are about trying to understand your stakeholders, their wants, needs, desires and pain. The simple act of trying to put yourself in someone else’s shoes can go a long way when you are creating something for them to use.

If you’re more interested in learning formal methodologies and conducting user research then there is a wealth of information available online. Some examples include Usability.gov, which is an excellent resource for exploring some standard designer tools. Universal Methods of Design is a purchasable book that contains a very comprehensive index of HCD implementing methodologies.

I find that often software engineers don’t consider themselves designers, but that simply isn’t true. The decisions we make on the code we work on every day will have impacts on people. Whether you’re saving lives working on bugs in a cancer treatment machine, or you’re helping people buy insurance, always thinking about the humans using your code can go a long way in improving your products.

Image References

[1] “Killer bug. therac-25: Quick-and-dirty,” PVS. [Online]. Available: https://pvs-studio.com/en/blog/posts/0438/. [Accessed: 06-Oct-2021].

[2] “Color of destructive primary button,” User Experience Stack Exchange, [Online]. Available: https://ux.stackexchange.com/questions/45490/color-of-destructive-primary-button. [Accessed: 06-Oct-2021].

[3] “Methods,” Methods | Usability.gov. [Online]. Available: https://www.usability.gov/how-to-and-tools/methods/index.html. [Accessed: 06-Oct-2021].

[4] “What is API Documentation and Why it Matters” Swagger, [Online]. Available:
https://swagger.io/blog/api-documentation/what-is-api-documentation-and-why-it-matters/. [Accessed: 11-Nov-2021]