I initiated this project of refreshing our design system based on the outcomes of an ongoing engineering project to update our UIs. Outside of spearheading the initiative, I worked with one other designer and our design manager in the following roles to create a highly flexible Figma component library:
We needed to created a design system for Acquia that was flexible and adaptable to the company’s various marketing and web development products.
Our existing design system was centered around Dashkit and did not scale well to meet the needs of our product suite.
There were many inconsistencies within it in terms of spacing, pattern usage and visual language - and in many cases there were too many components with similar use cases that were being applied inconsistently across products.
The existing Dashkit based design system was being implemented in our products and I was responsible for coordinating with the engineering team to answer any open questions about the components.
During this process I realized how much work was required to get this design system to a usable place and proposed that instead of us redefining components as these questions came in from engineering, we should instead refocus our efforts on updating the system as a whole and then delivering it to the teams to implement.
I proposed a 12 stage plan to tackle each phase of putting together a design system. The first step required us to audit our existing products. This helped us isolate all the existing components we were using, where we were able to update existing components from Dashkit and where we needed to design something net new. It also allowed us to see inconsistencies across how components were being used across all the products and create more harmonious patterns among them.
We then began to work on complex pages to get a stronger understanding of where our components worked well together and where they didn’t. For example on the page below when we used our existing design system we found the command well was not ordered intuitively, and we found we did not have buttons that could operate as filters or toggle states and needed to create a pattern for it.
.png)
We created a list of every component and their levels of ‘done’, and then began to track these in Asana so that we were able to keep track of which designer was working on which.
We have two Figma files for this project, one for explorations and one for final component deliverables that designers and engineers could actively use. Each component went through the stages of research, exploration, refinement and dev ready, This was reflected in both the Asana board and our Figma exploration file.
When we completed a component, it was moved into our final design system file and turned into a Figma master component and heavily annotated. Every time a component was completed on our end and moved into dev ready in Asana, a message was triggered in Slack to alert the engineering team that a component was ready. Each Asana ticket was set up to have the link to the page in the exploratory file and the frame in the final design system file.
We found that staggering our design workflows with the engineering sprints was the most effective in ensuring they were able to stay on track with their deliverables for the quarter.
We kept the communication collaborative and transparent throughout the process with engineering so that we could keep delivering components at an efficient pace. The first phase of updating our design system was to ensure all our products had the same look and feel, and it was important to ensure everyone from both teams understood this. This transparency helped us continue to iterate as we began our work on understanding product identity, as all teams were aware that these might change moving forward.
We had weekly check-ins with the engineering team to answer any open questions and to show our work in progress to ensure we were accounting for technical feasibility. Twice a week, myself and the other designer working on the design system would attend engineering standups to help with potential inconsistencies between implementation and designs.
Our study was intended to understand the following:
Scannability - does the change in contrast increase the user’s ability to glean more information at a glance?
Wayfinding - how quickly can the user navigate the page?
Recall - can the user remember key elements on the page after navigating away?
I recruited 12 internal users to participate in the study and the participants familiarity ranged from Cloud Platform products to marketing products. Each participant was shown a different set of design concepts, including our current visual refresh designs. They each went through 4 timed tasks:
- The first three were to find a specific component on the page while we measured how long it took in each instance.
- The fourth task involved them looking at a page for 30 seconds, after which it was hidden and they were asked three follow - up questions to see which information they retained from it.
Each participant then went through a product identity exercise to help us understand how these design concepts are perceived. They were given a set of adjectives and asked to place them on the screens that were most suited to them.
Overall we found that the screens with the dark blue top navigation performed better than the rest, showing faster wayfinding times in two out of three categories. In reviewing all three concepts with the participants, the idea of a clear information hierarchy came through a lot with the blue top navigation, showing that it was easier to separate the working area from the navigation area because of the stark color contrast.
We need to incorporate the results of the above testing and update our navigation items across the products. We’ve also begun to map out what shapes a product identity and how it ties into elements such as branding, voice, personality, etc., and understand which of the adjectives from our study might be more relevant to which of our personas. Our next step is to finalize what voice we are working towards and identify which of our components could be affected by this.
We are also currently working on improving the documentation for each component, particularly around accessibility. We want to make it as easy as possible for designers to quickly choose which component would work best for their purposes and how to ensure the designs meet accessibility standards. For e.g., clearly displaying which colors would work best in combination as shown in the below chart:
