The Problem
Go from zero to design system in 3 months
like many companies, my client had an existing design system, but it was outdated and hardly used by engineering. I had recently joined a very talented team of 9 designers and one front end engineer at Disney Studios and due to my previous experience at Ticketmaster spearheading a design system creation effort, I was asked to lead the effort.
The Solution
Schedule regular Meetings
OK. It's not as simple as just that, but I point this out because it will take a concerted effort on everyone's part to get a design system up and running while everyone is working on their actual projects. Thus, setting up a recurring set of meetings with a fairly strict number of meetings in total will help shape the expectation that each meeting is critical to making progress and that everyone's participation is vital.
During this project I used Mondays but many other tools (Trello, Notion or AirTables) will also do the trick. You just need something to help the team "see" how many elements require everyone's input.
Here is how I like to divide up this work ↓
Foundation
Building Blocks First
The first steps are to agree on the following foundational elements:
- Typography
- Colors
- Grid
- Spacing
- Motion
- Elevation
- Icons
As you might imagine, some areas will take longer than others. I find that grid, spacing, motion, icons, and elevation are far less time-consuming than colors and typography, so set more time aside for these elements. I would set an expectation that if your team meets twice a week that you should be able to complete designing foundational elements in about 5 weeks.
I am skimming across the top of this process as each foundational element contains a myriad of detailed considerations. For example, if you get your team makes use of industry-standard icon sets like Feather, Shape, or Material Design then you can save a lot of time. I would recommend limiting your typography scale to no more than 10 options with only one including all caps.
Other Important Considerations
Here are other parts of the puzzle to settle on early in the process.
- Dark / Light Theme
- Naming Conventions
- Design Asset Distribution
- Theme Compatibility
All of these topics are already covered in much more detail on Medium and other places that I won't get into too much detail here. For me, even if it doesn't seem obvious when you start, make your design system able to seamlessly handle light and dark themes. You will thank me later. Name your elements in the most abstract, yet most understandable way possible. For example, colors should be named based based on function (e.g. White - High Emphais, White - Medium Emphasis, etc.) rather than hex code or fanciful names. Decide on how you want to distribute design system assets including version control, updates and user management. Right now, tools like Sketch Library, Framer X and Figma all offer interesting options for design system asset management. Lastly, it is imperative that everyone on the team buys into the concept that you are really creating one specific theme for your company and your design system should be easy to convert to another company's theme.
Base Components
Block and Tackle
After about 5 weeks, I was in a good position to turn the team's attention to components and switched our meet cadence from twice a week to once a week. Here is a list of components I would recommend tackling first:
- Buttons
- Text Fields
- Selects / Dropdowns
- Checkboxes / Radios / Switches
- Search
More Complex Components
The Other 20%
Once you have your base components, you have a toolkit for about 80% of what your design team needs on a day-to-day basis for most application scenarios. Now you can concentrate on filling out the library with more complex organisms that use several components and foundational elements. Here is a short list:
- Menu
- Lists
- Slats
- Dialogs
- Badges / Filters / Tags / Tooltips
- App Bars
- Drawers / Trays
- Cards
- Progress
- Data Tables
Socialization
Build Momentum
There is really no point to a design system that lives within the design team and is not embraced by engineers, product and other stakeholders. In my case, I involved my respective product and engineering teams in the process and helped them understand which parts of my designs included elements from the design system. I am glossing over a lot of detail here about how this actually gets done but I will highlight that this is selling. I sell my ideas effectively by looking for win / win scenarios. In short, product and engineering want to move faster and the sex appeal of design systems is less about consistency and more about moving faster.
The Results
USed right Away
I was very pleased to see the new design system demonstrate value immediately as one of the projects I was working on required a very fast turn around. In this example, engineering was able to take a design I delivered the day before and show it working the very next day!
