Practical .NET

What's Important in UI Design

The key decisions -- the "architectural" decisions -- in user interface design aren't technical ones. The good news? Just two principles that drive those decisions. The bad news? You won't like either of them.

• By Peter Vogel
• 10/06/2012

In a recent article, Billy Hollis argued that "user interface design is no longer optional" and pointed out that many UI design decisions were driven by the construction of the human eye. And that's certainly true -- but those decisions only kick in after you've made a whole bunch of other, "architectural" UI decisions: What screens/forms/windows/dialogs should I have? What should go on each one? How should the user move from one to another? What should go in the upper left-hand corner of this one? Where should the buttons be? When should I have a button and when should I have a toggle (practically never, by the way)? The answers to these questions are as critical to your application's success as your database design or your object model.

Those questions and answers fall into two categories driven by two principles.

Convention
One set of answers is easy: convention. In Windows, for instance, dialog boxes have OK and Cancel buttons, those buttons go in the lower right-hand corner of the dialog, and the OK button goes on the inside. Why? Because that's where users expect to find them. Why? Because that's where Microsoft consistently puts them.

This approach sometimes raises a counter-argument: "Just because Microsoft does it, it doesn't make it right." Well, actually, it does. In Windows, the conventions followed by the Microsoft UI design team have trained your users to expect certain things. You can fight with your users' expectations, but it's not clear to me what benefit you're delivering to them by doing that.

There's also a supporting argument that's equally foolish: "Windows is intuitive and those conventions represent what users would do naturally." If you've ever taught a complete novice how to use Windows, then you know that nothing about Windows is intuitive. What Windows is, is consistent. If a user has successfully printed something in one place in Windows then they can successfully print something anywhere else in Windows (or, at least, the odds are in their favor).

This is not a paean to Windows: new users in Windows often spend years double-clicking on everything because the distinction between click and double-click is nowhere near as obvious as experienced users assume it is. When following directions, people who've been using Windows for years will still ask "Do you want me to right-click or left-click?"

But it does suggest a good UI design principle, though not ones that techies like very much: When designing a UI, find the most popular application among your user community that's most like the one you're building, and copy that. Let me be more specific: On the Web, steal as much from the Amazon UI as you can.

I told you that you wouldn't like this principle very much. You'll like the next one less.

What Comes Next?
Unfortunately, conventions only address the most trivial of the UI design questions. It leaves unanswered some of the most important questions: "What forms should I have?", "How should they work together?", and "What should go on each form?"

Understanding the second principle starts by considering the ultimate user interface: A single button with the caption "Take Care of It." Every other user interface is just an approximation of that perfect UI: Click the button and your task is taken care of. The criteria that makes this the perfect UI is simple: The user always knows what to do next. When that criteria is true, you have a great UI.

Conventions do help here: if the user knows what the down arrow beside a dropdown list does (and how to activate it), you can exploit that knowledge in your UI. But, notice: What conventions actually describe is the knowledge the user brings to your UI.

The user also brings another set of knowledge to your UI: The user (usually) knows what they want to accomplish and what tasks are required to get there. Your UI will make the most sense to your users the more directly it maps to your users' tasks and their goals.

Don't Just 'Do Stuff'
Far too many developers create UIs that "do stuff." The developer brags that "The user can do anything they want from this one screen." The problem is that the user doesn't want to "do anything" -- at any point in time the user wants to do one specific thing. So your goal is not a UI that "does stuff"; your goal is a UI that allows your users to achieve their goals. This means that, over time, a user typically needs multiple screens (not one), each of which guides the user through the thing they want to do now.

This means that the first step in building a UI is understanding (a) who your application's users are, (b) what your users' goals are, and (c) what tasks those specific users expect to perform to achieve those goals. Which leads to the second principle of effective UI design: Your first job in building your UI is not to understand your application; your first job is to understand your users.

Developers tend not to like this principle, either.

Billy recommended two excellent books in his column, so I'll recommend one, too: "The Design of Everyday Things" by Donald A. Norman (originally, "The Psychology of Everyday Things"). In addition to being vastly entertaining and deeply informative, it's one of those books that makes you look at everything around you differently. Like a UI designer.