A (un)comprehensive guide
Delivering a design system is one of the most formidable challenges for any design team committed to delivering digital experiences that unlock business value. This project is even more arduous when the team must adapt the components to multiple and diverse Corporate Identity design languages.
Theming of a design system is a critical step to deliver something that creates value for teams and enables adoption by the whole community. Multiple themes (Corporate Identity) defined the situation when the design team was tasked with updating and improving the existing UI kit. We had to manage a new Corporate identity and build a new version of the design system that was already delivering diverse themes. On top of that, the accessibility topic kicked in, and it became an essential part of the brief. After months of effortless work, the team had to manage two versions of the design system—one for the already-in-production solution and another for any new products. This task resulted in an unusual combination of component maintenance and a UI facelift.
As always, I sponsored to slice the elephant by prioritising tasks and initiatives based on the golden triangle of business needs, product roadmaps, and the company’s strategy. The plethora of applications and their different front-end tech stacks dictate this approach because it has been evident since day one that one solution to fit all is not our option.
As a result, the team had three main principles to define priorities and establish a timeline to share with all the stakeholders.
The first is sustainability. The team worked on a delivery plan that was 100% sustainable for the design, developer and product teams. We discussed with the teams busy with the most critical project to understand their needs regarding time and capacity to ensure that the transition to another design system didn’t block any business-relevant initiatives. Because the project had only one KPI and its adoption rate, the design team focused on preparing the components to onboard as many projects as possible on the new theme as soon as possible. The result was that we could onboard four teams building different platforms with different tech stacks. This situation enabled the Design Ops and the Dev teams to do a four-eyes check to validate component anatomy and documentation. This real-time feedback helps the team find the best compromise to deliver a product and tech-agnostic design system.
Second, relevantity. All the deliverables we planned, such as static UI kits, technical documentation and coded repository, were prioritised according to the most profitable business cases.
Third, humanity. The team worked extensively on establishing a design-agnostic vocabulary to describe components and artefacts to encourage non-designers to adopt the design system resources.
Here’s a more detailed description of these three principles that guided (guiding) the development and maintenance of our design system.
Design System Sustainability
I was reading about Keith Richards, the guitarist for the Rolling Stones, and apparently, he took one of the strings off his guitar because it was giving him a hard time. Even though most guitarists use six strings, Richards did what worked for him and his band. And it paid off big time – he’s now considered one of the best guitarists ever. His legendary solos helped make the Rolling Stones a total myth.
Like the Stones’ guitarist, the team focused on the essential stuff and removed the unessential.
Since the first version of the design system was already mature, we had an easy time prioritising templates, components, and patterns based on user data. This allowed us to improve the patterns in production with the first theme and redesign the same patterns with the new corporate identity for the new products.
With this approach, we have used the same component architecture to improve the user experience of live products and apply the new design language to the first project in the pipeline.
In the end, the way we distribute the design system looks like this:
Design System Relevantity
To keep sustainability at the centre of the design system project, we implemented a continuous audit of the most critical pages in terms of business KPIs, such as product detail, interstitial and listing pages. The team began to create components, according to the Atomic Design principles, only for these pages. The team accurately analysed the page anatomies to spot the core UI and UX patterns to build on to link the Corporate Identity’s mission with the best practices regarding usability and accessibility.
This focused approach pragmatically defined the component design roadmap for the two design languages.
In this way, we have been able to manage the different branches of the components.
Design System Humanity
As for every enterprise project, the team had to pitch visions, showcase proof of concept and report on progress. Once again, Keith Richards’ approach was the best option. We focused on what benefited the project and ignored the rest.
The team simplified its language when presenting design outputs. The component naming convention was adapted to the web standards to facilitate communication with DEVs and build consistency between design artefacts and front-end outputs.
We made an effort to link any design decision with business cases. This made it easier for everyone involved in the project to understand, approve and work towards the same objectives.
The reference to the business cases and KPIs helped the stakeholders to make informed decisions. In this way, it was straightforward for them to adjust the project timeline and the budget.
The simplified vocabulary made it easier for design and product managers to evangelise the design system’s short-term benefits to other stakeholders. The team also decided to present POCs built with coded components (Storybook) to showcase the design system’s benefits in a browser.
It’s no secret that a URL speaks more than one thousand slides!
Conclusions
Managing two different design languages in a complex situation involving multiple factors is challenging and demanding. Factors such as the intricacies of the environment, the urgency of the product timeline, and the significant investment required make it even more complicated. However, after careful consideration, we have adopted an approach that appears to be the most sustainable and effective in achieving our goals. As most of you do, our approach is designed to address the situation’s complexities while ensuring that the team meets the project’s timeline and budget requirements.
From now on, I trust you’ll listen to the “(I can’t get no) satisfaction” riff differently!
Caveats and feedback
Your feedback is precious to me!
Have you ever experienced something similar?
Image credits
Keith Richards onstage during a sound check, Denmark, 1970.
Credit – Jan Persson/Redferns — Getty Images