Are You Designing for Bigfoot?

Consider the following (imaginary) conversation:

Programmer: What if a user will want the ability to sort the values in the report grid by columns?

Manager: We don’t need a dynamic grid for version one.

Programmer: But someone might want to sort the values! Users will expect to be able to sort values by clicking on the column headers…

Manager: We don’t have time to add this feature to our schedule. Can’t we consider it for a future release?

Programmer #2: I don’t think sorting makes sense here.

….

Sounds familiar? If you’ve been part of a product development team you’ve probably encountered this kind of feature debate before… maybe even quite frequently…

Programmers are trained to think about possibilities and logic terms, that’s why the logic of what “might” happened is irresistible to the programmer.
Alan Cooper describes this behavior in The Inmates are Running the Asylum:

Programmers call these one-in-a-million possibilities edge cases. Although these oddball situations are unlikely to occur, the program will whenever they do if preparations are not made.
Although the likelihood of edge cases is small, the cost for lack of preparedness is immense. Therefore, these remote possibilities are very real to the programmer. The fact that an edge case will crop only once every 79 years of daily use is no consolation to the programmer. What id this one time is tomorrow?

The manager can’t advance the argument with the force of reason as he has no way to logically contradict this programmer and so he’s left with the choice of giving up or using his authority, which is usually how these kinds of arguments end up.

The programmers concern with the possible can easily obscure the probable by loading the program’s interface with controls and functions that will rarely be used.

The problem with this entire argument lies in the fact that arguing about what users might expect is the same as asking “What does Bigfoot like for breakfast?”

Users come in many forms and shapes. Some are proficient with computers, some don’t even like them. Some are used to Microsoft UI and some work mainly on the Mac. Some require advanced control with the expense of simplicity and should would rather give advanced control away in exchange for a quick and simple way to perform their goals.

In order to avoid this kind of dead-end feature debates its useful to change the team terminology and work in terms of personas and their goals. Rather than thinking of users as an abstract, difficult-to-describe, amorphous group of people, personas instruct us to talk about specific users who have names, personalities, needs, and goals.
Understanding exactly who the users are and what they do with the software is essential to determine if a certain feature is actually required.

Do we really need to allow sorting the column? there’s no way of telling… but if you know that we’re designing for Jeff, a CFO of a large enterprise, who would like to get his report in a fixed predetermined format then its probably a requirement not to do so…

A very good example for use of personas can be found in Nikhil Kothari’s post about where he describes three personas that were used by the development division at Microsoft while working on Visual Studio 2005:

We have three primary personas across the developer division: Mort, Elvis and Einstein.

Mort, the opportunistic developer, likes to create quick-working solutions for immediate problems and focuses on productivity and learn as needed.
Elvis, the pragmatic programmer, likes to create long-lasting solutions addressing the problem domain, and learn while working on the solution.
Einstein, the paranoid programmer, likes to create the most efficient solution to a given problem, and typically learn in advance before working on the solution.

The description above is only rough summarization of several characteristics collected and documented by our usability folks.
During the meeting a program manager on our team applied these personas in the context of server controls rather well:

• Mort would be a developer most comfortable and satisfied if the control could be used as-is and it just worked.
• Elvis would like to able to customize the control to get the desired behavior through properties and code, or be willing to wire up multiple controls together.
• Einstein would love to be able to deeply understand the control implementation, and want to be able to extend it to give it different behavior, or go so far as to re-implement it.

Using the above described personas, Nikhil’s team was able to effectively design a set of .NET controls so that each persona will find them usable for his use:

All of these controls just work out of the box in implementing the end-to-end scenario of managing user sign-on. Coupled with themes, these controls can look pretty good as well. They go on to provide a whole set of properties to tweak their behavior, and appearance.

Furthermore, they provide the ability to flip into template mode for more significant changes to their content and layout.

Finally, they’re built on the provider-model in ASP.NET so an advanced developer could come along and swap out the built-in membership provider going against say the default SQL or Active Directory user database and replace it with one that goes against say an Oracle user database or some other custom store while keeping the UI functionality intact.

So, the next time you’re in a feature debate, stop and ask yourself “Who exactly am I designing this feature for? Why does he need it?”.
Describe a set of personas that your software will target and use them as reference in any design discussion or feature debate instead of referring to an amorphous group of “users” that might not even exist.

Don’t design your software for bigfoot….