The Opportunity
When I first joined the WanDisco team, it was immediately clear that the company was experiencing unprecedented growth. However, as the design team grew, so too did the number of inconsistencies across our files and product experiences. Without clear design guidelines, the number of differing opinions and views across our teams led to a mounting design debt, caused by a lack of direction and guidance.
To tackle this issue in the past, we had an existing design system named DLS (Design Language System). However, this system wasn’t exactly helping matters, as many of its components were incomplete and it lacked any form of documentation; arguably it was adding to our design debt, instead of subtracting from it. Realising this could negatively impact our feature roadmap and lead to a fragmented user experience, I proposed a redesign of the WANdisco design system.
My Role
Component Creation
Component Documentation
Design System Management
Accessibility reviews
Product QA
My Approach
Starting with a retrospective
As previous attempts to create a Design System at WANdisco had failed, I started by running a retrospective that aimed to identify and understand where previous efforts had fallen short. To accomplish this, I ran a session with engineers and designers, to gather their opinions on how the existing DLS failed to live up to expectations and how it could be improved.
Through this retrospective, 4 critical challenges were identified:
Documentation lacked depth — Documentation for components and patterns often didn’t cover all component behaviour, particularly edge cases. This often resulted in lost productive time caused by uncertainty and differing opinions between members of product teams.
Incomplete Component Library — Many patterns and components used across our product experiences were not included within the design system and those that were included were often incomplete.
Accessibility & Usability Concerns — A number of components within the existing DLS failed basic accessibility checks, such as insufficient colour contrast or lacking a focus state. Moreover, there was no accessibility documentation for any components.
No governance process — A product team’s primary concern is releasing new features, not upholding the integrity of the design system. As a result, teams will often get creative and find 'inventive' ways to achieve their goals, resulting in discrepancies that slowly creep in and destroy your design system
Project Kickoff
Conducting a UI Inventory Audit
To kick off the project and better understand the current state of our existing design system and product experiences, I started by conducting a UI inventory audit. This process involved reviewing our product experiences and listing every unique component, pattern, and token instance I could find, and whether or not they were already documented within the existing DLS. The result is a spreadsheet that helps visualise the scale of inconsistency across our platforms and identifies opportunities where we can add, merge, extend or remove components.
These findings were presented to stakeholders in hopes of encouraging teams to buy into the idea of revamping the design system. This was incredibly important as many involved were somewhat sceptical of this project considering the failures of past design system iterations.
Drawing inspiration from industry-leaders
Design systems are an inevitable result of companies building large-scale and complex projects - many industry-leading companies have published their design systems for all to see. During this project, I reviewed many publicly available design systems as a point of reference and inspiration for how WANdisco could structure its own design system. Some examples of design systems that were reviewed included Shopify's Polaris System, IBM's Carbon System, Saleforce's Lightning System and NordHealth's Nord System.
Laying our foundations
Drawing from what we learned during our interface audit, I began to create and document the tokens that will act as the foundation for all components to come - You can think of tokens as the properties that define the look and feel of components. Using the inventory audit as a reference, we were able to significantly cut back on the number of unnecessary tokens that were leading to inconsistencies across components.
Under our token documentation, you can expect to find everything you would use to theme an interface, such as; Colour, Typography, Iconography, Spacing, Units, Elevation, etc.
Once I had our foundational tokens in place, It was time to start thinking about components. To get things rolling, I started by identifying 3 pilot components that would serve as a testing ground for how we design and document components across the entire design system.
Designing Components
I designed our pilot components using Figma, all components were built to be responsive using the auto-layout feature, allowing for components to be used across a range of different device sizes. Furthermore, using the variants feature, each new component could easily support a range of custom properties such as unique values, interaction states, validation states and more.
Documenting Components
Once designed, a component could be documented. During the pilot process, this involved collaborating with engineers and designers to create a documentation template that contained all the information required by those involved in the creation process. This template went through several revisions until everyone was satisfied with the result. Once complete, we had 3 fully documented components and an approach that could be applied to all future components.
Initially, our components were documented within Figma, however during the pilot process, we made the decision to move to ZeroHeight. The reasoning behind this decision was to better assist developers, as our developers have expressed a dislike for reading documentation within Figma and ZeroHeight would allow us to directly embed Storybook components into our documentation.
The contents of the documentation page vary depending on the specific component. However, at a high-level, most of our documentation pages include:
Overview and Usage Guidelines
Component Construction
Interaction/Behaviours
Accessibility Guidelines
Token Usage
States, Validation and Status
Following the success of our pilot components, I set to work applying our newly found design & documentation process to new component opportunities. Throughout this process, I always referred back to the UI inventory audit to identify opportunities where components could be added, merged, extended or removed. The result was a library of over 25 components with more to come in the future!
Addressing Accessibility Concerns
To tackle the accessibility and usability issues of the previous design system, all newly designed components were created in accordance with WCAG Guidelines to at least a AA standard. Moreover, the documentation created for each new component includes the requirements needed to ensure accessibility for users relying on assistive technologies such as screen readers and keyboard navigation.
Establishing a Governance Process
To ensure that the revamped DLS didn’t suffer the same fate as its previous iteration, it was essential to establish a governance process that allowed for the DLS to evolve with our products, without discrepancies forming over time. To address this, I created an initial governance plan for teams to follow when requesting the addition of new components or changes to existing components. This process also resulted in the creation of Jira workflows specifically for the design system team and dedicated communication channels within Slack.
Driving Adoption
To encourage the internal adoption of the revamped design system, I took the time to redesign many of our key screens and workflows using our new and improved components. These redesigned screens were then presented to product teams to demonstrate the potential our newly revamped design system had for improving user experiences and promoting overall consistency across products.
Outcome & Next Steps
The response to the newly revamped DLS has been extremely positive from both engineering and design teams. Results include:
Time & Cost Savings — Designers and Developers are more aligned than ever, resulting in less time being wasted trying to decipher how a component should and should not function.
A system that stands the test of time — Teams across our organisation are confident that the newly designed DLS will be capable of growing and evolving with our products.
Inclusive & Accessible — The redesigned DLS was built with accessibility in mind, giving our teams confidence that anyone can use our products regardless of impairment.
Increased proactivity & adoption — The introduction of the new design system has motivated teams to participate actively in the design system process and discover fresh opportunities for reusing components.
As for the next steps, we are still in the process of building and developing all the documented components. However, once the process is complete, the plan is to further refine our governance process to ensure that all components and patterns can be updated easily when requested, allowing the DLS to cater to evolving needs.