Practical .NET

The User Interface Design Process

There's a well understood UI design process that you can use to get to the "right" UI for your application. And it starts by inventing people.

• By Peter Vogel
• 01/04/2013

There's been sufficient interest in the recent columns on UI design from Billy Hollis and myself that it makes sense to take a moment and sketch out the key step in the standard UI design process. Getting this part right avoids getting so much else wrong (as I'll demonstrate at the end of this article with some war stories from my own life).

What you're looking for in the first step is some basis for making decisions on what will (and won't) work in your application's UI. Billy pointed out that many decisions are driven by our physiology. However, that's unusual. Once you start letting others review your UI, you'll find that everyone has a whole bunch of "UI preconceptions" that have more basis in superstition than fact: "Oh, users don't like that" and "You should always put x near y" are common phrases you hear; but if you ask why you should or shouldn't do something, no one has a good answer (the first statement usually boils down to "I don't like that," for instance) let alone one based on the design of the human body.

Personas
This is where personas come in. A persona is a description you create of one representative member of your audience. A typical application has two or three audiences, so you'll end up defining that many personas. The key is to describe each persona thoroughly. Describe more than just the "features" of your audience member that cause them to interact with your UI -- go on and describe a complete, well-rounded human being. You should, for your persona, be able to describe what they do in their spare time (do they have spare time?), what their family life is like, where they went to school, the house they live in, what interests them the most; their whole life. Make the persona real.

Now, when it comes time to make a decision about your UI you can refer to the appropriate persona ("This part of the application will be used by this persona"). If you've done a good job of describing your persona, you'll know, for instance, what other kinds of applications that persona will interact with and what the physical world of this person looks like. As a result, you'll know what sort of visual cues the persona will respond to, what knowledge they bring to your UI, and what their expectations for your UI will be. In case you're not sure what will or won't work for your persona, you can go and find a person who closely matches your persona and ask them (it's not cheating).

Beyond the Persona
The next steps derive from your persona definitions: what are the tasks the persona performs, and how can you support them? By this point, you have a handle on what each persona's goals are for their tasks. At a high level, you should know if the persona wants/needs fine control over this task, or if it wants to get the task done as fast as possible (is quality or convenience "Job 1"?).

At a low level, you should know what the typical defaults for this task are, along with the inputs that the persona typically changes/controls. You have, as I said at the start, a basis for making decisions. Coupled with existing research on how effective UIs work (and there are any number of great books out there; the articles referenced at the beginning have good recommendations to start with), you'll have a lot of guidance.

What Goes Wrong -- And Why
Here are two examples of what goes wrong when personas aren't used: one from my professional life and one from my personal life. And only one is my fault.

Many, many years ago, I was the project lead for a team building a purchasing system for my employer. One part of that system managed contracts. In this system, contracts specified, for a particular vendor, the price we'd pay when buying the items listed on the contract. Of course, from one year to another, these prices would change (usually, upward). I designed a UI where users could go into the list of items for a contract and change the prices for any item.

There were two personas involved in this UI: The person in the purchasing department who used the screen, and the vendor who provided the information used to update the prices. It turns out that neither of these personas were interested in precision. These contracts basically handled all the purchases where the company didn't care about the price (prices for stuff the company did care about -- raw materials, for instance -- were negotiated on single item contracts). So neither persona was interested managing these prices individually for the literally hundreds of low-value and/or infrequently ordered items on a contract. My UI was going to add hours of overtime to what should have been a trivial task.

What both personas would value was a single screen with two controls: (1) A TextBox labeled "Percentage Change" for entering some decimal number, and (2) A Button labeled "Increase all prices by the Percentage Amount." If anyone needed to change the price for a single item, they could use my original screen (but I don't think anyone ever did). After the application was released, we enhanced this screen by copying into the Textbox the percentage amount used the last time the contract was updated. After that change, the user often just had to click the button to raise the prices the right amount. It was the ultimate UI: A single button that took care of the task.

Split Personas
My second example is from the morning of this writing, at the hotel at which I was staying. I got up, turned on the shower and got in. To control water flow and heat, the shower had a single lever: pull out to get more water, swing to the right or left to change the temperature. The water wasn't quite hot enough, so I swung the lever to the left (towards the "H" and the conventional side for hot water) to get more hot water.

I thought I was going to die. I have never been so cold in my life (and I grew up on the prairies of Canada).

It turns out that the designer of this lever felt that it was where the top of the lever pointed that mattered, not where the part I was holding pointed. So, while I was swinging the bottom of the lever towards the "H", I was also swinging the top of the lever towards the "C" and death by freezing.

This decision by the UI designer would have been more obvious if the top of the lever, instead of being a smooth ball, had been designed to show that it mattered: a little point, or an indicator line of some kind. But here's my real point: the sink in this same bathroom also had the same lever design. But, with the sink, it was the bottom of the lever that had to be pointed at the H or C to set the water temperature. So the bathroom designer had, apparently, one persona in mind for the sink and, apparently, a different Bizarro-world persona in mind for the shower.

It's simple to describe (and not that hard to do): Figure out who your application's personas are, find out what they expect and want, and build that.