Design system FAQ: adoption and implementation

Too much talking on which tool, too little on who’s using it.

Alberto Vitullo
UX Collective

--

Foreword: I worked now 6+ years with Design Systems (DS). I was there when it started (Check this), and now I am here writing about what it has become. A buzzword, with a lot of noise around, that has made it very difficult to find reliable sources. Nonetheless, I hope that what I write will prove itself so close to your reality, that you will find it actually useful.

This article is for you if:

  • You are contemplating starting a DS
  • You have created a DS, but it is not performing as you expected
  • You know all about DS, and how to structure Figma libraries in variants and components

Adoption is at the core of design

Adoption is not a new aspect of design. Branding FX, has always been about creating visual frameworks to implement a unique brand identity across all touchpoint. If we roll back to the “offline era”, agencies were mastering the effort of documenting those frameworks into one-time published manuals. Some of them became real icons.

The NYCTA Graphics Standards Manual contains scans of Massimo Vignelli and Bob Noorda’s (Unimark) modernist masterpiece.
The NYCTA Graphics Standards Manual contains scans of Massimo Vignelli and Bob Noorda’s (Unimark) modernist masterpiece.

With the coming of digital, few aspects have changed:

  • Changed: brands aren’t existing only offline anymore, but online.
  • Changed: online means constantly evolving, connected, measurable.
  • Changed: visual frameworks aren’t defined “one time”, then published and delivered in a manual. Design systems are living rulesets, expressed in libraries of changeable components that silently follow and assist the work of product teams using them.
  • Not Changed: The people working with these frameworks. The same people who for years has used a brand guide as an inspiration artefact, now must work using a much stricter ruleset. The same people who were discussing colour codes with print labs, now have to communicate to front-end developers in a completely different language. It’s an immense effort, and realistically, it will take a very long time for our client teams to catch up with this aggressive digitalisation.

What do we do then? We can’t send everyone home and swap-in fresher, eager, digital designers. Now more than ever, our job has become about designing a system that sets them for success. That means the legwork is on us, we have the responsibility of making sure everyone can operate their DS without breaking a sweat. We need to use the DS as a medium to slowly transform them into digital designers. Adoption once again is key.

Adopting a Design System, a change of mindset

The first roadblock to overcome is the change of mindset. In companies where the value of design isn’t fully understood, concepts like collaboration, consistency and unified experience are rarely well implemented. What is the reason?

A company not committed to fully implementing healthy design practices, won’t likely put too much effort in investigating how design is executed in its teams. In other words, small budgets for documentation allow loose governance over teams, whether it’s product or marketing. Loose governance opens also for the creation of an internal culture where personal taste, best guess, and different brand interpretations are core part of how the job is done. For how self-empowering it sounds, if not channelled correctly, these behaviours lead straight to brand dilution. In a market ruled by customer experience, a brand coming out to market blurred, noisy, or inconsistent, has very little chance of success.

Fine arts can be subjective. A corporate brand identity must be objective, and this is not my opinion, I can prove it! Imagine using your iPhone on your way to work, then your iPad at home and everything is suddenly different: the way it works, the way your apps look like. Imagine then the day after at work switching to your Mac, and once again, it’s all different. Frustrated, I would call Apple asking for an explanation. The answer would be something like:

“Hi Alberto, we often hear customers with the same frustration. The reason why your operating system is pink on your iPhone and green on your iPad is that the former has been designed by Joe’s team in London — he loves pink — and the latter has been designed by Paul’s team in Brazil. Those teams communicate rarely, but most of all, they deeply disagree on how digital design is executed. Joe believes Apple is a pink brand, instead Paul thinks we are a green brand. While we try to figure out how to fix these issues, we deeply apologise for your uncomfortable experience, nonetheless, we hope you will still choose our products in the future”.

In 2022 a brand can’t afford to not provide a unified experience. Customer interaction must be intuitive and seamless across devices. All teams, both product, and marketing, need to start acknowledging the idea of uniting their effort under one experience, whatever it takes. It means 100 departments = 1 customer, not 100 experiences.

Super important: Clearly, the successful implementation of a DS requires a substantial organisational shift. It’s an effort that only management can lift. It has to be the brain to communicate to the rest of the body how to move, not the other way around.

Essential for designers: Once a company adopts a DS, the culture of personal taste, best guess, and open interpretation has to change, no matter how hard it is. You will hear “DS kills creativity”. Then explain that a DS sets some limits aiming at channel and regulate the creative flow. It creates a sandbox for teams to operate in safety. Only think of how many figures one can build with the same set of LEGO. Designers need to re-caliber their definition of success: in the corporate industry, consistency has always won over “one-off uniqueness”.

To be academic, I could argue that designing cohesive, functional, visual frameworks where a brand can be expressed granularly across country, language and device is a very difficult tasks for a designer. On the contrary, creating something new every time, following no rules but same colours, it’s way easier. But then why are we calling ourselves professionals? Have anyone who can operate a design software to do that job. Where is the value that we add?

First create a unique brand expression, then figure out how to implement it consistently everywhere. That’s the goal, and that’s exactly what a DS is built to help us doing. Therefore, working with a DS is not a free choice, nor an open option to consider. But the only way to make sure that what we create is compliant to the brand experience, visual and functional, that we’ve designed.

See a design system like a Dictionary, with those words you can write any sort of poetry

How do we make sure people will use it?

Assuming we managed to bring management onboard, and the whole organisation, or a good part of it, is ready to accept the idea of working together, connected and aligned to the brand experience they represent; how do we make sure people will adopt a DS in their workflow?

A funny gif about misdelivering
My first Design System delivery, back in summer 2015

Many DSs crash and burn. I’ve crashed a big one myself too. Without that experience, I would not be able to warn you against these mistakes:

  • Wrong ownership: It’s owned by an external contractor, so once the hours run out, the project ends. Nobody from the client has ever owned it, nor knows how to continue the work started, promoting it and keeping it alive. The DS loses relevance, gets obsolete and outdated. Teams go back to do what they were doing before. (I wrote about ownership here)
  • Wrong governance: The system doesn’t address what teams need. People miss elements, they are often forced to best guess. The rules are too strict and do not help the context they are in. Nobody is responsible for gathering these insights and updating the DS accordingly. The DS lacks relevance, gets obsolete and outdated. Teams go back to do what they were doing before.
  • Wrong format: Teams have always worked with Photoshop and PowerPoint. Not aware of this, hyped by the opportunity, the DS team decides to create a brand new Figma component library, and flashy Keynote templates. What the team should have been aware of, is that people have deadlines and busy days; people also have developed their habits along the years to get their job done. Learning new tools and a new way of working, with a lack of support, it’s too much hassle. The DS loses adoption, therefore relevance, it gets obsolete and outdated. Teams go back to do what they were doing before.

Some digital designers are focusing a lot on crafting action-packed libraries, ensuring they tap into all functionalities softwares are making available. Sadly, I am seeing very few keeping their focus instead on what DS users need, utilising those amazing features to make libraries viable, and not uselessly over engineered.

Few paragraphs above I wrote “…design systems are living rulesets, expressed in libraries of changeable components that silently follow and assist the work of product teams using them.”. Silently! A great rule of thumb to set yourself for success in implementing a DS is to make its implementation as smooth as possible.

  • If the company works with Photoshop, build a Photoshop library.
  • If the company uses Sketch, build a Sketch library
  • If the company uses Microsoft Paint, build a Microsoft Paint library
  • And so on

Adapting the DS to what people are already used to, increases drastically the likelihood of adoption, especially if backed up by management’s blessing. And yes, you will probably think “how retrograde” or “why don’t they use Figma variants?! It’s much smarter!” Well, our job is to set them for success, not to use their business as a ginny pig for our library experiments. Ever heard of “if Mohammed can’t go to the mountain bring the mountain to Mohammed”?

How do we make sure people use it the right way.

Yep. One last step.

  1. First, the change of mindset
  2. Second, a framework not foreign to their practices
  3. Third, provide a clear set of rules and guidelines
Please print this in poster format and hang it in as many places as possible.

Over-engineered or not, a component library is not a DS. But it equals simply to a set of lego bricks tidily organised into a box. Without the actual instruction manual of how to compose them together, we are giving no reference to DS users on how to play with it. The rules do not need to be 100% accurate, but they must express the amount of knowledge that you, as DS team, have gained by crossing your implementation research with the brand expression your are trying to deliver on. It is crucial teams do not perceive rules as absolute limits, that will prompt rejection. It’s more a mindset of constant change and update. Sentences I often use when implementing rules for design systems are

  • “…this is what we know so far”
  • “other teams in the same situation are solving the problem in this way…”
  • “at the moment we are all using X colour in this way…”

As you probably notice, we are softly shifting into Governance, which is an argument I will write about in another FAQ article in the future. I hope this article led to some useful thinking points. I am always available to discuss about this, feel free to reach out at any time. Thanks.

Other articles I wrote about design systems

--

--