Starting a design system with existing products and a design system team of one
When I was assigned to create a design system for our company we had nine designers and five software products but no design system. A design system as we defined it at the time was a standard set of reusable components and designs that would prevent our designers from duplicating each other’s work and save us a lot of time and effort. We also understood that a design system wasn’t just for our designers but also for our engineers, with a design system they could save time and effort with shared code and reusable components.
The problem that got things moving
Our company owned a lot of smaller companies that each had their own branding. The company needed one of our software products to be copied and then rebranded to all the other smaller companies. The stakeholders just wanted to be able to copy the code and swap out the branding like I’ve illustrated below:
Initially one of our engineers went into the code and simply changed a color variable from purple to maroon. She assumed that the purple color for brand-1 could be swapped with the maroon color for brand-2, and in a company with a design system, yes, swapping brands is that easy. But she didn’t realize our software never had a design system implemented and what she had done had actually ruined the colors of the product. With her change the product didn’t fit any brand, was hard to look at and was even harder to use.
The reason she wasn’t able to swap brands by simply swapping colors was because our software had originally been built in a hurry by an outside agency that never implemented a design system when they wrote the code. As time went by our internal engineering teams were also never given time to revisit the code to add in a design system. So after years of adding more code on top of the problem our code base had gotten out of hand and a great deal of code had to be rewritten to simply swap brands.
Deciding where to begin
To create a successful design system meant our design and engineering teams needed to start creating and using shared components, shared code and shared designs. I needed a strategy, both immediate and long term to accomplish these goals since they were going to take a lot of work.
A design system strategy and a starting point
I understood all the areas that needed to be covered to create a successful design system and I knew it would take a number of years to accomplish them. I put together the following illustration to give us a strategy and a roadmap as we moved through the project.
You can see in the image above that there were things the UX team needed to do and things the engineering team needed to do. There is also a node in the middle, in green, where the design team and the engineering team needed to formally work together, even though they would be informally working together during the whole process.
Creating a shared component library
Our designers were inconsistent from each other when it came to their component designs, but they did understand the concept of a shared component library, and most of them had worked with component libraries before. Even though a design system is much more than a component library, I decided that a shared component library was still the best place for our team to start.
Looking at the best design systems
When I brought the team together to create our shared component library I didn’t want us to reinvent the wheel. I knew that other companies had already built design systems with shared component libraries, so I asked the designers what existing design systems they thought were best.
Our list of best design systems:
- Atlassian
- Salesforce Lightning
- Google Material
A quick note on Apple’s design system
We also looked at Apple’s Human Interface Guidelines as a design system to copy, but we felt that Apple’s guidelines weren’t tactical enough or detailed enough for what we needed. Plus, all our software products were browser based, so even though we loved Apple’s work, it didn’t make sense to try and copy them like the other design systems in our list who were all browser based. We did still refer to Apple’s Human Interface Guidelines along the way when we felt like there was something useful and applicable.
Component audit
Next I made a list of all the components in Atlassian, Salesforce and Google’s design systems. I created a spreadsheet for each of their design systems that listed all their individual components. Then I made a new spreadsheet where I combined and de-duped all those components into a final list. Their components turned out to be fairly similar even though the components in each of the design systems had different names and attributes.
Each designer ranked the components according to their needs
Next I created a survey in Optimal Workshop that had each of our designers rank the 126 components.
For each component they marked one of the following:
- Currently in my product’s UI
- Going to be in my product’s UI
- I have questions or concerns about this component
- I think we should spec this component even though it isn’t currently used in my product
- This component can probably wait or we don’t need it
Prioritized components
After everyone took the survey I exported the results and combined the answers the designers gave. In the end we came away with the following two columns of prioritized components. The rest of the components in the list we decided to set aside for the time being.
Component discussions and process
Once I had our list of prioritized components, it was time to bring all the designers together to discuss and debate the details. Each of the designers on our team had very different design backgrounds, experiences and opinions and getting them to agree and reach agreements was going to take time.
Discussion schedule and format
In each of our design system discussion meetings I handled facilitating and leading the discussions. My focus was on making sure everyone felt safe, had a turn to speak and that everyone’s opinions were heard. In between meetings I would synthesize and document everything discussed.
We had our meetings from 2:00 p.m. to 4:00 p.m. on Tuesdays and Thursdays because that was the best time we found to accommodate designers in different time zones and not disrupt their other product meetings. We also took a five minute break at the hour mark to give everyone a chance to stretch and eat.
What we discussed
There turned out to be an incredible amount of decisions that needed to be made about every component in our shared component library. Eventually I found a rhythm and a cadence to our discussions that lead to the following roadmap:
For each component we would do the following:
- Brain dump (Team)
- Read the three (Team)
- Find in our apps (Me + Team)
- Turn into more components as needed (Team)
- Finish taking notes (Me)
- Polish documentation (Me)
- Build in Figma (Me)
- Test Figma component (Me + Team)
- States
- Accessibility
- International concerns
Step 1 — Brain dump (Team)
The first thing I would do was have everyone in the group get everything out of their heads in what we called the brain dump. I needed to get everyone’s opinions out on the table at the start so that everyone could relax a bit knowing that what was most important to them had been shared and documented.
During the brain dump I would share my screen and open Confluence to take live notes. Taking live notes was great because it showed everyone that what they said was important, heard and documented. Sharing my screen also gave the group something to focus on while others were talking.
The brain dump also helped everyone get to know each other. The group’s ability to get along and communicate was crucial and going around the room round-robin during the brain dump gave us a chance to hear how everyone expressed ideas and communicated.
The brain dump also allowed me, as the facilitator, to learn what topics mattered most to the group and what didn’t. Knowing what mattered most allowed me to speed through things that weren’t as important to the group later on.
Step 2 — Read the three (Team)
After the brain dump it was time to open our source material and read what the best design systems said about the component we were talking about. It helped that we had just finished doing the brain dump because that gave us something to compare and contrast with what the other design systems said.
To read the three I would share my screen and open the design system to the component we were talking about. I would then read the documentation to the group. Reading the documentation aloud ensured that everyone read the source material and had the same knowledge to work from.
At one point we tried having the designers read the source material on their own, but they rarely did. Instead we found that reading the material together in the meeting worked better and kept things moving.
As we read Atlassian, Salesforce and Material, we quickly learned that those design systems rarely agreed or aligned. Conceptually they all had similar ideas, but the names and details were almost always different. We found this frustrating, and it was one of the reasons we read three design systems instead of just one. When it comes to design systems there still isn’t one single source of truth.
A note about educating the group
The brain dump and reading the three also had the intentional effect of educating everyone in the group about design systems and component libraries. These bi-weekly meetings weren’t just about having the group come up with a shared component library, they were also about teaching the group what they needed to know about components and design systems.
Step 3 — Find in our apps (Me + Team)
The next step in our process was to find every occurrence of the component in our software. Most of the designers had never audited their software up to this point, so this was a much needed exercise for everyone.
To do the audit we would log into each of our software products and take screenshots that we’d then paste into a large Figma document. The image below is a zoomed out view of all the screenshots we took for our menu component.
Auditing the components helped us know if the component was in our products or not. We often discovered that our products didn’t actually use the components we thought they did.
Auditing also helped the designers see all the incorrect ways components were being implemented in their products. We would constantly find the same component styled in different ways in the same product and across products. This was eye opening for the designers and one of the reasons we wanted to build a design system in the first place.
Step 4 — Turn into more components as needed (Team)
When we were discussing a component we’d often come to the realization that we needed to split the component into multiple components. The biggest example of this was with the text field component.
A text field component seemed pretty simple at first, it had a label, field, placeholder and helper text. But as we audited the text fields in our products we quickly realized that each type of information we asked for in a text field made the text field behave differently. We decided that we needed to separate out each type of text into its own component with its own specific rules and guidelines.
In the end we divided the text field into ten new components, as seen in the image below:
Step 5 — Finish taking notes (Me)
At this point in the process I had pages of notes from all our discussions. This step was when the discussions were winding down on a component and I needed to double check the notes for anything missing. I would re-read the notes on my own and look for any questions that didn’t get answered or areas I felt needed more clarity. In the next discussion meeting I’d then bring up these lingering questions for the group to answer, after which I’d put the additional information in the notes.
Step 6 — Polish documentation (Me)
When we were officially done discussing the component and I had finished taking all the notes, it was time for me to write our polished documentation in between our meetings. During this step I would create a new Confluence page for the component and go through all our notes, synthesizing and consolidating them into polished documentation. I would also create images and diagrams to put in the documentation where needed. When this step was done the component would have an official and finished documentation page we could refer to and share with others.
Steps 7 & 8 — Build and test in Figma (Me + Team)
Eventually we had enough finished documentation that it made sense to start building components in Figma. These components were what the designers would actually use in their designs to speed up their workflow and create consistency across everyone’s work.
The process of building and testing the components in Figma was its own stand alone project that I’ll write about in a separate article.
Steps 9, 10 & 11 — States, accessibility and international concerns
Every component in a design system has states, accessibility and international concerns.
- States refers to all the different states a component can be in, for example, a button can have a hover state, a mouse down state and a clicked state.
- Accessibility refers to how compliant each of our components was with the Web Content Accessibility Guidelines (WCAG) standards.
- International meant things like localizing our components to different languages as well as allowing users to enter international addresses and international currency.
Early on in our component discussions we talked at length about states, accessibility and international, but the team eventually realized that those items required much more time and attention then we could give them at that time. The group eventually decided that states, accessibility and international would go into a design system backlog to be worked on as our design system got further along.
A year later we changed the schedule and format
After a year of meeting every Tuesday and Thursday we started to see some ways to optimize and speed up our discussions.
The first thing we noticed was that there were always three or four people who participated more in the discussions than the others. The rest of the group was still engaged, and as the facilitator I worked hard to keep everyone involved, but not everyone could contribute all the time. There ended up being a core group of three to four people who drove most of the discussions, which often left the rest of the team to observe.
We decided to formally make a core group of individuals who contributed the most. We’d have that core group meet every week, then once a month we’d have the rest of the designers review the work of that core group. Having a core team do the bulk of the work sped things up and the rest of the designers still got to comment on everything we were doing.
35 components discussed and documented
As a team we are able to successfully discuss and document thirty-five components for our shared component library. The rules and guidelines for each of those components was hard won information that our designers all agreed on. Having these component details documented made it so the designers could speak with one voice and have consistency across the design of their different products.
Below are the thirty-five components we ended up documenting. You’ll see that this list has many new components that weren’t in our original list. We found that as the designers got deep into their discussions they would modify and create new components that better fit their needs.
A successful beginning, but a lot more to do
When I began the design system project I created the following strategy that outlined tasks for both the UX and engineering teams. Each step in the strategy was vital to successfully building and implementing a design system at our company.
After an intense two and a half years we were able to make significant progress on three parts of the strategy — agree on standards, document agreements and create Figma components. But even though we had accomplished a significant amount of work there was still a lot more to be done.
Read more about my coaching and mentoring experience in my case study Unlocking creativity: a deep dive into our two-day UX workshop on workshops
