What is a style guide? Simply put, it’s a document that tells you how to tell a story. It establishes standards such as how to write copy, how to format, how to create visual elements and interactive methods, etc. Style guides originated in the print world, such as newspapers (see The Guardian's style guide); they are also of great value on the web. Whether it is traditional printing or the Internet, the most important thing is "content". The ultimate goal of a style guide is to present your content in a clear and consistent visual style. The BBC's Global Experience Language (GEL) is a great example of a website style guide. You may want to download a PDF document from "Download GEL Web Styleguide" on the right side of the page to get a brief understanding first. ![]() You may think, as a designer, aren’t these things we should know instinctively? Why should we include them in documents? In actual work, it is impossible for designers to take care of everything. For example, there may be many people and teams involved in business research, content strategy, user experience, technical development, QA, deployment and other aspects. You need to deliver the documents to the corresponding cooperation departments at the appropriate stage so that they can understand the characteristics of the website product more accurately when necessary. Usually, after the website interface design work is completed, the interaction designer and visual designer will start working on the style guide. See if this scenario is familiar to you: You have created a perfect visual prototype in Photoshop or Fireworks. Every pixel is perfect, the line spacing is well controlled, and the color scheme is reasonable and meaningful. Great, now it’s time to hand over the design to the front-end developer; how do you plan to communicate every detail of the design to the developer? Think back to the important design decisions you made during the design process, the 60% opacity of the background, the one-pixel light gray border of the container, the pixel-accurate padding and margin settings... How should you communicate all of these with the developer so that they understand these important details? ![]() A style guide does not need to explain every pixel in every design element. What we need to do is to summarize a series of general design principles so that relevant people in the project can understand and appreciate them. This relatively abstract approach can also reflect your design ideas and intentions. "Consistency" is a universal quality that all elements in the interface should have. As part of the design system, they should all reflect a consistent design concept. It’s also important to keep the visual style and experience consistent when people use different types of devices to access your site. As Nathan Borror said in an article about interface harmony in 2009: "Good interface consistency is not noticed by users." In other words, the wonderful experience brought by good interface harmony will make users feel happy without realizing it. I usually use the "Interface Harmony Canvas" introduced in this article in my style guide, presenting all the typical design elements involved in the project on a canvas at the same time, including their different states and corresponding code snippets. ![]() Don’t wait until late in a project to start working on a style guide; you can add mature interface style standards to the document bit by bit as the design process progresses. It is a good habit to think carefully about the consistency and standardization of interface elements while creating them. ![]() Focus on communication As designers, we often get caught up in the details of design; remember to remind yourself that the essence of design is to convey information, that is, communication; the overall "design solution" is also a response to a certain macro problem. We also need to create a style guide at a high level for the purpose of communication, explaining the design decisions and the thinking behind them. In short, we should create a style guide with those “big” elements as the starting point, and then gradually refine them as we go along. It can be said that if you can keep thinking about the global elements before the design process enters the detail stage, the subsequent design work will become very calm and coordinated. In fact, this process sounds a bit like the principle of CSS (cascading style sheets). The so-called cascading style sheets are all about cascading from macro structures to micro details. So you could call the style guide a “cascading style guide” if you will. ![]() Now that we have covered a lot of ground, let’s take a look at the basic steps and process for creating a style guide. 1.Overview A brief statement of the project, including an introduction to the project goals and solutions. In this part, you have the opportunity to communicate with other members on some major direction issues to let them understand the focus and focus of the entire project. At the same time, you can also briefly describe the style, tone, and content strategy that the website needs to have. 2. The grid system used in layout page design, basic layout conditions, positioning rules of page modules, etc. You need to describe the positioning of some global page elements, as well as related white space rules, etc. Wireframe prototypes of some typical pages should also appear in this section as illustrations. 3. Brand identity includes color schemes, global brand images, rules and restrictions for the use of brand images, etc. 4. Typography: Introduce the typography scheme used on the website, including font styles, reasons for choosing these fonts, etc. Here we will also use some representative specific diagrams to introduce the relationship between font style and page context. 5. Navigation: Global main navigation, secondary navigation, drop-down menu, text links of category entries, search...any elements that can help users navigate the site can be included in this part. From here, we'll gradually get into the details. The definitions of attributes such as link color and background color of navigation elements in different states should also be described in detail here so that developers can understand them at a glance. 6. HTML elements HTML tag usage rules for some typical elements, including title elements (h1, h2, h3...), ordered lists, unordered lists, buttons, forms, fieldsets, tables, etc. This list of rules does not need to be exhaustive, but it should be as comprehensive and representative as possible; if necessary, you can work with front-end developers to complete this part. 7. Rules regarding usage scenarios, size limits, display ratios, cache settings, etc. for media files, including images, audio or video files. 8. The objects involved in this part of other resources are basically at the detail level. Those design elements that cannot be classified into the above seven categories and have a high degree of customization can be placed here. For example, how the presentation of different modules should change in certain specific situations, the advertising rules of the sidebar, how to handle search errors, the presentation rules of the comment list, how to browse the photo collection, etc. Usually, in this part, we can explore and summarize some design patterns with high reusability. 9. Interface Coordination Canvas combines all of the above into one large canvas. The so-called canvas can be in the form of a picture, but it is best to be in the form of an HTML page, because this can more flexibly carry copywriting and HTML or CSS code content, allowing front-end developers to directly use corresponding code snippets according to the design rules of page elements. In addition, placing all content related to the visual style on the same canvas also allows designers to easily check the overall coordination of page elements. 10. The topic of UX documentation is indeed not small, which needs to include the deliverables produced by the project so far, such as site maps, wireframe prototypes, high-fidelity prototypes, user research documents, etc. These early product deliverables can play an important role in defining the functionality, visuals, and interaction methods in the subsequent design and development process. Using a Style Guide Creating a style guide is only the first step; putting it into practice is the most important step. Attach the guide to the project management tool, or email it to the relevant people in the project team; if you are not sure who is really "relevant", then let the project leader or product manager do this. In short, what we want to achieve with a style guide is team collaboration, so that everyone can work together to complete the project. After delivering the style guide to team members, remember to often talk about the importance of this guide at important stages of the project so that it gradually becomes part of the workflow and even product culture. I have to admit that sometimes I do find style guides a bit boring, but that’s okay, at least we can’t use that as an excuse not to create one. Believe me, a style guide plays a crucial role in the design process and the success of the entire project. |
<<: Linux Operation and Maintenance Basic System Disk Management Tutorial
>>: Implementation code for using CSS text-emphasis to emphasize text
Table of contents Array destructuring assignment ...
Docker is a management tool that uses processes a...
# contains a location information. The default anc...
JSONObject is just a data structure, which can be...
Let's take a look at the detailed method of b...
Table of contents 1. What is a prototype? 2. Prot...
environment: 1. Windows Server 2016 Datacenter 64...
Button is used quite a lot. Here I have sorted ou...
0. Preliminary preparation Disable secure boot in...
Table of contents Function Basic query functions ...
Find the problem Today at work, when copying tabl...
Table of contents Preface Is the interviewer aski...
Memo: Just experience it. Record: NO.209 This exa...
This article uses an example to describe the mana...
This article uses examples to describe the common...