Ruiwen Tay writes about her practical experience of building a design system in 8 steps. Starting a design system in a start-up can be quite challenging and Ruiwen has articulated well in her article to provide some good insights with references for further readings.
Highlights of the article: She and her team clearly defines design system - a repository of reusable components with clear usage guidelines, shared among designers and developers.
Ruiwen describes her journey through 8 steps as follows:
1. Audit existing components 2. Research on other design systems 3. List out components 4. Plan a timeline 5. Research and discuss components 6. Create design symbols 7. “Design” design system 8. Implement design system
She rightfully comments that "Building a design system is a never-ending challenge as they continue to update and adapt it in order to better suit their organisational needs.
Interested? Read the full article below.
Design systems are all the rage now and you’ve probably seen this term being thrown around ever so frequently. I was first introduced to the world of *design systems* when we started on our web design system back in January 2019. Working in 99.co with only one other product designer, we had limited resources to dedicate to starting a new project. Still, we deemed a design system important to eliminate existing design inconsistencies and improve future workflows for both designers and developers as the company scales up. That being said, there was a lot we had to work around and get our hands dirty in order to push it forward. Just so you know what you’re getting yourself into, I’ll define what we mean by a design system — a repository of reusable components with clear usage guidelines, shared among designers and developers. It should showcase all existing components with guidelines as to when and how to use each component including ready-to-use code.
Our design system is still a work-in-progress but by documenting this journey, I hope to share our process as well as some useful tips and tools. :-)
Steps
Audit existing components
Research on other design systems
List out components
Plan a timeline
Research and discuss components
Create design symbols
“Design” design system
Implement design system
Step 1: Audit existing components
In order to get a bird’s eye view of all the use cases we need to cater to, it is important to audit existing components in our product. Yes, every single component on every page. This is a crucial step albeit a tedious one. For this, we took screenshots and used Trello to organise them.
Each list (top to bottom) represents a page on our website, e.g. Home page. Within each list, different sections of a page are captured as screenshots and organised into cards. Each card is tagged with labels (panel on the right) that represent each component present within the section of the page. The labels are colour coded based on the type of component, e.g. checkboxes, radio buttons etc are forms of data input, hence they are colour-coded green.
By organising in this manner, we can easily search for specific pages or filter by components using the right panel and see all its current use cases across all pages. It also helps in identifying where there are design inconsistencies.
Step 2: Research on other design systems
Here are some of the design systems we used as a guide to shape what we wanted in our design system:
Atlassian
Ant Design
IBM
Zendesk
Workday
HubSpot
Salesforce
Shopify
Bootstrap
QuickBooks
We wanted to take the best practices out of these great design systems and see how they organised and displayed their content. I’ll go through a couple of my personal favourites — Atlassian and Ant Design.
Atlassian categorises their design system into Brand, Marketing and Product. As different aspects of design require different guidelines, catering to the requirements of each design aspect ensures that the design language across the entire company is kept consistent. For instance, Marketing may need more colours when designing beautiful collaterals, as compared to Product where we generally only need a fixed set of colours to showcase different component states. Atlassian also provides extremely clear guidelines for each component, from its different styles and variations to its use cases and best practices.
Ant Design categorises their components into different sections such as Data Display, Data Input, Navigation etc. This really helps in organising and finding components. They display anchors on the top right corner so users know what to expect on each page without having to scroll all the way to the bottom. Every component style and variation is showcased upfront and each component is interactive. Code is displayed and there are quick actions for developers to copy code or open in various environments. KUDOS to a great user experience!
Step 3: List out components
After researching on other design systems, I circled back to list down patterns and components we would need based on our research and filter labels we had on Trello. This gives an overview of what needed to be reviewed so we can keep track and plan time accordingly.
I organised components into the following sections based on their functions —Buttons, Data Input, Data Display, Feedback and Navigation. The list gets revised continuously and ticked off whenever we finish discussing a component.
Step 4: Plan a timeline
Next, we made a weekly timeline based on what needed to be done and by who. This helps to keep stakeholders and everyone involved in the design system updated on progress, as well as facilitate resource allocation. We planned out which components to discuss, starting with those that are most commonly used from the use cases on Trello. Patterns such as Typography, Colours and Layout were important to discuss first as they laid the foundations on which subsequent components would be based on.
With limited time aside from our day to day responsibilities, we strove to have two to three design system discussions weekly, each session about two hours long. Of course, this is an ideal situation. There were often times both product designers were swamped with work and unable to take time out. On extremely rare occasions, we were able to dedicate more time to discussions and would try to make up for lost time.
On top of weekly discussions, we also planned for the following steps — creating components as symbols on Sketch, designing pages for the design system, and for our frontend engineer to build these pages. We would update the timeline continuously week on week based on our progress.
Step 5: Research and discuss components
The end goal of the discussions was to design each component with its properties and states, as well as establish its usage guidelines. For each component discussion, we reviewed its use cases on Trello and researched on best practices. These include reading articles and looking at how other companies are using that component etc.
Initially, we did our component research during the discussion session. But what we realised subsequently was that research did not require both designers to be present and it would be a better use of time to do research beforehand each in our own time in order to reserve the full session for discussion alone.
We penned down our discussions on Google Docs in order to keep track of decisions as well as how we reached these decisions. This was really helpful at times when we had to revisit components that were discussed previously. Having these notes reminded us of past thought processes and decision making in order to better facilitate subsequent ones.
Step 6: Create design symbols
As the discussions progressed, we started building our styleguide. I created text and layer style libraries, and symbolised each component on Sketch while catering to its states and variations.
Again, we combed through articles and looked at other UI design kits to compare naming conventions as well as how they created nested symbols etc. What I realised was that there really is no best way of organisation for everyone, just one that best fits our current workflow. Chances are that as tools get updated along the way, we will need to adjust our workflows accordingly to optimise the usage of these tools.
An example will be the recent Sketch 60 update with the new Components Panel and Popover. The previous naming convention for our Style libraries had multiple layers segmented by size, weight, colour, alignment and line height. With the new Search (or more like Filter) function in the Popover, we had to scroll and click through multiple folders just to find a particular style.
To cater to this new update, I flattened the naming structure such that we can now search either via [Size][Weight] to see all font colours with or without the default line height, or by [Colour] to see all fonts in this colour sorted by size and weight. Naming for our neutrals palette was also shortened from Dark, Mid and Light Neutrals to D, M and L Neutrals respectively, due to limited horizontal space within the popover especially when font sizes are large. Moving forward, I will expect more changes to come but overall our efficiency has definitely improved with these updates.
Some useful articles:
…and Sketch plugins:
Find and Replace: Change text within layers and symbol overrides
Shared Style Finder: Find instances of a shared layer or text style
Sketch Runner: Perform quick Sketch actions quicker with your keyboard
Symbol Organizer: Organise symbols alphabetically and into groups as determined by symbol names
Step 7: “Design” design system
As mentioned above, we wanted to incorporate best practices from other design systems into our design system. I designed mockups for each page after its components are symbolised, before passing it on to our frontend engineer to build these pages.
We soon realised that this was not an ideal workflow. As much as we could customise the pages as we deemed fit, it was taking up resources that were already limited just to build these pages. Hence, we sought out tools that would help reduce the workload so resources could be better allocated to what is necessary, i.e. building components and implementing them across the product.
It was crucial to find a tool that we can integrate into our existing workflow while features such as version control, branding customisation were also good to have. We found a table created by uxtools.co comparing across different design system tools and their capabilities. I tried out different design system tools such as brand.ai (now Invision DSM), Lingo and Zeroheight so we can make a decision on one that best suits our needs. While each tool had its merits, we settled on using Zeroheight.
I created pages and sections within each page for different components and their variations. Usage guidelines are stated clearly for each use case and Sketch symbols from the styleguide are imported directly into Zeroheight via a plugin. Live component examples can be displayed to viewers using interactive HTML snippets and Storybook components. Developers can easily stay in sync with designs with their design token API as well.
Step 8: Implement design system
Communication with engineers, product managers and other stakeholders is important throughout the entire process, and especially this step. In order to implement the design system, we would need to build the new components, link them to Zeroheight and replace the existing old components in our product as well as design files.
I checked with our data analyst for a breakdown of the most frequently visited pages. With these pages ranked by highest traffic, we decided on components to update across these pages in different phases. The initial plan was to take a couple of sprint points in each 2-week sprint for designers and engineers to work on the implementation.
However as a start up, priority has to be given to doing feature work and we were unable to stick to the schedule as planned. Instead of taking time out to work on specific pages, we came to a compromise such that pages involved in the feature work we are working on will be designed and built with the new components.
An additional tool we used to improve collaboration between designers and engineers in implementing the design system is Zeplin, with its Global Styleguides and Connected Components. We uploaded all new component symbols directly into our Styleguide as shown above, and developers were able to link their codebase and documentation sources (such as Storybook or Github) to these components. Once this was done, whenever a developer inspects a design on Zeplin, they would be able to see an overview on the component linked to our Styleguide and reuse the components.
All in all, this is how we started our design system from scratch. There is still much work to be done, but slow progress is better than no progress at all. Building a design system is a never-ending challenge as we continue to update and adapt it in order to better suit our organisational needs. It might seem daunting at first but taking a small step at a time will make it a lot more achievable. Baby steps!
Thank you for reading. If you‘ll like to chat more, feel free to reach out or leave a comment below!
Reference:
This article was published at uxdesign.cc: