April 18, 2014
Projects at Fastspot tend to be large content managed websites that require not just design, but fully realized design systems to support long term success. That requires a client’s ongoing participation. And it doesn’t matter how elegant or intuitive a system is, if a client hopes to “follow the rules,” he or she needs an instruction manual.
Style guides are often created at the end of a project to document the decisions that have already been made. We’ve found that instead, the best time to create a style guide is immediately after a design direction is selected, before any secondary pages have been designed. It’s the perfect time to iterate, since the project has a clear aesthetic momentum, but the design is unrefined and there are a lot of problems yet to solve.
Creating the first draft of the style guide highlights inconsistencies that may have crept into a design during the creative process:
- colors that are supposed to be the same but have different hex values
- typography decisions that are incrementally different
- layouts that violate the underlying grid
- image aspect ratios that are all over the map, and others
The act of articulating the strategy behind aesthetic decisions and distilling elements of a design down to its basic parts forces you to revisit decisions and verify that they were purposeful. The first draft of a style guide is an opportune time to consider what gives the design its unique character and how that character can be maintained while the design system expands.
The benefit of starting style guides early extends throughout the design process. In our process, the number of designers that touch a design increases as the scope of the design increases. Once the core constraints of a design have been clearly defined, all contributing designers can be working from the same rule book, which saves time and iteration. As a design system grows so does the documentation – each new design pattern and unique element is discussed, vetted, and eventually documented in the style guide. The style guide becomes a valuable tool for taking stock of the scope of a design system, what features might be missing, and how each design element affects the overarching system.
What actually belongs in a style guide is changing
It’s no longer enough to document the fonts, colors, voice and tone, link style, button style, etc. Sure, the basic elements of a design should be included, but it’s important to go into detail about how to combine those elements.
Ask yourself: How does the grid system work, how is an event presented differently than a news article, is there a standard format for presenting profiles, how should video be presented, what about a group of videos? Documenting the detailed design patterns and not just the building blocks is infinitely more helpful for ongoing practical use.
And design doesn’t end when development begins — our designers don’t hand off flat files and then clock out of the project. Everyone stays involved until a project launches, and the style guide continues to play an integral role.
Develop the style guide first
We kick off development by building all of the elements of the style guide in one long scrolling page we call the “component reference”. Developing in this way removes design elements from the context of specific pages which promotes more semantic HTML and better CSS naming conventions. Avoiding unnecessary namespacing has improved the efficiency of our CSS by promoting better habits and improving the overall cascade. If we add new features to the design style guide they are promptly developed on the component reference. Maintaining a one to one relationship helps to organize our development process and keeps everyone on the team involved with production.
Finally, developing the component reference has been a boon for quality assurance. Reviewing all design elements and content patterns on a single page is a great way to test responsive breakpoints and scan for unintended consequences after each revision and addition to the project.
Style guides and component references document and define the design systems that we create on behalf of our clients. They elevate the quality of our design and improve our craftsmanship. The act of documenting a design system helps to clarify the bounds of the system, all of which benefits our internal process and in the end, helps us to create better websites.