Whether it’s sheet music for an orchestra, a user manual for a Roomba s9+, or a memo passed around a cubicle office in the early 90’s, we humans are used to having documents that keep a group of people on the same…page. A style guide is just that for people collaborating on anything web: a reference guide outlining a brand’s presence online, informing current and future stakeholders as to how the UI designs elements should be consistently represented.
In other words, it’s a brand guide for the web. An up-to-date log of the web application, the place where developers can go to find the information and assets they need to build. The trick is to remember to update it constantly, so it remains the single source of truth for all.
This article will touch on how a style guide helps designers communicate with developers throughout a project, as well as being a final design deliverable to hand over to a client after everything’s wrapped up.
Elements of a style guide typically include, (but are not limited to):
For larger projects, this document can quickly become lengthy, so you might want to break it down into individual artboards or sections.
Even if this is a company’s maiden voyage on the web, logo assets and guidelines are typically spelled out by the client. At least a couple variations of their logo likely exist: a darker version for light backgrounds and a lighter version for dark backgrounds. Having all variations already compressed at different sizes and spread out on one page is preferred, with each available as an export in multiple formats (SVG, PNG, JPEG, etc). Having a section for third party logos can be helpful as well.
Brand colours also typically come from the client but sometimes need to be considered in different formats for use on the web. If they already exist as HEX codes, great. But if they don’t you’ll have to convert them from CMYK or RGB to HEX. Including all these types of values in your style guide is a good idea.
In addition to primary brand colours there are typically secondary, font, and background colours that often sprout up that should be documented here too.
Each colour should be uniquely named, with their HEX code easily copyable.
This is where you outline all heading, subheading, paragraph and other font styles that are to be used across the project. Font sizes should always be stated in pixels (px) not points (ppt), and should never be under 12px, across all devices. For each type, clearly state its name (ie. H2, paragraph, etc.), font name (ie. Times New Roman), font weight (ie. bold), font size (ie. 21px), line height (ie. 30px) and colour (ie. #FFFFFF). All this information should be laid out clearly for developers.
This section can include various elements such as call-to-action (CTA) buttons, radio buttons, drop select buttons, check boxes, toggles, tags, tooltips, prompts…. the list can go on. Including height/width measurements for each is super helpful when a developer scans the document. ‘Default’, ‘hover’ and ‘selected’ states should also be included and organized in a table format with clear headings.
Full bleed image, container image, thumbnail gallery, image carousel, a selected expanded image, profile images, etc… all of these should be isolated in one section of the style guide, just as they appear on the final mockups. Other instructions like art treatment (ie. if certain images should never be cropped), aspect ratios, and caption typography can also be included.
Form UI is a pretty important one to front load right off the bat, as it tends to have more complex user interaction and is something developers can start on right away. Just like buttons, every Form UI state should be laid out and labeled. They can include: default, hover, focused, active, blurred, error and success.
Tables, ordered and unordered lists, etc, may also be found in this section.
Components that show up frequently across the application can be a nice feature to have. Remember, a style guide should be an easy-access document (or set of documents) so that a user can quickly find what they need. Instead of digging through all the finished prototype boards to find, say, a card layout for events, they can go straight to the style guide page entitled Components. Here all the variants of each component can be laid out and labeled where they appear. Such components might include hero layouts, 2 column feature sections, cards, image galleries, prompt messages, and so on.
Whether this appears in the style guide is really up to you. It can be a standalone board or a section on another page, but no matter what, global navigation should be clearly mocked up and always up to date, lest any inconsistencies result in building an unintended site structure. If the project has multi-admin users, don’t forget to include all possible types of navigation, and which user it’s intended for. Include any logos, menu headings, subheadings and CTA buttons as they are to appear on a given page. Mocking up the navigation in default, all possible hover states, collapsed and expanded views, are recommended, since this will likely be the only place its UI will be laid out. Lastly, be sure all responsive versions of each navigation are included - with collapsed and active versions of hamburger navigation for mobile devices, if that’s the design.
Having everything spread out and super accessible makes it easy for developers (and anyone else who has access to the project) to grab what they need at any time. The process won’t get blocked because the designer’s on holiday. Or conversely, the designer won’t get a message in the middle of the night when someone needs a logo as an SVG.
Whatever prototyping and design feedback tool you use, consider how the style guide will be used. Are sections and subsections clearly labeled? Are all creative assets exported in the desired formats? Maybe you want to use navigation tools like menu headings and links between artboards so the user can access information in the most convenient way. It may seem far-fetched, but thinking about a style guide’s information architecture will only help out the collaborative process.
