Who is "The User"?

In the software development world, it is common to hear developer, designers, product owners, etc. all talk about "The User". Most of the time however, we don't think much about who Mr./Ms. User actually is. This inevitably leads to a problem.

The problem is that if you don't know anything about who you are designing software for, you are very likely going to create software that either is geared toward use by the developers or product owners themselves or is based on some union of all traits of any possible user. Since most software companies are not building software development tools there is an obvious problem with the former. And, unless you are building very specialized software for a narrow population of user, you can't really combine the traits of a super power user and occasional perpetual novice user into one ideal person which makes the latter a problem.

Why shouldn't the developer build what she would want?
The answer is simple. Developers are a different breed of person. Take no offense if you are one. I am one too. Developers enjoy having an understanding of the inner workings of software and can appreciate the technical difficulty of it. Plus, they understand every aspect of the software they are building. All of that makes it hard to see the software from the point of view of a non-technical person, who has no interest in how software works and doesn't care how difficult something is to implement.

Why can't one UI serve all the traits of all possible users?
If you think about most things in the physical world, there is little that is "one size fits all". In fact, things that used to be called "one size fits all" now say "one size fits most". The reason is obvious. One size can never fit all. This doesn't just pertain to size...

Imagine you were in the shoe manufacturing business and you created a line of sneakers. So far so good. If someone decided that you should make shoes that would be good in the winter while shoveling snow, you would not likely try to adapt the sneaker design for this purpose. Even if you could make that work you will ultimately wind up in the situation where as you need to create dress shoes, sandals, water shoes, etc. they can't be combined into one shoe. The only way this can work is to understand the needs of "The User" better.

In our shoe manufacturer example the better solution would be to think of the different types of shoes as meeting the needs of particular consumers. As you go through the process of defining the different types of shoes needed, you will probably see opportunities to combine types. A sneaker and a hiking boot could be combined. But a hiking boot and a sandal probably can't.

When designing software we need to do the same thing. Certain functionality is meant to meet specific user goals. Those goals can usually be categorized into buckets such as Employee or Manager, Student or Teacher, Player, Coach and Scout. Once you categorize the functionality, you can start to make decisions about how the UI can support those types of user.

As UCD practioners will notice this is a step toward defining Personas. While Personas are very powerful mechanisms for understanding specific users, I have found that Agile teams are very reluctant to spend the appropriate amount of time defining them. If you have the time, by all means, go for it. If you don't, and can't get the time somehow, at least try to make a quick pass at it at the beginning of the process. Finding out during the middle of development that the software is going to be used for global reporting by executives as well as the individual employees for data entry would be very costly .

The Bottom Line
While you don't need to go survey hundreds of real users, it is very valuable to at least think about who those users are. Every user will be happier with the result.