Everyone has their own design and development style. One person’s
.class-name is another person’s
.className in CSS, not to mention HTML formatting and how people organize their Photoshop layers — if at all.
Teamwork hinges on people’s ability to get along, yet disparate file-organizing and naming strategies can make things hard to deal with. If Bob goes on vacation, how is Alice supposed to carry on his prototype work on the important $50k Big Ranch website redesign?
That’s where design systems come in. Design systems do more than provide visual and interactive style guides to which teams should adhere. They also make their contents easy to find. After all, UX doesn’t just apply to non-designers.
Organizing a design system’s pattern library
Pattern libraries contain templates upon which to build instances of design. For example, a list of the ranch’s amenities is a list plus real content. The list itself — its bullet point style, its line-height, its maximum and minimum widths — are parameters upon which one-off lists are made. Does the client need a list of their ranch houses for rent? It’s the list template to the rescue.
The trick to pattern libraries is — well, it’s not a trick. It’s common sense with a dab of discipline. No matter what you put into a pattern library, each component, widget, and element will need a few common bits of information that makes them easy to locate in a hurry.
Name things how they’re used. Avoid specific names that describe context like “horse signup template”. That describes what it contained when it was built — and obviously it’s a template. Instead, think about how it should get used, now and in the future: “signup form” or even “basic form” are more useful and more applicable to future needs.
Write a (brief) description and use case. Consider the following:
“This form has a photo, three to five radio buttons, an email field, and a submit button.”
Anyone could tell that by looking at the form. Try instead:
“Use this form when asking users for personal information and you want to reassure them that they’re not going to get spammed.”
Include a version number or date. Patterns change. Most digital assets do. That’s why versioning — anything from 1.x to 2017-01-01 — will help you weed out old patterns and track your library’s evolution. Bonus points if you use a versioning system like Git to track “what if?” experiments in branches and copies.
Pattern use cases
Cite live examples. Whenever possible, reference examples of how the pattern’s used in the wild, rather than with generic placeholder content.
“Best used for ….” What is a pattern good for? Answering this is tricky because, at least the first time, patterns are often created to answer one-off needs. The best bet is to try different contexts. For example, on how many different pages could a specific header get reused? What would have to change to make it work? Think generic. “Best used for third-level inside pages” is more useful than “best used for pages that feature barbed wire.”
Include sample variations. Plain-box templates are useful for low-level views of a template or element. But seeing it in action — several times — will help your team understand its versatility (or lack thereof).
Categories: Organizing your assets into groups is an obvious approach to organizing at all. But what should the groups be? Some suggestions for categorization:
- Based on psychology, like those found at UI Patterns.
- Based on prominence, or how important a pattern is to the project.
- Based on type, as in “teasers,” “primary content,” “lists,” or “panels.”
- Based on application, like “layout,” “navigation,” or “social.”
- Based on frequency of use: “major,” “minor,” or “supplemental.”
Tags: In general, categories divide different types of information, while tags create cross-references among them.
- Primary color, if a pattern requires a certain hue or value.
- Version number — there’s that concept again.
- Style, such as “bright,” “textured,” “elegant,” “illustrated,” or “flexible layout.”
- Resources: don’t think of patterns as strictly visual. Remember inclusive tags like “has HTML,” “has CSS,” “has PSD,” and “has content.”
Meta data: Information about the pattern is just as important as the pattern itself.
- Informal title: How do you refer to the pattern?
- SEO title: If we’re talking about an entire page layout, what guidelines do we follow to make it search-engine friendly?
- Last modified date: When was the last time someone tweaked the pattern?
- Next check date: When is the next time the pattern is up for review?
- Author: Who is responsible for the pattern’s upkeep?
- Medium: Is it a layout component? A video template? A single graphic?
- Size: How wide and tall is it? Does it adhere to a particular layout grid? If it’s video or audio, how long does it last?
Notice that the tags listed above are adjectives, while categories lean towards nouns. Metadata, meanwhile, answers questions. Use these as cues to forming your own taxonomy.
Pattern libraries work with a team’s workflows
Whether Bob’s file is called brown-cow-teaser-5.psd or Photo-2017-01-01.psd, a curated design system helps Alice find it by type, description, use case, or maybe even dimensions. The goal is find-ability, not just search-ability. Your team should be able to round up assets its pattern library by browsing as searching.