Getting started on design systems
If dark mode was a buzzword in 2019, design system will be a strong contender for 2020 title. It’s not a surprise, as digital products mature and gain ever expanding functions, designing those products need more sophisticated tools.
Getting there
As you work on your designs, the number of your design elements, icons and colors used will inevitably grow. You are at the tipping point, when it is just about to get out of hand. You want to reduce clutter and achieve consistency, so you start using components (aka symbols in Sketch) whenever you can. So do your colleagues. To stay on top of all the new designs you build libraries from those components, which eventually mature to shared libraries containing all the components your team created and use that as a common building base for creating new stuff.
This works fine for a while, but as your team advances and the design evolves, it will be difficult to keep your libraries up to date. When your team members work on different parts of the product, those meticulously crafted shared libraries can easily get out of sync, and it takes real effort to track design changes across the product. The shared libraries, once created with the idea of being a single source of truth, are getting fragmented as some element are getting outdated. It’s not clear anymore what elements are current, what’s an old leftover, and what’s just a concept which never made it into production. You realize that methods that worked on a smaller scale will need to be adjusted to scale well. You also realize that new tools alone will not substitute regular maintenance of your designs. It will take effort from all participants, otherwise you end up with a design debt which hinders quick iterations across teams.
Design system ≠ design system
Does this situation sound familiar? If yes, then you already know the solution: a design system. The more I researched the topic, the clearer it became that a design system ≠ a design system. It can range from a simple library with the basic elements gathered in a shared database, to a system fully integrated with developer and testing tools. So despite how easy the answer seems, you have a lot to consider.
Consider the tools
Nothing proves the trending demand for design systems more than the number of new design system managing tools emerging and disappearing. Google just deprecated its Material Theme Editor plugin for Sketch this year, in order to focus on building tools beyond Sketch and macOS. There is an effort to create new tools which work cross-platform, are also usable for developers and — instead of generating a new template to fill — can be integrated with existing source files. Now almost every UI design software offers some level of design system management from the veterans like Sketch to the newcomers like InVision, so there is a great chance that the software you are using already has it. Although they all use the same name, design system management works bit different on all tools and has different features. Currently our team is using InVision Cloud for developer handoff, so checking what their DSM offers was an obvious thing to do, and so far it seems like a good match for what we want to achieve. But what do we want to achieve in the first place exactly?
Preparation and research
To start building our design system, we need to start with designing our design system.
Cross-team discussion
We need to involve members from our development teams to discuss goals and priorities. A design system not only helps us build a more consistent product, but enables better communication between development and design.
By creating a common visual language codified through design tokens, and a set of components and patterns cataloged in a UI library, you’ll vastly improve designer/developer communication. – Jina Anne
Restructuring libraries
Housekeeping our shared libraries to get rid of duplicate components, superfluous colors, merging back missing new designs, create all possible states of elements is a good start to prepare it for using it as a base for the new system. As I mentioned, it is better to start out and integrate your already created sources into your design system than creating one from scratch. A structured, up-to date, clean source is essential.
Naming conventions
While preparing our source, we have to decide on a pattern for naming things. As our product has native apps for MacOS, Windows, Linux, Android, iOS and there is a web app as well, we have to come up with a naming system which fits all and allows easy structuring. Implementing design tokens in our system will allow us a faster handoff or even enable us to make style changes without handoff on our web client.
Gather knowledge, keep what makes sense
There is a ton of information about design systems out there, which at first may seem overwhelming. The more you get familiar with the topic, the easier you can decide what is worth trying to implement in your design system. The goal is not to implement all solutions you’ve ever heard of into your design system — it would be an overkill. Only add features that are beneficial for your team and you can maintain.
Expanding and evolving
In software design there is no “one and done”, your design system works well if it changes and evolves over time. It will need constant maintenance, but on the other hand, will save you a lot of effort to maintain the applications as the reusable components automatically inherit all changes and improvements.
Your design system is not the only thing that evolves, the tools you use to maintain it are evolving. Who knows, in a couple of years we might have a standardized system for managing design systems, and the entire design process of software interfaces will be integrated with development. The gap between the static images UI designers produce and the implemented result is huge, and the whole industry is working on closing this gap. Look forward to these changes and embrace them to build better products in the future.
Useful resources:
https://www.designsystems.com/
https://www.designbetter.co/design-systems-handbook
