Style guide - a digital campfire to unify system with organization

A style guide used to be a static document for a brands visual language in terms of the brand logotype, colours, fonts and typography. A style guide today is so much more than that. Style guides are starting to become a common strategy for organizations to manage both brand consistency while also setting a common standard for development and maintenance of entire application landscapes.

Establishing a design system means that the building blocks of your design system are going to be spread out and utilized in several parts of your applications. Possibly with different teams working with them in different projects, with different release plans and different goals for each project. To ensure that everyone has a common understanding of the design system and work towards the same goals, there needs to be a meeting point. An obvious place to see all the pieces that your design system consists of along with guidelines, processes and some guardrails.

Which are the puzzle pieces that build up the solutions? What do they look like and how do I utilize the design system in my particular application? Which parts of the system are relevant and how, where and when are they relevant to me?

This is where the style guide comes in. When done right, the style guide becomes your organization’s digital campfire, your common meeting point and single source of truth for everything related to your design system. In this article, I will walk you through what a modern style guide is and how you can start your journey towards it today.

The fundamental parts of a style guide

There are a few different interpretations and variants of style guides and what it consist of, but as I see it, a style guide needs to consist of the following 5 parts to bring value:

Visual language

The heart of the style guide is the visual language. It shows your organization´s graphical directives such as the use of colour, fonts, typography and space as well as the organization´s logotype and if there is a certain preferred way to use images. This is a good place to start since it will permeate every UI component in the whole system.

Component library

The component library is the home of the actual design patterns and components in your design system. This is where you can view visual examples, guidelines and UI source code of the buttons, lists, navigation menus, forms etc. The components should be built on a modular UI architecture to be utilized entirely stand alone, context- and project agnostic. I will cover modular UI architecture in more depth in an upcoming blogpost.

Processes and methodology

Working with a design system will imply changes for your design and development processes and it often goes along with working according to a style guide driven development process. The aim of this process is to integrate your design system with your organization. In short this means that the style guide acts as a single source of truth and that the style guide always is the obvious starting point for user interface development in any way. If something new is developed in a project or application, for example a new design pattern or a new component, it should be added to the style guide to add value to the whole design system.

Directives and documentation

Many organizations are working in silos, having problems with the left hand not knowing what the right hand is doing and vice versa. If documentation exists it is not always accessible, or updated sufficiently. When providing directives and documentation, the style guide acts as a live and automated documentation and specification of the design system. The directives should include:

- Overarching directives
Which level of accessibility do we meet? Which browsers and devices must we optimize for?

- Directives on component level
What is the purpose of each component? How, when and where can and should I use it? How should I not use it? Did someone make our primary buttons blue because it looks nice or because this is our primary action button and blue is our brand color? Is this blue actually our brand color?

- Common terminology
Does everyone know what a "teaser" or what a "toolbar" is? Naming conventions enables a shared vocabulary between different project teams and even different competencies.

Templates, examples and prototypes

To fully grasp the ways that the design patterns and the components can be used, examples of how components are combined into larger components and even complete pages is key. Setting up common templates for pages where you can easily add components as puzzle pieces from the component library to build something bigger, will act as a perfect space to rapidly set up prototypes to test new ideas.

The different parts of the style guide can vary in scale and complexity depending on the needs of your organization and still bring out significant value. This following simple maturity model describes how you can embrace different levels of integrations and how your style guide can grow and become more complex over time as well as generate more and more value depending on how it is built and integrated.

Levels of integration – a style guide maturity model

Static style guide

I am always torn about mentioning this type of style guide as an actual style guide, I keep questioning this every time I talk about this model if it really deserves its existence in the model – but I still feel this is an important level even if it is not really a “real” modern style guide as how I have described a style guide above.

The static style guide is very common for many organizations. It can be a static web page, but often it is a PDF document, with graphical guidelines and sometimes UI components that acts as a style guide. Since it is a static document, it is up to every application and project to make their own interpretation of it. It doesn’t really matter how extensive it is – if it isn´t being updated in the same speed as your applications and the changes within your organization, your style guide will very soon be out of sync and cannot be trusted.

That being said, a static style guide is still a good way to start if you are clear about it being static. It is still better than nothing at all and it is still a good start if you can´t take a big leap right away. The solutions you build will be able to speed up development and improve the overall quality and user experience as it will resemble that of the components in the style guide. When you build new solutions, they can use the same resources as in the style guide, for example logotype, icons and perhaps even UI code snippets.

Another aspect is to use the one-time style guide as an inventory of which design patterns and common components you have within your solutions. This can work as a great stepping stone for visualizing your system and build a common understanding for further efforts, without too much effort and time (read: show this to your manager to prove your point!).

Manual style guide

In a manual style guide, every part of the style guide is implemented to some extent. There is at least a visual language part and a component library along with documentation and directives. Parts of the style guide is being used in the applications.

The component library is made of components with real UI code that can be copied from the style guide along with the latest version of the component library into the applications, as a base for further development. The inclusion is one-time, one-way and based on a copy and paste process. This means that your applications can always use the latest version of the UI code from the design system, but each application will have a separate UI code base which means duplicated code in the design system. Any updates in the component library must be applied manually to all instances that are used throughout the application ecosystem.

Integrated style guide

An integrated style guide has the same base as the manual style guide. At least one application has been built on the style guide. It is used as a product with its own release cycle and lives side by side with the applications as an essential part of at least one applications build process. It has been around for longer than the manual style guide so that it is proven to be aligned with the processes within the organization. Every application may decide which parts of the style guide to use, it is up to you how flexible you want to be – but the style guide is built ready to empower every application that is open for it by setting the standard and foundation for a consistent user experience and a standardized code base.

A living style guide

A living style guide has the same base as the manual and the integrated, but a living style guide is governed by at least one person, preferably by a team, and has been accepted, supported and contributed to by the organization. A living style guide is largely self-sufficient because it is fully integrated in the organization’s design and development processes. The development in every application contribute to the growth of the style guide and the style guide contribute to consistency and scalability of the applications. I will cover the management and work with style guide governance in more depth in an upcoming blogpost.

One common UI code base

A technical bonus to add to your style guide is to consider using a templating language and/or an API for your component library. This would enable components to be rendered real-time, both in the style guide and in the applications. It means that you can have only one common UI code base and that any update in the component library will benefit all applications where the updated components are used. This of course has great positive impact on user experience and the maintainability of the applications.

As it can be a bit of a high threshold I would suggest that you start building from the ground up. Take small steps to fully integrate the style guide into your development process and see what will best suit your needs and what will bring most value to your organization.

Why can´t I just use someone else´s system?

You can and I would suggest that you should if you are building something that is not going to be maintained. There are a lot of frameworks out there and some of them might fit your needs.

But as soon as you have a brand you wish to promote; your organization will be served by having a strategy for its web presence. As soon as you have any type of active web development; either external websites or internal web-based applications, your organization would benefit from having a style guide, and thus a style guide-driven development process to some extent.

The problem with using someone else´s system is that it will never be built for exactly your needs, it is often too easy to paint yourself into a corner as soon as you wish to change or customize something. Using someone else´s system means that you commit to someone else´s standards, structure and development cycle. Beware of and look out for how much time you spend on using and benefiting from the system vs customizing, modifying, extending or even fixing the system.

A living style guide – updated, never outdated

In my last blog post I discussed how establishing a design system will help you to see the big picture of your web presence and application landscape. How working systematically with a system will set the foundation for building consistent, flexible and scalable solutions.

The key to ensuring that your design system will not only be implemented, but continues to bring value and evolve consciously, is to visualize your design system in a style guide. To be useful, the organization needs to know that it exists. So, build a home for your system, because what will for sure bring out the most value of your style guide is how usable it is – in the end that is what will continuously empower your applications.