Design patterns are generally considered a good thing, but do they actually help run a user experience group? As a user experience group manager and an observer (and sponsor) of design pattern exercises, I’ve come to have serious questions about their actual utility. It’s not that design pattern libraries are bad, but that in a world of limited resources, it is it is not clear that the investment is worth it. Fortunately, there is a better approach: reaching outside the design group to solve the whole problem.
An interaction design pattern is a “general, reusable solution” “to common usability or accessibility problems”. They usually consist of pictures and descriptions of the best way to handle a GUI design element, such as a date picker. Libraries of them are found online (see below) and in many institutions with a user experience practice. Like all tools, they exist to solve a problem; but what is the problem?
They are generally said to help:
- instruct junior user experience people
- save time of documenting design details in every project
- make collaboration with developers easier
- encourage consistency
The case against design patterns
Pattern libraries have laudable goals, but in practice, design patterns do not support how teams actually work. Practically, the pattern approach assumes that the users:
- know (and remember 3 months later) that the pattern library exists
- quickly find the pattern that they need
- know how to interpret the language
- know when to apply a particular pattern and how much they can deviate
- have the time and motivation to continue documenting ideas
Design patterns are not effective training tools.
Patterns, once literally a design on paper that could be copied, in UX are an abstract idea that professionals can reference. You can not copy a UX pattern, like you can copy a sewing pattern. Having someone read a pattern library will not make them a competent user experience designer. It would be akin to teaching writing by reading the dictionary – the “why”s are not answered.
Design patterns don’t replace UX expertise
Design patterns can be a useful reference point for the junior user experience designer. But experienced professionals find ideas and inspiration in the whole world. Should your team invest time in making a pattern library as a training tool, or just change the way they work? Should they spend time on documentation or collaborate on projects? Should junior people learn from the documents or, as is typical in the crafts, apprentice with an experienced designer?
Completeness and learn-ability are in conflict.
In order for a pattern to be used, it has to be easily read. But completely describing even the simplest UI pattern (like a two-panel selector) requires such detail as to prevent the person from absorbing it. Additionally, any design pattern I’ve seen inevitable contains “it depends” clauses, which leave the important decisions right back with the reader.
Pattern libraries suffer from a similar problem. Many seem to start by defining the basics, to answer questions like “when should one use radio buttons versus a drop down menu”, but lose steam before they get to the complex pieces. This is ironic, as the complex interactions are the ones that need the most definition, and offer the most creative opportunity. Defining the pattern of a radio button, is necessary for completeness, but not a good use of time or creative energies.
Design Patterns take a lot of investment.
The investment in the library needs to pay off in later efficiency to be successful. But each pattern is essentially a mini design project with extreme documentation and design reviews. Having corresponding template widgets is an additional effort, as is updating the designs when the inevitable rebranding comes along. (I’m already tired just writing this.) If your team uses more than one design tool (InDesign, OmniGraffle, Visio), who is going to update all the versions?
Design Patterns should help non – UX people first
Design patterns reduce work for UX people, but they clearly increase work for developers. Developers operate under time pressures and need a spec to code to. Directing them to look at a pattern library means that they have to find, parse, code, and review the pattern, in addition to the wireframe. The design pattern’s open ended nature requires them to read a general case and code a specific case. Because they are just designs, they can also ignore the ugly complexities in many of the problems, by simply not addressing them.
Design Patterns don’t work with a normal designer’s motivation – indeed, they seek to restrain it. When a person sits down at their drawing program to address a problem, a reference document is several steps away, especially under time pressure. They almost always want to design rather than copy, especially, when it is unclear if a new situation is different “enough” from an existing pattern. On the contribution side, any change will entail a review with peers, which could take weeks to finalize, too slow for a project. Large organizations who most need a pattern library (many practitioners) are least able to build one (complex organizations, conflicting deadlines).
Why do people make design pattern libraries anyway?
I’ve never heard of a business owner or technology lead asking for a design pattern library. They seem to arise from internal concerns rather than external requests. What if the motivation is not really project efficiency, but something more personal?
Pattern libraries seem to be made by a UX person who wants to put a stamp on how things SHOULD be done. To establish, once and for all, the right way to do something. The design pattern library could be more akin to building a model train set: like the real world, but controllable. They are like design projects without clients or time pressure. “Just this once, we’ll do it perfect”. A participant at a recent New York IXDA event said with pride that he personally had created several pattern libraries –it was a personal accomplishment, not a business achievement. No one can argue with how a person spends their free time, but teams have to make sure work time is spent wisely.
The downside to this motivation is that individual authors want to create their own collection, which inevitably duplicates the other libraries. Pattern Libraries also tend to be abandoned when the author loses enthusiasm after the initial burst of activity. Even the major sites like Yahoo and Welie have stalled. The last update on Yahoo was 2 years ago; Welie was 4 years ago.
What is the solution then?
Let’s apply the user centered design process to this situation. Using the goal of “better designed products and increased productivity”, we can identify the three potential audiences of an enterprise Pattern Library: User Experience, the Business representatives, and Technology.
The UX group is primarily concerned with consistency and best practices. This is culture, not documentations and should be managed as such:
- Culture is built through personal interaction. Review, Review, Review. Regularly meet to share work, and best practices.
- Patterns do not mean your design sense can go on auto-pilot.
- Build a collaborative culture referring each other’s work. (“Joe worked on something like that.”)
- When a new design challenge appears, get a bunch of people to talk it over, get “good enough” agreement.
- Document decisions quickly and spread widely, for example on a wiki (so any one can edit it).
- Focus on content first, make the pretty library template as a reward for reaching 20 patterns.
Business and Technology are primarily concerned with getting work done and reducing costs. The biggest efficiency gain is reducing development time, focus on giving developers the tools and guides they need. The biggest issue is that typically, UX people do not code. The solution is to get out of the design cave and work with people who do.
Create a design ecosystem instead of documentation.
People do not RTFM. Period. It is hard to get people to engage with any documentation on their own. They are happy to read the details about what they want, but are put off by finding it inside a large document or library. The solution is to create an ecosystem where each piece reinforces the others. iPods were well-designed devices, but they succeeded because of the ecosystem (devices +iTunes + stores + accessories). Music was easy to find and buy, and easy to put on the computer. The overall experience of the ecosystem is what determines the success. When you say the answer is a document, rather than a community, it turns people off and limits their contribution.
The ecosystem should be composed of:
- People: Developers, Designers, and business leads. People who can answer questions, who are motivated by their own job requirements and professional pride
- Code library and documentation
- Management demand
A code library beats a pattern library
The code library should be “internal open source”, a shared library enabling developers at a company to share code without worrying about licensing or malware. Instead of the whole org waiting while a centralized team builds the future, let every group contribute.
It should have the most commonly needed components with brief descriptions and links to example implementations, bug tracking and feature requests, supported by an active development and UX mail lists. Make them easily accessible as web pages, not a document. Style guides and pattern libraries get retained even if they are out of date. Social connectivity is much more important than printing them out.
It should have the most commonly needed components with brief descriptions and links to example implementations, bug tracking and feature requests. This is supported by an active development and UX mail lists.
For each presentation layer technologies you support, there should be in Version Control system, with a Main branch, supported by a core team, and an open Contrib branch that anyone can put components in. Good components are promoted to the main branch, which is released in versions, so updates do not break existing apps.
Components should cover three scales:
- Basic styling of standard components
- Custom components, like a date picker or type-ahead
- Page sized components, such as forms,dashboards, or search result pages
How do you get such a library?
In a world of limited resources, one has to boot-strap the Library.
- Build off of the current running projects. Nominate widgets or functions in an active project as “library-worthy” and have them coded abstractly and contributed to the library.
- Publish and reward people who contribute to the library.
- Make a most wanted list and see who has them.
- Solve problems that you actually have, don’t worry about completeness.
- Have the patterns in working code samples accessible by anyone in the firm. Instead of pretty pictures, have the code that actually performs how your want it to. Make the options / parameters editable in the sample, so anyone can play with configuring the sample.
- Look and feel should be a separate code library, released in parallel, so that the design can be upgraded in the future (as it will be) without affecting functionality.
- For general guidelines, write high level guidelines a sketch or two, but point the developers to ask a mailgroup of designers and front end engineers. When a question gets asked enough that it is annoying, code the pattern.
Management support is critical -if the project is a “nice to have”, it is doomed. Each project should report what they contributed to the library and what they consumed. A developer’s performance evaluation should list what they contributed to the library and what they re-used -Both save the firm money. At a firm I worked at – a single component, taking 2 weeks of two developers’ time, was re-used over 200 times. This saved 16 person-years of effort -this is real money. Not every component will be so effective; the library team should be focused on the business value of each component and the user experience of the eco system. If done right, the design / code ecosystem has the potential to both improve design and save time, something we can all agree on.
Design patterns are not, in themselves, a bad thing, but in the real world, it’s better to focus on the lifecycle of design, rather than the design process alone. Working together with non designers can make everyone’s life easier, and make the final product as good as the design.