One of the most beneficial activities you can do on a large design project (especially if it’s a web application) is to define a pattern library. This architectural document details the framework that all the UI screens and screen elements must use/follow. I like to explain what a pattern library is from the perspective of a journalist (it was my first college major) – I ask the standard questions who what when where why and how:
Who will use the pattern library? Developers? Other UI designers? QA? The details of the documentation supports the intended audience(s).
What does the UI element look like? How is it displayed and presented to the end-user?
When do you use one UI element rather than another? Provide examples of usage so that this can be clear.
Where in the UI are the elements presented? The pattern library should provide “templates” of the different types of screens so that positioning and placement are clear.
How do the UI elements behave? That should be specified explicitly and clearly. You notice I left out the “Why,” and that’s because the question is: Why have a pattern library in the first place. There are several reasons:
- It provides a reference for future UI design work.
- It documents UI behavior in one place instead of having to document it at the field level on al the design specifications.
- It allows for one “source of truth” for all parties, thus reducing confusion.
- It provides for a mechanism for enforcing consistency, which allows for structured design work.
- It reduces design churn, it enforces consistency, and helps ensure quality.
The pattern library should have three primary pieces of content:
Templates: Details of the different screen types in the site or application
Containers: Collections of different UI elements (such as a results table)
Elements: Details on the discrete UI elements and rules around usage and implementation
A pattern library is traditionally NOT a style guide and so does not contain branding information – it to be used as a reference for UI designer. You can design a pattern library one of two ways – bottom up or top down. Bottom-up means you look at an existing UI structure or set of screens and you define the patterns based on them. This is the right approach if you are redesigning a legacy application, and you can do this at the same time you do a heuristic review of the application. Top-down means you look at defining page templates and standards from scratch (leveraging best practices and existing pattern libraries, of course).
Pattern libraries aren’t for everyone, as it takes a focused perspective to create an artifact that is useful and usable, and some projects are small enough that such effort is overkill. I was on one project where the person who created the pattern library took upon the work like it was the Great American Novel, and the results was a top-heavy document that was not the least bit user-friendly. For a good example of how to do a pattern library right, look here: http://www.welie.com/index.php
Good luck!