Some time ago, I wrote a post about the use of patterns in user interface (UI) design. The idea is that, when one solves problems for a living, over the years the same problems will crop up, and similar solutions will be re-used. The context may change, but a solution that worked well at one point may also end up working well for a new problem. Having the experience to recognize these patterns and not have to re-invent the wheel each time is what makes one an “expert”.
The idea of patterns grew out of Christopher Alexander’s seminal work on patterns “A Pattern Language” back 1977, and was first detailed in the realm of software in the book “Design Patterns” by the “Gang of Four” (http://books.google.com/books/about/Design_Patterns.html?id=6oHuKQe3TjQC ).¹
Since then, the patterns movement has gained momentum in many communities, including among user interface/user experience (UI/UX) designers. A very common pattern is the Wizard, a set of screens that guide a user through a pre-defined set up steps to accomplish a particular goal.
Patterns make for great short hand when collaborating during design work. Being able to just say “use a two-panel selector” saves time and helps people get on the same page quickly. They also make for a great teaching tool. As someone who teaches classes in Human-Computer Interaction (HCI), I’ve done several lectures over the years that talk about interface and interaction patterns. (An excellent read on the topic can be found here: http://designinginterfaces.com/about-the-book/ ) ²
An alternative way to approach patterns is to look at things that we, as designers, should not do because they didn’t end well the first time. This is the idea behind anti-patterns, which are bad solutions to common problems (http://c2.com/cgi/wiki?AntiPattern ).³
Much like touching a hot stove, being aware of anti-patterns can help us not make the same mistakes twice.
I first became aware of this notion several years ago when I discovered the first edition of the book “GUI Bloopers”, by Jeff Johnson (http://www.gui-bloopers.com/ ). 4 While the content in the book is certainly dated (think Windows 3.1), the idea of learning about what not to do by studying examples of poor user interface design always stuck with me. Towards the end of every semester, I would give a lecture showcasing many of these bad examples. Within that lecture, I would give a warning to my students not to create things that might land them as an example in a future lecture. This typically got a chuckle from the class and would cause most of them to spend a bit more time on their final projects.
As part of our growing collection of UX design material here at ICS, we are assembling our own collection of anti-patterns. We’ll showcase examples of software from a variety of domains and platforms, from desktop to web to embedded, each with a cautionary note about why the developers really should have talked to a UX designer before releasing that particular gem into the wild. We hope you have as much fun reading these examples as we had assembling them. Look for an upcoming monthly series of posts into our UI Hall of Shame starting in early 2016.
- A Pattern Language, Christopher Alexander, Google website, last accessed December 28, 2015, http://books.google.com/books/about/Design_Patterns.html?id=6oHuKQe3TjQC
- Designing Interfaces: Patterns for Effective Interaction Design, O’Reilly, publishing website, last accessed December 28, 2015, http://designinginterfaces.com/about-the-book/
- Anti-Pattern Description, Wiki website, last accessed December 28, 2015, http://c2.com/cgi/wiki?AntiPattern
- GUI Bloopers, Jeff Johnson, website, last accessed December 28, 2015, http://www.gui-bloopers.com/