The User

The single most important aspect of programming is the user. Keep this in mind through all the discussions we have, even down to the lowest technical details of an operating system. The only reason we need programming is for users.

Who is the user? As they are the people we ultimately serve, we need to understand who they are, and who they aren't. In the most abstract sense, a user is anybody using technology to accomplish a goal.

It's the photographer touching up their photos. It's a gamer relaxing behind a controller. It's friends talking to each other on the phone. It's an accountant entering numbers into a spreadsheet. It's the thousands of people browsing social media, or the few organizing a weekend getaway. It's a hungry man ordering a burger late Saturday night. It's a musician putting the final touches on their new masterpiece. It's the medical researcher trying to create a new vaccine.

The list focuses on people doing real things. I've intentionally omitted a lot of what I consider to be secondary users. These are people producing tools for other people to serve end users. These are the administrators and programmers who use technology and libraries. We're users, but a special class. Our requirements need to be met, but ultimately we need to cater to the primary user.

Note that I haven't mentioned software here. A user doesn't care about software, hardware, or anything in between. The user has a high-level, real-world task. Many components need to work together to help them. Thinking about the hardware, software, and process separately does a disservice to the user.

Ideally, the user's thoughts never leave their application domain. They shed no worry about the bits they are using. It blends seamlessly, becoming part of their flow. And there's no way to provide that flow unless we can think like the user. We need empathy to understand their problems. Any time we make a decision, we must consider the impact it has on those users. Frustration arises from mismatches in expectations, not necessarily defects.

Furthermore, we need to consider what abilities our user has. They aren't as computer literate as us -- again, their thoughts ideally don't need to leave their domain. Getting into the user's head lets us use terms, symbols, and processes they will understand. The user shouldn't have to read this book to use the tools we make.

Way beyond knowledge, not all humans are created the same. Not just disabilities, but minor variations, like finger size, can make applications hard to use. We don't all have the same reaction time, nor the same appreciation of, or even able to distinguish colors. In a world where everything is connected, we have to consider all people. Leaving even a few behind is unfair.

Creating good software requires understanding our users. Who are they? What are they capable of? What do they want to do? This goes well outside the realm of programming, to all development teams. There is only one reason why we develop software, and it needs to be at the forefront of our thoughts, always.

The user.

This is a draft excerpt from my upcoming, probably free, book. Sign-up to my mailing list to stay informed.