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.
Good post Steven. I’ve worked on some really big pattern library/style guide projects and the measure of success is ultimately about how useful the patterns are to development and QA. Any UI pattern library should always include code snippets or links to GitHub.
If a library doesn’t support code reuse it’s a sign that UX & engineering aren’t really working together as a team (and management isn’t making it happen). Sadly as a consultant, I still see companies that fail at this all the time. Teamwork is the real secret ingredient behind all great UX…there is no substitute.
Here’s a tip. if you include an example on the pattern page that uses the latest code, it removes the problem of updating things later on. It also has the added benefit that you know if there’s a delta between “as spec’d” and “as built”. Putting the example UI next to the image/spec makes it easy for the entire team to verify the pattern exists and to test it.
It seems that pattern libraries as you’re presenting here seems to be cast in a fundamentally old school way of doing heavy waterfall style speccing. You would get much better bang for your buck and encourage consistency across your product and platform by having a lightweight pattern library. Not a heavy spec heavyweight document.
A critical part of this approach is that it stay a living document similar to a wiki approach. Someone has to initially get the bones of the structure running but once that is in place, it’s a valuable resource in large teams (especially geographically challenged ones) to make sure we’re all doing functionality as consistently as possible within the scope of the requirements. You can’t have two calendars that behave or look like it wasn’t made by the same team or belong on the same site.
Developers should not be using the pattern library. A UX Designer worth his salt would never tell a developer to go refer to an internal reference document. UX should be providing developers with a working wireframe for the feature being developed using the pattern library as a resource from which that wireframe was built.
As you wrote, there seems to be an assumption that a pattern library has to be a dictionary. I agree wholeheartedly that most people can’t learn a language by referring to a dictionary. However, when a teacher (UX) uses a dictionary (pattern library) to teach students (development) the context and common definition of a word, it’s an invaluable resource. Can you imagine a world without dictionaries?
Interestingly, those are the same contradictions used in software development (the actual programming).
“Directing [devs] to look at a pattern library means that they have to find, parse, code, and review the pattern, in addition to the wireframe” … this part alarms me and is the crux of where things could go wrong.
As contrast: In a recent project we designed over 80 design patterns (and no fluff ones like “Radio Button”). These were only lightweight specced which we then took to devs and did some agile rapid prototyping iterations and refining of the specs before they went off and produced code modules. Importantly, this was a special dev team set aside to produce code libraries which the app devs would go on to use.
Note too that we didn’t just hand over all our wireframes and ask the devs to find patterns to code. We did consistency reviews and peer reviews of our wireframes (a necessary process in any case) and out of that process we identified the design patterns we were using. This process also encouraged us to refine and coalesce the design pattern definitions, removing some idiosyncrasies. If we didnt remove those idiosyncrasies but simply handed the wiredecks to devs to codify the apparent patterns they would of course had to code all those warts in too.
Another outcome of the UX design review and pattern definition process is that we actively participated in some uncomfortable discussions which exposed some differing assumptions about the UX vision we were theoretically hewing to. We refined the UX vision, and captured those findings into the pattern definitions as well.
Excellent article…and very timely! I am the lead of the usability practice for the Government of Canada. Today we started posting our pattern library online. These patterns will be used to increase consistency and usability of our web presence while building capacity (and awareness) in user-centred design.
Since we are building up a practice from very little previous capacity in this area, we needed a way to focus our energy and bring awareness to a completely new way of working.
Researching, discussing and documenting patterns (they start out on our internal wiki by multi-disciplinary groups) as an interesting first step to:
-building code packages that support user tasks
-communicating to the (many!) people involved in web development across a distributed network of organizations
-empowering anyone within the organization to provide potential solutions (or at least identify problems)
-providing requirements to designers and developers
The development of the patterns is just one part of a peer-reviewed process that includes usability and accessibility specialists, amongst others.
Each of the patterns in the library links to it’s corresponding code package. Our entire code repository is available online and is free for anyone to use.
You can see our works-in-progress here: http://www.tbs-sct.gc.ca/ws-nw/tmpl-mdl/index-eng.asp Comments welcomed
Thanks Stephen for this thought-provoking article. I definitely agree with what you’re saying, but with one small twist. Design patterns are good: they demand rigorous thought to create and are a relatively concise way to communicate ideas. However, I firmly believe that well-executed component libraries (i.e. coded, working elements) always trump design patterns libraries in both their communicative ability and their return on investment. I made a similar argument on UX Magazine about a year ago: http://uxmag.com/articles/from-pattern-to-component
I think a quintessential example of a component library is Twitter’s Bootstap project (http://twitter.github.com/bootstrap/). In a recent article on A List Apart, it’s co-creator Mark Otto described their approach as making it into a self-documenting style guide (http://www.alistapart.com/articles/building-twitter-bootstrap/).
From my experience actively curating a component library at TwigKit over the past two years, the two greatest lessons I’ve learned are: design and development must collaborate as closely as possible, and iteration is vital to success.
Thanks everyone for the comments & links! I agree with many of your points – patterns are not bad in themselves, but pairing designers with developers is much more efficient and leads to better results. A quick test: if the “right way” is in the pattern library, but not in your lead product, there is a problem.
Thank you for this article. I just spent 6 months putting together a new book for O’Reilly, Mobile Design Pattern Gallery. It is different from the comprehensive pattern library they just published called Designing Mobile Interfaces which is like an encyclopedia of mobile information. I personally can’t wrap my head around it and wanted to instead just pull together a whole bunch of solid mobile application examples across different OSs. I chose to organize this the gallery by common pattern categories like Navigation, Forms, Charts, Search Sort & Filter.
I’m wondering if this gallery vs library approach is more helpful to business owners, designers and developers?
http://www.mobiledesignpatterngallery.com
@Jocelyn I wrote up a quick article on this topic- Pattern Libraries vs Pattern Galleries:
http://mobiledesignpatterngallery.com/blog/?p=78
There’s a lot of truth in these criticisms. The pattern vernacular is like the stone in the stone soup tale that Jared Spool has used as a metaphor for a lot of tips-and-tricks dressed up as methodologies. Thinking in terms of patterns has some advantages, for sure, and I’ve seen them help designers and developers communicate better. But it’s far too easy to waste time documenting the obvious things and gain little in terms of saved time or effort in the future and, as with any documentation scheme, pattern libraries can fall prey to inertia and bureaucratization or to ego and turf.
I actually haven’t found it to be true that most pattern curators are motivated by a desire to put their stamp on what is right. I think the pattern-slash-wiki ethos is much more about shared understanding and emergent standards and I feel that the work we did in the Yahoo library and on the social patterns project (wiki, book, etc.) were much more about identifying the best thinking and citing the sources and building blocks (in some ways a quasi-academic exercise) and much less about a prescriptive desire to tell the world what to do.
There are some very good points. My favorite is: “Solve problems that you actually have, don’t worry about completeness.”
That being said a UX Designer should not have to tell a developer which library document to use just as he wouldn’t tell the developer which fields to call from the database or the creative director which font-style or color to use. The UX may have a development or creative background which helps him or her communicate with developers and designers but the UX’s role is to focus on the client and the user. Namely how do we design this “X” that the client wants AND have users intuitively understand how it works and want to interact with it.
I currently lead a mid-sized, globally distributed team of Ux design and usability practitioners. The article raises a number of valid critiques and questions.
1) My immediate reaction was to question whether Stephen Turbek actually manages a distributed Ux team. The “disparate time zones and geographies” factor alone is an excellent reason for having documented Ux patterns. The pattern library allows less experienced team members to reference the patterns at will, rather than having to wait for an overlapping times to network with more experienced colleagues.
2) Design patterns are not effective training tools. They are useful for some types of training, e.g., getting experienced Ux designers on the same page. I agree that they are not appropriate for training new Ux people how to do design. New designers require an apprenticeship model with oversight supervision, and ever-increasing levels of design challenges—until mastery is achieved.
3) Design patterns don’t replace Ux expertise. Agreed. However, they do keep a team of Ux people on the same page when they are trying to achieve standard Ux architecture and interaction approaches across a diverse set of product offerings.
4) Completeness & investment. Agree that pattern libraries are seldom complete and that they require constant updating. This is pretty much true for any dynamic, knowledge management practice. Updating multiple tool templates is simply an argument for using a standard set of design & prototyping tools within the Ux team.
5) Patterns should help non-Ux people first. Patterns should help Ux and non-Ux alike. I agree that pointing developers at a pattern library is a recipe for disaster—particularly if there are no accompanying Ux specifications and code samples. On my team, we created a “pattern quick start guide” in order to provide developers & new Ux’ers with a quick overview and orientation of all the key architectural and interaction patterns and how these work together.
6) Why pattern libraries? To keep a large, distributed team of designers on the same page with regards to overall patterns and standards of our Ux. On my team, we’ve always maintained that the patterns are not meant to be a strait-jacket, but rather living, breathing references. They will change and expand over time.
7) Building a design culture. Yes, reviewing is essential. On my team we do lots of it. Design should never be on auto-pilot. Simply applying patterns without thinking is a recipe for disaster. We would never do this. Documenting decisions on a wiki sounds like a potentially messy approach; unless the decisions are not put into a proper context in a timely fashion.
8) Documentation style. I’ve always felt that dynamic/animated patterns are easier to understand than static written ones—particularly for complex patterns. Yahoo used to have a nice collection of animated examples, but they seem to have eliminated these over the last few years.
9) Code libraries beat pattern libraries. Agree to a certain extent. Code libraries are important in terms of enforcing a more consistent Ux, reducing the amount of QA testing and special-case behaviors, etc. However a code library by itself doesn’t help Ux designers get on the same page. If Stephen believes that a pattern library enforces rigidity, I can assure you that a code library provides rigidity and enforcement on steroids. 🙂
In summary, I think my team’s investment in creating pattern libraries has been quite worthwhile. That being said, I fully recognize that pattern libraries will not make sense for every company. Like most things, it depends on what one is trying to accomplish.
I think Liam and others have done well to point out some of the nuances in this article that are begging for balance. I think good points are raised as well but I have a criticism about the approach.
So many articles are written that criticize an entity for factors that are not within their methodological limits in the first place. These kinds of articles totally confuse conversations especially when they bake a non-sequetorial negatives into their titles. If you want want to talk about the importance of UX expertise, talk about it. If you want to talk about how people rely on tools in lieu of expertise as a mis-use of them, that’s different from framing the conversation as a question of the foundational premise of that tool. Discussing the misuse of a method is completely different than discussion the value of the method. A tool is only as good as those who use it. In production environments where a lot more damage is done by not having a congealing framework to centralize points of view and discussion in a fluid yet centralized discourse, cultural development is stymied by tower of babel type scenarios. There will never be any perfect artifact or tool or process or temporal cultural dynamic that will be prefect and without flaw. But the emergence of the attempt to identify, discuss and use emerging patterns — whether in design, or a code library, or clear definition of terms, or anything else — is a critical fact of a culture trying to overcome obstacles to conceptual integrity and common mental model building.
Very interesting post. Disclosure: my thesis is about patterns. That being said, I do agree with your observations, but respectfully disagree with your conclusions. Let’s try to make it short and on topic:
– “Design patterns are not effective training tools.”, “Design patterns don’t replace UX expertise”.
That may be, but that’s not what they pretend to be. They are at first design guidance and communication artifacts.
– “Completeness and learn-ability are in conflict.”, “Design Patterns take a lot of investment.”
Same goes for any kind of documentation, I’m thinking about guidelines for instance. Do you think that we should put more emphasis on actual development (or hiring more people) and less on documentation? That would be a legitimate question, but again, not pattern-specific (in my opinion).
– Design Patterns should help non – UX people first
That’s subjective. But I totally agree with it. I actually wrote a paper in that direction: http://www.springerlink.com/content/pxn2nmkth6042703/
The rest of your article is about solutions. They are interesting but we can’t agree on the solutions if we don’t agree on the problem first, so I’ll leave it there. Again, it’s a good article and some of the problems you mention are very real. It doesn’t mean there’s nothing we should do. Thanks!
@Jon Innes: good point about linking the code to the patterns, and what it tells about how you are seeing both in your organization.
@Eric Scheid: very interesting, could you expand on that? The “lightweight specification” of patterns looks especially interesting.
@Laura Wesley: I’m heading to your pattern library right now. Go Canada!
@Theresa Neil Would you hqve the time to expqnd on the difference between a gallery and a library? Fwiw I read your article on the “Invitation” mobile pattern on UX Booth and found it quite nice!
Love the article because I agree whole-heartedly that Pattern Libraries/Galleries/Wiki’s are actually a UXer’s worst nightmare.
First, any of us who have been in the business know the patterns and a quick google search will provide you with more thoughts and examples on the subject than you could ever imagine.
Second, they’re not for us but we’re tasked with creating & maintaining them.
Third, if you don’t know the functionality of the basics and when to apply them properly (radio button v. checkbox), you shouldn’t be making those kinds of decisions. Period.
I used to write detailed functional specifications and storyboards for my teams and they were incredibly effective. What has happened? It seems that in an effort to keep re-inventing the wheel, we’re making more work for the teams and creating more swirl.
We do need documentation, but once a pattern is designed and applied, it is a living, breathing example of how to do it right – unless no one listens to ux and does it wrong. In that case the pattern “whatever” doesn’t matter anyway… This is especially true in the application world.
I think the bigger issue is integrating ux into the development process and allowing us to collaborate with developers to make sure they apply to designs properly.