"We are not designing pages, we are designing systems of components."
~ Stephen Hay
A style guide is a set of corporate standards. A guide on using the brand style which defines the corporate colors, fonts, forms and blocks, size of elements and layout. This is a detailed description of design patterns for each element separately and, when necessary, together with other components.
There are dozens of various style guides - starting from the ones for design and ending with the coding guidelines for different programming languages. They may have different names, but all of them have the same mission: to create general corporate rules. One of the first style guides were brand books.
A brand book is an official document of the company. It contains a detailed description of the brand's concept, its attributes, target audience, positioning and other guidelines used by marketing department and business executives for building communication with customers and company development in general. Besides, a brand book provides a complete corporate identity manual which governs the usage of all brand elements on various media, including advertising and corporate relations.
The larger the company, the more comprehensive brand book it has. While for small businesses it is often enough to have a logo and corporate colours.
In addition to a brand book there is a sales book (also referred to as a corporate sales book). This is a document that reflects all stages of interaction with customers, related standards used in the company, as well as the specifics of sales taking into account the characteristics of the product and company. Even though this document is aimed mainly at the sales division, it plays a significant role in the company - familiarization with corporate ethics. Consequently, it saves time of all employees, as it takes less time to get involved in the working process and allows to reduce the training period. Also, it provides an opportunity to preserve the experience within the company and to share it among different departments.
Style guides for developers
As was mentioned above, every programming language has its own style guide, a set of rules for writing and organizing the code:
- Rails style guide
- Ruby style guide
- HTML CSS style guide
- Google HTML CSS style guide
But these are style guides with very narrow specifics. What do they mean in the wide sense? What functions should they perform?
In my earlier article I talked about documenting CSS by reviewing how it can be done using KSS. However, does this method of defining style guides encompass the full range of application components?
In the general case, this is a set of rules that should be used by all developers: system architects, designers, front-end and back-end engineers. It is also very useful for managers and owners of the application when they need to discuss some updates or add new features.
Many companies store their style guides on their websites on a separate page. This way, they are always available online.
Depending on your web application, they may look completely different, here are some examples:
The advantages of style guides
1. Easy testing
When all the components are on the same page, it is easy to see when the behavior of one component affects the other one, if there any styles overlapping, whether the styles suit each other well and fit into the general model of the site. It is handy to test them on different platforms: mobile, tablet and desktop. To test the component, you do not have to go to the website (sometimes, in order to do this, it is necessary to log in as a user with special rights and go to a page accessible under certain conditions). Here, it is enough to look into the style guide because it is "live" and reflects the current state of the used components.
2. Streamlined workflow
A style guide encourages us to think not in terms of pages, but rather in terms of the project functionality split into small parts. Sticking to this process starts at the stage of application design, so everyone in the team follows it. This allows to easily incorporate new developers into the project due to the next point.
3. Common dictionary
It is not only a common dictionary of component's names, it also involves names of inner elements. It is straightforward and precise.
4. A convenient reference
For designers and managers it is a place that reflects the current stage of the project. Here you can see which elements already exist, which ones require revision and which do not exist at all. For instance, the statuses of errors or notifications, which are often forgotten.
Therefore, a web development style guide is an up-to-date documentation with a refined detalization of elements and modules along with handy visualization. It is a mean of communication between project architects, designers, developers and managers.
Development of an application with a style guide
The process of application development looks like this:
1. Defining the application features
Usually, the design starts from creating a color palette, typography and drawing the application page by page. This approach will cause many problems for developers in the future, because it does not provide the project scalability but just piles up more and more new pages. It is not a good option. Having a style guide implies that at the first stage, in addition to design solutions, basic elements should be distinguished. These elements may be used several times or expanded.
2. Splitting into components
Allocation of the components, adding new or extending the existing ones is impossible without close cooperation between a designer and a programmer. At this stage, the style guide is being updated because it should always reflect the current stage of the project development.
3. Implementation and documentation
This stage involves the implementation of components taking into account their appearance and behavior. A new component should conform with the existing ones and possess quality inherent to all components: to have enough flexibility and integrity, so that it can be used under various conditions and in different scenarios. It is also a good time for creating unit-tests and documentation.
4. Assembling the application
Everything is clear at this point. We already have a set of finished components, which can be used to build a single application. We can easily check how various scenarios work and write integration tests.
Initially, this article was supposed to be only about style guides for web design and development. However, digging deeper into them you realize that this approach (breaking into components) works very well not only for styles. Components are small blocks that constitute everything around:
- In functional programming these are pure functions. In OOP it is just correctly written functions, small ones that implement some pieces of logic but without side effect, not influencing the operation of other functions and methods.
- HTML: dividing into pre-used blocks (partials).
- CSS: a methodology of web development - BEM (Block Element-Modifier) or its enhanced counterpart - CSS Bliss. Both approaches perfectly fit into the structure of components. In Bliss, a separate file is created for each component. This file contains the description of styles for this component and for nested elements and modifiers.
- In design, components are the elements that constitute the prospective layout. For example, as a specific instance we can take Bootstrap: a set of predefined components, such as headings, buttons, text, columns, menus, etc. In a more general case, it is constructing large applications of smaller components, which in their turn, consist of even smaller parts. This is the basic idea of Atomic design, which may be described by the epigraph to this article - a saying of the famous designer Stephen Hay ("We are not designing pages, we are designing systems of components.") - and illustrated by the following outline of design creation: