I believe that the way we create on the web has fundamentally changed. We’ve scaled our systems so that they have now become vast branded experiences. Digital production is no longer just one person from each discipline. With greater scale, we must also scale our collaboration techniques. Don’t wait on the final designs. Build up your component library step by step. Setup your documentation store in code first. If you wait until the Figma is done, you’ve already doomed yourself to failure.
What is a Design System?
The most common misconception is that a design system and component library are interchangeable. A Design System is not just a UI component library; it is not just a style guide. It should include a complete overview of the principles and approach to describe a visual language for any product or brand. It will include documentation on tone, branding, layout, animation and yes also UI components.
We can think about the design process in these stages:
Research – Analysis – Prototype – Test – Iterate – Visual
In a traditional model, Developers would be involved only at the Visual stage. In more progressive teams, Developers would become involved at the Prototype phase. For a Design Systems workflow to be effective, it means developer involvement in all phases of the lifecycle
One of the foundational text of Design System methodology is Brad Frost’s Atomic Design. I also highly recommend Designer-Developer Workflow that Brad (Twitter) co-created with Dan Mall (Twitter); they have an excellent screencast.
Example of Great Design systems:
Which problems can Design Systems solve?
The great promise of the first wave of component libraries was to allow for a consistent visual style throughout a digital product. However, in practice, I don’t believe it delivered. If not applied in a wider design context, Component libraries can lead to expensive redesign projects and wasted effort in a quixotic struggle for one codebase that could be reused everywhere. A common pitfall of that approach is to make the mistake of tightly coupling behaviour with appearance.
What should be striving for is to achieve is a way to communicate a shared methodology. A roadmap for how we create the digital experience. To do this, we need an easy way to publish style guides. We need a common way to share visual indicators throughout our teams to be understood and replicated in contexts that we cannot yet imagine. Finally, we need to create a code-first approach to design iteration.
What we need is a largescale way to create new experiences at speed.
All creative processes are best when they work within the constraints of the medium that they are intended for. Therefore, I urge you to read Frank Chimero’s seminal 2015 article – The Web’s Grain (if you haven’t already).
One of the major problems that we have is that the design tools we use are divorced from the constraints of the web. I’m sure that you’ve experienced reviewing a design comp and finding it out of sync with the platform’s existing components. That design review & revision process is expensive, and we shouldn’t need to be the only team member that keeps that in our heads. It should not just be the Frontend Dev’s job to police the consistency of the product.
Designing in the browser doesn’t scale. It’s fine on small teams. But, as much as we try, it’s hard to encourage Designers to code. Component libraries alone don’t scale; their components become overextended until such time that they crack under the weight of the first abstraction.
What do we need from a Design System to make it work in an Agile Context?
I think at its heart Agile software development is about fast, small interations. We need to create an alternative source of truth for our platforms that are made up of the symbols that form the essence of a brand’s identity. We need a place to maintain style guides, brand guidelines, tone of voice documents that is easy for any member of our teams to maintain. We need to lead the change in our process so that new styles are rare, and integrating them into our design systems is part of our definition of done.
Sharing behaviour is not the same as sharing appearance or tone. The frontend framework you use does not affect the tone of voice the content is written in, and it shouldn’t affect the visual appearance of your component. We should be able to work on new behaviours and new appearances in parallel. We need to ensure that design systems allow us to solve our user’s core problem, and at the same time, allow our colleagues to increase visual fidelity in small iterations.
If you want to learn more:
Other great Design Systems to draw inspiration from:
There is a directory website Adele by UXpin that is an excellent resource listing publically available design systems.
Comments
Add your comment