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.

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.

About the Author

Peter Vogel is a principal in PH&V Information Services, specializing in Web development with expertise in SOA, client-side development, and user interface design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His most recent book ("rtfm*") is on writing effective user manuals, and his blog on language and technical writing can be found at rtfmphvis.blogspot.com.

comments powered by Disqus

Reader Comments:

Wed, Jan 16, 2013 Duuunk NC

One persona that the Visual Studio staff magazine should look into is that group of people who don't like it when advertisements cover up a quarter of the text in their articles (eg. the upper right corner) and there is no way to get rid of the advertisement. Just saying.

Fri, Jan 11, 2013 Peter Vogel Canada

Nigel: Not Stallone's "Judge Dredd" but "Demolition Man" with Sandra Bullock, Wesley Snipes, Benjamin Bratt, and Denis Leary. A great idea turning into one of the world's oddest films--it couldn't make up its mind if it was action/adventure, satire, or comedy and certainly couldn't fuse them. But it does have Slyvester Stallone knitting.

Thu, Jan 10, 2013 Nigel williamson West wales Uk

Another good bathroom example that everybody would have some recollection of is the 3 sea shells in judge dread. Again and as you explain, a less than obvious design awaiting trial and frequent error.

Thu, Jan 10, 2013 Peter Vogel Canada

Gerhard: Awww, that would be unfair--once you were outside the bathroom (and warmed up) it was a very nice hotel. Besides, it's far from the worst. My buddy Ken Getz talks about waking up in a hotel room and looking at a panel of 14 buttons built into the bedside table--all of them unlabeled. When I present on UI issues at conferences I never have a problem with finding some good example of UI failure (and, occasionally, success) the day before the talk. When I consult on UI issues with clients I can find something (in 5 minutes or less) in their own applications where everyone goes "Yeah--that makes no sense at all. But everyone in the company figures out how it works...eventually." So picking out one hotel would just be cruel. Out of all the system architect consulting that I do, I wish, more than anything else, that people would have me in to help with their UI design. It's so easy to get people on the right track to doing well on their own because people already know so much about good UI design--they just need to find out how to leverage that knowledge.

Tue, Jan 8, 2013 Gerhard Germany

Funny, gimme the name of that hotel, I'll never be there :-) Cheers Gerhard

Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.