For a long time I've been stuck in the mindset that creating a fabulous user interface requires a top-notch artist. I thought someone who is a master of colors and graphics is bound to make the ideal user interface. Trial and error has proved this incorrect.

I've done projects with and without fabulous artists. A good artist can improve the details of the interface to make it easier on the eye, but rarely does he or she make suggestions that dramatically improve how the software works. That's okay; that's not their job. But if they're not changing how the software works, then maybe colors and graphics aren't what make a user interface easy to use.

Maybe it's the programmers who make it easy to use. The programmers know the database, therefore they must be masters of data input fields and data display, right? Without the right data, the software is going to be useless. As most of us already know, programmers are generally pretty bad at making easy-to-use interfaces. It's probably because we're all left-brained creatures. Or it may be because most programmers are quick to try and save time by reusing prebuilt interface widgets that may not be ideal for the people using the software.

It's not the people on our team who make a good interface, it's the design process. As much as I don't like McDonald's, they've created a business that can be operated by uneducated teenagers. They have created an operation that focuses on ideal steps that just about anyone can do. While most of the people reading this article fall into the "programmer" category, it is possible for us to improve our interfaces by improving our design process.

People Have a Name
The first step is to paint a picture of who is going to use your software. If you are building a business application, it's likely numerous people will use the software. We can't account for everyone so it's important to group people together. Most of us already do this, but the most important thing we can do is to stop referring to them as "users." They are people. Instead give them a name, gender, age, picture, and a short story. Paint their picture.

This is not a new concept; it is commonly used in the marketing world, and known as a persona. With software, a persona is a fictitious person using our system. Don't confuse personas with UML actors. The concepts are similar, but different on a broader level. Use case actors help us understand how a person fits into the flow of the software, whereas personas help us decide why one solution is better than another.

For example, Sally is 16 years old and a high-school dropout. She left school because she just couldn't seem to pass her math classes. Now she works for McDonald's as a cashier, earning minimum wage. Even with only a few sentences we can paint a fairly dramatic picture of Sally, enough to help us rethink how the cash register software needs to work. McDonald's has a good understanding of Sally. For example, their cash registers do not require her to type in how much an item costs. Instead they have pictures of hamburgers, French fries, etc. But could they improve the cash register so Sally doesn't have to count the correct change? That may seem ludicrous to a programmer who does highly complex math every day, but remember Sally is not a mathematical genius.

Distinguish Tasks from Goals
When we're using software we're frequently completing tasks. Improving tasks does not immediately make software easy to use. For example, we don't go to Amazon.com just to enter our credit card information into their database. That's just a means to an end. Joe, an Amazon customer, uses Amazon.com to obtain a book to read. Reading the book is his goal, it is not a task. Reducing the tasks to achieve a goal immediately improves an interface. Amazon has done a good job by remembering Joe's information when he returns. Their one-click order system is the ultimate attempt at reducing tasks to achieve a goal.

Identify the Human Flow
After identifying the goals our personas are trying to reach, we want to define the human flow they will go through to get there. By human flow I mean the steps they take in day-to-day life. Some of the steps may involve your software, others may not. Each of these steps should have a date/time associated with it. Let's look at using a cellphone interface.

5:00 p.m.: Todd leaves his office to go home.
5:05 p.m.: While driving, Todd decides to call his wife to find out if he should pick up groceries for dinner.
5:08 p.m.: Todd hangs up.
5:15 p.m.: Todd drives to the store.
5:25 p.m.: Todd forgets all the items his wife asked for. He has to call her back to ask again.

Not all of the steps in the human flow involve the software. The human flow may leave out critical steps necessary for the software to work. Even so, the software flow should be based on the human flow. In the steps above, there are a few events that involved the cellphone. Understanding the human flow provides our user interface with the boundaries in which the interface needs to work. For example, can we improve making a phone call while driving a car?

Since Todd's eyes should be on the road and not on his phone, can we improve the audible interface for his phone? Since it's more likely he'll want to make a call while driving versus playing Tetris, there is little reason to include the games in the audible menu. How about helping him remember what was said during a conversation? Instead of calling his wife back and bothering her, couldn't the phone just record the conversation and play it back?

These boundaries may appear artificial at first, but if the personas defined accurately represent the real users they are based on "probable" issues, not "possible" issues. While it's possible to put a Ferrari engine in a station wagon and add some tractor wheels, it's probably not a good idea. How many soccer moms need to pick up their kids from soccer practice and plow a field, while doing 160 miles an hour? Our software should not attempt to solve every problem in the world. Instead we should focus on the probable issues and solve those. Personas help us identify these probable issues.

Only when we have identified why the people using our software are trying to accomplish certain goals can we effectively make decisions about how the user interface should be built. Personas provide us with a structure to improve our chances of making the correct decision about our software and its interface.