For those of you who aren’t familiar with the meaning of a style guide, it’s a guideline that contains branding elements such as typography and logo treatments, social media icons, the color scheme, etc. This guideline is used to help keep a company’s branding consistent across the board. It also helps communicate to clients and other designers the styling that is used for both print and web.
A style guide should be thought of as a contract – and it shouldn’t be broken. Consistency is key in keeping a brand alive and a style guide helps keep the branding consistent. Some of the biggest issues I found with style guides is developing them when a company is first starting up. A style guide can help speed up the process when a site is being built out or when print items are being produced. However, this process can be hindered when the style guide is used the wrong way.
The style guide we use at REVOLT is just a general style guide that shows how the logo is used, the color scheme, the typography, a UI kit and the treatment of photography. Style guides can be a page long or a hundred pages long. It can be brief, like ours, or it can go extremely in depth like Skype’s which has 93 pages.
When working for a new client, we first start off with a ton of research about the company itself, it’s target market, the demographics and so on. When it comes time to start designing a new site or print work, we first start out with the design contract – the style guide. A designer puts a lot of time and thought into the style guide because it lays out the path for how the brand is going to be portrayed. The next step after the style guide has been completed is to receive its approval from the client.
After the client has approved the style guide, it’s time to wireframe the site, mock it up and send it over to the developer. It’s at this point in time where everything can go smoothly or can be halted to a stop. Most clients like to see the site as it’s being developed and, even after seeing and approving the mockups, they might change their mind. There could be a small amount of changes or many changes. The problem with having many changes is that it stalls the process and delays the launch date.
For example, let’s say the client decides to make a couple color changes. The designer has to go back and make these changes to the style guide and mockups. These changes then need to be communicated to the developer. Making simple color changes in development are easy, but they can be time consuming. Once the changes are made, the client will most likely view them again. Some clients will be fine with the changes, while others might want more changes.
The point I’d like to make here is that a style guide needs to act more as a contract rather than something that can be continuously changed through the initial process. Of course companies will rebrand every now and then and make some major changes to their style guide. If a company isn’t being rebranded, then changes shouldn’t be made after its approval. Any changes to the style guide should only be made before the development of print, a website or other media work. I believe describing this process to your client and having them agree to it will make for a smooth transition from design to development. This process will also help retain the initial launch date and remove any confusion between the developer and designer.
