Breaking the design system misnomers
The current rise in published design systems has earned products a strong reputation for being human-centered and establish a more personal connection. Companies like Apple, Uber, Slack, Netflix are perfect examples that we designers look up to when referencing design systems. By sharing the thought process behind details like typography, photography style, a tone of voice guide etc., they do a great job of telling the story about their product, giving it a unique personality.
It’s common knowledge that having some kind of a design system in place is a prerequisite and it serves many purposes including product managers, developers, designers, and even actual users. Having worked in the consulting and product industry, one of my biggest pet peeves are the misnomers used for design systems. I have come across different clients calling this document different names. Although the common saying goes, “What’s in a name?” when it comes to the purpose of these documents, I firmly believe that establishing a clear understanding of how these are different is important.
How are design systems different from design style guides ?
Style Guide — Say you’re starting on a new project, the first step is to establish a general understanding of the brand and business objectives, for which you begin curating mood boards. The output of this first step is typically a style guide. It comprises of atomic details like the logo, typography, color palettes, padding and grid guides, icons, input fields, etc. The style guide is typically a static document and doesn’t evolve drastically over time.
Component Guide/System — Once the atomic details are solid, you move on to the next level, i.e. building a component guide. In my past projects, I have found Brad Frost- Atomic Design approach instrumental in establishing different parts of a design system. After doing an audit of the content, you distill it into a list of design objects that will be reused throughout the project. The component guide is typically a live document that evolves and grows as we touch different parts of the product or introduce new features etc. In addition to styling, it includes additional details like a component’s behavior, it’s different states, content type, etc.
A design system can be thought of as a superset of a style guide and component system.
Design System — A design system can be thought of as a superset of a style guide and component system. Everyone has heard of Apple’s design system — Human Interface Guidelines and Google’s Material Design. These are comprehensive design systems that include design guidelines for everything — style, foundational components, photography usage, copywriting guides, etc.
It’s important that we all have a shared and accurate naming convention for these guides..
You must be wondering whether it’s important to call style guides or component systems differently. I’m pretty sure every company has its way of naming things, but in my opinion, it does make a difference when you refer to them specifically. Imagine you’re starting a new project and need to get your design system in place. During this time, if there is a clear understanding of how long it will take to build a style guide while parallelly working on a component system, it can help multitudes. For example, you can set expectations with your PO’s, PM’s while having developers working on a live style guide and also get going with the component audit.
In my experience, this approach has helped get a head start on projects and not worry so much about consistency. When a reference guide is already set, it’s easy to onboard new team members, direct developers and designers to one source of truth. And before you finish the project, you would have a design system ready.
Are design documents time consuming?
Definitely not! Remember “a stitch in time saves nine!” Very rarely would you design without a style guide, and because a component guide is a live document, you can always add new design objects. This will help you maintain a clear idea of your design inventory, prevent you from reinventing what you already have (I bet the developers will love you for this) and most importantly bring consistency to your product. Practicing this simple trick has undoubtedly helped me become a more informed designer.
Efficient way to create design system deliverables
Online design systems are the dream, but there can be constraints to building one, like resources, time, and money. Also, it’s pretty apparent that it will take you a while to aggregate the component and style guide together into a single place. In my past projects, we have taken different approaches to this:
- Online Style Guides — If you can get help from a front end engineer to build an online style guide, this can serve not just designers but also engineers a great deal in the future. Since the style guide doesn’t change much, having it online can serve a targeted audience of designers, engineers and stakeholders. You would also need a sketch file version, specifically for designers.
- Interactive Component Guide — An interactive component guide can be useful to demonstrate not just styling but also behavior. In one of my past projects, we built a component library in Axure that showcased details like elements, responsive behavior, content type, etc. This wireframe fidelity, an online interactive guide was a single source of truth and was referenced by diverse teams — marketing, designers, C-suite exec’s, 3rd party agencies, etc. for that project.
So based on your needs and resource constraints, it’s totally possible to build these guides separately and help them drive your process and design handoffs smoothly. If you have built similar guides or have suggestions please leave comments below. :)
