People trust the familiar. Knowing that, many designers strive to keep their work as simple as possible. It’s also practical: once you design, say, a navigation bar, then duplicating it to every page or view is easy.
But standards change over time. New designers with fresh ideas inherit old projects. New code techniques replace last year’s bleeding edge. The result is a mishmash of inconsistencies in both the visuals and underlying code. And that leads to trouble.
What is design consistency?
Design consistency is the practice of keeping a product looking and acting like a cohesive unit — as if it was planned from the start, even after changes occur. It’s an exercise in branding that helps users find their way around, especially in large sites.
In principle a consistent design is also easier to create and maintain. There’s no time spent inventing new elements that might not fit the established look. From a development standpoint, drawing from a library of pre-built components can make code copy/paste simple while creating fewer chances for bugs. Reusing well-tested code isn’t a bad idea.
Inventing standards is relatively easy. But enforcing them isn’t.
Design system documents keeps projects in line
The best way to maintain consistency is with a document that spells out how — and why — the brand looks and functions.
A design system doc does just that. Providing guidelines, design systems keep everyone in line with the tone, look, and behavior to which a project should adhere. Good docs also explain use cases and best practice, contain code snippets, and show practical, visual examples complete with source files like Photoshop and Sketch files.
That’s a lot of responsibility for a single document. But there are ways to make it work.
Get high-level approval. Designers who implement the work — the folks who push pixels daily — should get their product manager’s approval to keep things official. Many times, explaining that a design system document will help prevent future cost overruns will get their attention faster than “I read it on a blog.” Ahem.
Make it part of the contract. Whether you’re designing for an outside client or an in-house department, a formal agreement of deliverables and responsibilities will help define the project, alleviating scope-creep and declare who’s in charge of what. The final product is often the main deliverable, but to make the product last beyond launch, you should make the design system doc just as important.
Get everyone’s sign-off. From the PM to the dev intern, everyone it affects should know about the design system document. This is especially true when it’s in development. Keep everyone informed and keep stakeholders, like the art director, lead developers, and project managers, involved. Then — and this is key — get their official approval for the final doc. Hold them accountable for their buy-in. Knowing a signature is required makes people take a doc more seriously.
Make it available. Don’t lock the design document away. Whether it’s a file in Dropbox, an internal website, or a Google Doc, tell everyone where it is so they know where to go when design and development questions arise.
Make it practical. The ultimate design system doc isn’t just a doc; it’s a collection of resources or a pattern library from which people can grab ready-to-go resources. In particular, templates and code snippets will help design teams knock out new work quickly.
Keep it fresh. Review the doc every six months or so to make sure it still fits the organization’s goals and user’s needs. For example, do users still understand the iconography? Has customer service or user testing unveiled that users respond better to a friendlier tone? Does the business still want to emphasize a certain call to action? Have visual trends changed? Schedule a time for design system stakeholders to discuss changes, if any. As designer Brad Frost put it, “Once the pattern library ceases to reflect the current state of the products it serves, it becomes obsolete.”
Above, a design system document includes typography, color, styles, and notes on use cases.
What needs to stay consistent?
Depending on the project, many things. On the visual side, color, typography, iconography, and placement of site-wide elements are important to help users recognize what means what.
But don’t neglect behaviors. From modal boxes to drop-down lists to colored links, the way a site works is as important as how it looks. For example, think of icons as promises. Everywhere you see a given symbol, users should know what to expect. And when users know what to expect, they’re more likely to feel comfortable with your brand.
Tone and voice are important too. When a project, especially a large one, needs to tell users many things, having a consistent message will help reassure the users that they’re still interacting with the same brand. Not only does MailChimp do a great job of defining their voice, they also publish it for everyone to read. This should also apply to microcopy, from form labels to submit buttons.
Finally, the code. Few things drive developers crazy like having to relearn six-month-old code while hunting for that one missing semicolon. The more consistent code is, the easier it is to adapt and troubleshoot. Love ’em or hate ’em, frameworks like Bootstrap and Foundation are excellent examples of how a common codebase makes debugging code easier, especially between different developers.
How to test your own consistency
How consistent is your project? Here are a few ways to find out.
Audit your interface. Take screenshots of every element you can get your hands on, and list them by type. Don’t assume they’re all the same, or that you already know what they look like; get everything in a single view for comparison.
Audit your code. Most digital products are based on a core set of code. List exceptions to the rule.
Ask users for their workarounds. Would people rather use your search tool than the navigation bar? Discover how people actually use your product, rather than how you wish they would.
Share your findings. Show the results with your team or project manager. Surprisingly, having to explain inconsistencies often reveals one-off solutions and ill-informed assumptions.
Consistency in design keeps a product looking and working as if it was planned — not just on paper and prototype, but all the way through the user experience. People tend to trust brands more that they can figure out, without having to relearn its UI conventions.
After the initial investment, consistency can make future design and development faster, easier, and more cost effective by removing guesswork. And they do so from a single source: a design system document, whether it’s a pattern library or a single PDF, that provides best-practice guidelines and tangible source files.
Remember that design inconsistency occurs when new team members replace old ones, or current designers and developers try to improve upon their old work. While neither is unavoidable, designing and developing from a common template is the key to consistency.
Inventing standards is easy compared to enforcing them. But both are important to keep a project in shape. Let the doc inform the product, not vice versa.