We ended the previous post with a reasonably coherent project brief, and a primal urge to break out the Moleskine and start designing the user interface.
Well, hold your hosses there cowperson, there’s been a slight change of plan.
The goal of this series is to give you the tools necessary to create shimmering add-on edifices of your own imagining, not simply to walk you through the creation of some ropey Twitter module. With that in mind, it makes sense to cover a few basic principles of good UI design, prior to doggy-paddling through the murky waters of my hoary-old design mind.
At the risk of stating the obvious, this will not be a full course in the noble art of user interface design. If you can’t draw your name in the ground with a stick, and consider Windows Vista to be “actually not that bad”, this blog post isn’t going to transform you into Susan Kare overnight.
What it will do (hopefully) is guide you gently away from some of the more egregious UI sins, and towards something that is at the very least usable.
If I could emphasise one user interface design principle above all others, it would be this: keep it simple.
In “Designing Visual Interfaces”, the authors regard simplicity as the foundation upon which great user interfaces are built, stating that:
Before you do anything else to improve the quality of a design, make sure you have reduced its formal and conceptual elements to the absolute minimum.
The benefits of reducing the complexity of a design are manifold: it makes the interface more approachable, easier to understand, easier to recognise, and above all, easier to use. It also makes all the other principles in this post easier to achieve.
As you might expect, Apple understands the value of simplicity. Their Human Interface Guidelines caution Mac OS designers against attempting to please everyone, astutely stating:
If you try to design for the 20 percent of your target audience who are power users, your design may not be used by the other 80 percent of users.
Elements of the same type, with the same function, should look the same. Once again, “Designing Visual Interfaces” nails it:
<blockquote> <div markdown="1">Any irregularity will be interpreted as significant by the user</div></blockquote>
This doesn’t just apply to link and button styles. It means copywriting, action verbs, page layout, the works.
Eliminate ambiguity in your design, and you eliminate confusion for your users.
Design consistency has the added benefit of making it easier to highlight key elements. There are 7 different ways to establish visual contrast: size, tonal value, orientation, texture, shape, position, and hue (colour).
Reams have been written on which differentiators are most effective in which situation, but for our purposes this is overkill.
You don’t need a 200 page UI tome to know that your big pink button will attract attention. Masuga, stop sniggering at the back. Use your common sense, pick one or two differentiators, and try them out.
Before we stumble headlong into the next principle, there’s one more thing worth mentioning: destructive actions should be clearly differentiated, and separated.
If clicking on a button is going to delete the internet, don’t position it next to a nice innocent “click here for kittens!” link. Stick it on the far side of the page, and make it red and scary looking.
Consistency and differentiation work together to establish the relative priority of page elements.
Determine what the user is supposed to do next, and draw his attention to it. If it’s a multi-stage process, it’s the “Next” button. If it’s a settings page, it’s the “Save Settings” button.
Yes, occasionally a user may wish to regress to the previous step, or reset his settings, but these are not the most common actions. Once again, we’re designing for the 80% here; add these secondary actions if you must, but don’t allow them to detract from the primary objective.
Every system has its conventions, and in the case of add-on development you’re already working with two: ExpressionEngine, and the operating system within which ExpressionEngine is running. Don’t confuse matters by introducing a third.
If you’re growing tired of my endless dictums, and find yourself tempted by the prospect of creating a really pretty custom checkbox, consider this: in addition to his daily routine of abstinence and flagellation, Brandon Kelly — yes, that’s right, the original Playa pimp — lives his life by the following principles:
- The UI should appear “of its environment” — it should blend in with its surroundings, not drawing much attention to itself.
- Following conventions trumps innovation most of the time.
There’s more, but it involves sacrificing chickens.
There is one caveat to this recommendation, and it concerns the occasional conflict between convention and “correctness”.
With your new-found UI expertise, you may decide that ExpressionEngine has clearly got some things wrong. In such a situation, should you go along with the standard way of doing things — simply because it’s familiar to the end user — or should you stand your ground, dogmatically demanding that users embrace your more “correct” implementation?
If defying convention will cause usability issues, then set aside your pride, go with the ExpressionEngine “solution”, and file a bug report. Otherwise, by all means show EllisLab how it should be done. And file a bug report.
Shock usability testing revelation! The best way to identify user interface problems is to use the interface.
Use what you’ve built. If you find yourself working around something, or putting up with that stupid button being 3px too far to the right goddammit, don’t ignore it. Pretty soon you’ll just learn to live with whatever the issue is, and then you’re sunk.
Be alive to the experience of using a product. If you hate something, make a note of it. Do the same for designs that you love.
Good user interface design is mostly just about noticing stuff. I know, people actually do degrees in this. Idiots.
Countless hundreds of pages have been written on the subject of user interface design.
If your interest has been piqued by my blasé summation of decades-worth of interaction design hand-wringing and usability testing, the following list of recommended books and articles should keep you in bathroom reading material for the foreseeable future.
- Designing Visual Interfaces, by Kevin Mullet and Darrell Sano.
- Defensive Design for the Web, by 37signals.
- The Visual Display of Quantitative Information, by Edward Tufte.
- Apple Human Interface Guidelines. Parts 2 and 3 are all about designing for Mac OS X, but part 1 (“Application Design Fundamentals”) contains some excellent information about the fundamentals of user interface design.
Brandon would also like to draw your attention to the following gems:
- Don’t Make Me Think, by Steve Krug (seconded).
- Designing Interactions, by Bill Moggridge.
- One Free Interaction is an article by Chris Noessel, identifying the biggest step you can take toward making a UI fun to use.
- Derek Sivers recently published a great blog post on the perils of convention vs. innovation.
A big thank you to add-on heavyweights Brandon Kelly and Leevi Graham for indulging my inane questioning in the run-up to this blog post. Their answers were both thought-provoking and informative, and resulted in my decision to afford this subject the attention it deserves.
You can expect to see many more of their insights as this series progresses, particularly when it comes time to build the user interface.
Sharpen those pencils, the next post will be all about putting these principles into practise.