User Interface Design for the Rest of Us

Most of my career as a software engineer has dealt with user interfaces in some capacity. As this includes designing and implementing one-person configuration software at a forty-person company, leading the graphical redesign for sections of a very large project at a two-thousand-person company, and back again, I suspect at least small forays into UI work are nearly ubiquitous for programmers. The problem with this, of course, is that programmers are not normal users. And the programmer who writes an interface is the least normal user for it, because that programmer knows the precise location and appearance of any widget they expect to be there and what it should do, and their expectations of functionality are skewed as well. Many companies, especially for large projects, manage to reduce this problem by having dedicated designers, artists, and programmers to handle their own area of expertise. Depending on whom you work for and what you’re working on, it may well just be you, lone cowboy developer, and a list of requirements.

And so we come to the title, which proclaims “for the rest of us.” What does a single software engineer do when presented with a interface design and implementation problem without the resources of a dedicated team at, say, Google, or Microsoft, or Apple? The following are the basic tenets I have learned over the years that have saved me a significant amount of time and stress in the long run, and have worked out well enough that my grand prize keeps being more interface work.

1. Internal consistency.
Even when you are building a small section of a larger software package with an existent bad interface, consistency is of utmost importance. Name your menu headers consistently with the rest of the program, use the same cancel and ok buttons in the same placement, use the same wording for your errors and dialogs, use the same colour scheme, and so on and so forth. This is boring, obvious, and important. Oddly enough, I’ve found internal consistency most important when adding to a bad interface that can’t be completely overhauled, because once users learn to navigate an unintuitive interface, they can work much more efficiently within that framework than if you change it, even to something better, for a single page.

2. External consistency.
Remember the examples above of companies who have dedicated teams for designing aspects of user interface design? I have had Microsoft and Google employees describe to me the eye-tracking technology they use to monitor how testers examine a new interface and use it, streamlining their products to match these use cases. You don’t have to have those resources to learn from those who do. Take a closer look at your operating system, common applications, big-name web pages. Follow their conventions and you are not only piggy-backing on big-name research, you are piggy-backing on the user expectations that have developed from familiarity with this other software. There are degrees of theft that become outright copyright violation or more nebulous “look and feel” lawsuits, but following an expected style can save a lot of time designing around niggling little issues, and can also reduce the number of user errors that occur when expectations are violated (see Charles Miller’s Firefox “bug” report).

3. Clearly provide only and all relevant information, grouped effectively.
This condenses several points more long-winded lists of design principles make: avoid clutter and reliance on color, know your widgets, group things effectively. An airplane flight simulator may require half a screen of fancy graphical knobs and indicators and buttons and switches, but very little else does. Hide infrequently-used options behind menu headers, grouped and labeled intuitively; go back to external consistency and look at a web browser or operating system for obvious, tested examples. Do you need a button or checkbox for every single option on the screen at once? Will a drop-down suffice and save you precious screen real estate? Can you make reasonable, intuitive tabs? The initial screen as presented to the user should flow directly into what they have to choose first or what they will do the most often. Hide what isn’t relevant and then make it very easy to make things appear as needed. Color is mentioned here as a matter of clarity: some users are colorblind, you may have no control over the color of operating system components that may show up in your application, and a basic interface that pukes up a rainbow on the user, even for most widgets in a paint program, is confusing and unpleasant.

4. Paper first.
In fact, several pieces of paper. This is another big-name design team trick. Before you write a line of code for anything more complicated than a confirmation/cancel dialog box, get out a notebook or a few printer header pages from the trash or anything on which you can draw some reasonably-sized “screenshots”. Draw out the whole first screen or form or relevant interface entity. Annotate each way that flows into the next screen or form. Draw the next one, and so on. Throw away pages, start over from scratch if you have to, chances are you will make significant changes in layout and flow for any reasonably complicated interface at this stage. This is right and good because you haven’t wasted your time writing any code or finding non-copyrighted widget graphics on the internet that would wind up unused. This is especially true and especially useful if you can show your “screenshots” to someone else.

5. Get user input early.
Doing an upgrade or redesign? Find yourself a user of the old system (and more is always better) and ask them what annoys them about it. Old product or new, sit your poor hapless test user down in front of the earliest prototype you have, send them screenshots of it, anything to get a modicum of testing done early by someone who will actually have to deal with the thing. Don’t have a real user? Drag anyone not writing code relevant to your interface over and have them look at it. Shove it in the faces of your roommates or significant others; if you’re a programmer, I assure you they’re used to this sort of behaviour. You may have to explain what something will eventually do, or what an icon is intended to look like in more polished stages of design, but it is likely that amidst the general griping and confusion you will get important insights on things that would be orders of magnitude more work to change later.

6. Have more than one way to do most things.
Your early user input and internal and external consistency should give you a good idea of what needs redundancy. “Users” is plural, and people have different ways they prefer to work, and in some cases different hardware and different needs. Best Practices state that most basic operations in a graphical user interface should be accessible completely by keyboard, or by keyboard and mouse. I’ve written an interface for software that was required to run on a small touchscreen as well as a standard PC, so we went farther and brought up graphical keyboards larger than the built-in Windows accessibility feature. Most graphical interfaces don’t require this degree of special effort, but there should at least be hotkey and mouse-based ways to do most things.

7. Anticipate user error.
Admit it. You have accidentally deleted things, sent email to “all”, printed the wrong page, mistyped a password, any number of every day interface errors. Getting user input early and adjusting for common failures can make them less frequent. But they’re still going to happen. Make user choices reversible when possible. Confirm when you can’t. Catch the errors you can, and explain the issue to the user effectively.

I am by no means a full-time professional interface designer. Fortunately for me, I am also no longer a full-time professional interface implementer, because decoupled from the design process, that is probably the second most boring job I have ever done, just behind folding t-shirts for an aquarium gift shop in high school. But while very little code has a dedicated team scuplting its user interface, every piece of software has UI somewhere, if only for installation or reporting, and some poor programmer has to write it and some poor user has to deal with it. And just a few simple things can make it easier on the rest of us.