Learnings from building a design system
Introduction
As hitting a software crisis made early programmers rethink the quality and the way they structure their projects, in recent years a similar trend started happening in digital product design as well. Design systems were introduced to better manage UI complexity and have changed the way modern web applications are built, since managing bespoke design at scale can be challenging.
So, what is a design system?
It is a framework that outlines a shared set of rules, constraints and principles¹ to build consistent user interfaces across applications and devices. It usually consists of UI pattern libraries for design and code as well as a collection of guidelines on pattern behaviour, their look and feel, appropriate use and even content guidelines.
Having a successful design system in a company enables it to:
- build new products faster and with lower costs,
- form a shared language which supports better collaboration between teams, and
- launch products with better user experience which reduces the end user’s cognitive load.
Great examples of design systems are Shopify’s Polaris, IBM’s Carbon or Google’s Material Design. For more examples, check out Adele, a great repository of publicly available design systems and pattern libraries.
How it all started for us?
dunnhumby Media has a set of tools that are built in-house and help our internal users to activate media campaigns as well as see their performance evaluation. As our company started laying out a roadmap that is more outward focused, this also raised a question of how we could align all the products and services so that they are presented to our clients in a consistent and easily recognisable way. The maturity of what we had up to that point was not high², as we had a static set of brand guidelines defined by our Marketing team and a basic component library for creating designs in Sketch.
We’ve set out to define a Media component library and pattern guidelines, with the goal of having this as a shared foundation to build our new products and update existing ones. We wanted to offer our teams a clear and modular way to build applications so that they have consistent look & feel and behaviour, since many of our internal users use multiple tools in their day to day activities.
The efforts to evolve our design system to a managed one can roughly be divided into four steps:
- Conducting a UI audit and introducing UX refinements
- Creating a Sketch component library and writing pattern guidelines
- Developing a codebase for components
- Adopting design system in more projects
1. UI audit and UX refinements
We started building on top of an already existing Sketch component library by doing a UI audit and usability tests of our existing tools, as well as ideating from the scratch for new projects. We combined these two approaches to determine which components would be the basis of our new design system.
During the usability testing of past designs, we discovered the following issues that needed to be addressed:
- The navigation patterns were horizontal and therefore not easily scalable, as such navigation didn’t support well the more in-depth application structure.
- Button types had accessibility issues, with no clear differentiation of information hierarchy; the use of brand magenta colour did not look engaging to use for main application actions.
- The grid did not accommodate different device sizes, especially for full screen, which meant that data-heavy list & table views would suffer.
- Visual UI problems negatively affected the application experience; certain UI elements were taking user’s focus away from the data displayed and were perceived as too bulky.
2. Sketch component library and pattern guidelines
All our designers use Sketch in their daily work, and version their UI files through Abstract. Since we’re a small design team, this means that we’re contributors and consumers³ of our design system at the same time.
When assessing the state of our Sketch library last year, we concluded that we were not happy with the component taxonomy which grouped components into themes and caused discoverability issues. The use of nested symbols in Sketch components also proved hard to maintain and often confused designers in terms of what to use and how to apply the overrides.
For these reasons, we decided to flatten out component taxonomy so that all components are just alphabetically sorted, and we also switched from nested symbols to layer styles to manage component states. We also found that some of the components in our library were not used, so we deprecated those.
Along with these improvements, we started to update the pattern guidelines by adding more descriptive explanations for components as well as linking them to the Storybook pattern library that was exposed by developers.
3. Codebase for components
During the audit, we found that, on top of having a different adoption level of the dunnhumby branding, different engineering teams were using different technology stacks across the Media business. This meant that our engineering teams had to agree on the development stack they would use moving forward. It also meant that older tools with legacy codebase would have to put the component library adoption to their roadmap.
Since we were not able to assemble a dedicated team to govern the component library development, the engineering teams approached it as a collaborative effort where contributors would add components as they would be needed for their respective projects.
Ultimately, the components were developed for React and presented with Storybook. This component library is a joint project among multiple engineering teams who contribute to the repository and maintain it as part of work on their respective products. When any product needs an update to component library, the review process including designers and developers from other teams ensures that component that is added or amended is modular and up to coding standards. The library is versioned so that each team can decide when to propagate which changes for their product.
The next steps for this library would be to align naming conventions of React components to the ones used by designers and to combine pattern guidelines together with component code snippets in one place.
4. Component library adoption
As mentioned before, adoption of a design system is quite a challenge⁴ which depends on how design driven the company is and how open it is to change. Since there doesn’t seem to be an immediate business value in investing into a design system, it’s sometimes hard to secure dedicated resources for it. To tackle this, we had to raise awareness about the benefits of having a design system throughout the company in two ways:
- Educating business stakeholders about what design system is and what value does it bring
We created a pitch to raise awareness about the benefits of having well designed products (great UX = better user satisfaction and efficiency), and to justify why the design changes we propose would be sensible. We emphasised the long-term benefits of having a single codebase for all products and proposed a roll-out plan for a design system adoption considering the roadmaps of the products that would need to adopt it. - Aligning with our product and engineering teams on introducing a design system as part of workflow
As designers, we had to be mindful about keeping the UX patterns consistent and introduce component changes only when necessary. We worked together with developers to assess the technical landscape and plan how the new component library could be adopted. The projects that are dealing with technical and design debt had a different approach than the ones starting from scratch in that they started to progressively roll out component adoption into product as sprint cycles allowed it to, so that feature development that is perceived as having more business value isn’t impacted by the ongoing changes.
Conclusion
In recent year, we have made a tremendous improvement in evolving our design system to a more governed state and to advocate its usage across teams as the starting point in developing projects. We are currently in the process of adopting components from the design system into more projects and expect to see less friction and more consistent user experience as a result. We have still a long way to go, but the solid basics are in place, and along the way we learned a lot. Main take-aways:
- Having consistent naming conventions helps to increase the discoverability of components for both creators and consumers of a design system.
- Unifying terminology ensures that design and development speak the same language and brings the teams closer together.
- Having a stable design language of the components and thoroughly testing them in the UI mocks reduces the time and effort from the engineering side when starting or updating a component library.
- Having the documentation published and readily available helps in ensuring consistency across different projects, since it serves as one source of truth for behaviours and UX patterns.
- Acceptance of the long-term benefits of a design system had to be promoted within the company. There was an initial fear that focusing on this would impede the development of the features that are perceived as bringing more business value, so we had to make sure everyone understands that building a design system is hard at the start, but in the long-term it increases the speed of delivery.
- Having clear ownership over design system helps a lot — if the design system is managed as a product, the contribution and evolution is faster. If this is not possible to achieve for a company, then there needs to be enough design and frontend champions that will govern the adoption process for their teams and contribute to the component library along with their product-related responsibilities.
[1] Sylvee L. “What is a Design System?”. Muzli Magazine // Medium.com, 21 Feb. 2018 https://medium.muz.li/what-is-a-design-system-1e43d19e7696
[2] Somers, M. “Design System Maturity”. Slalom Build // Medium.com, 9 Nov. 2015. https://medium.com/slalom-build/a-maturity-model-for-design-systems-93fff522c3ba
[3] Klein, N. “The spectrum of maturity for design systems”. Design Systems. Version 2.0.0. https://www.designsystems.com/the-spectrum-of-maturity-for-design-systems
[4] “Creating A Design System: Organizational Buy In”. Design Systems: Step-by-Step Guide to Creating Your Own — UX Pin https://www.uxpin.com/create-design-system-guide/get-organizational-buy-in-for-design-system
