ABC of design systems
I wrote this article in 2017, it’s still relevant in 2022.
June 2017. The buzz these days seems to be about a new trend: design systems (DS). Apart from a niche of experts writing on blogs, the looks I meet on people’s face when I talk about DS don’t seem to be well received.
My credentials, I’m a designer leading a team that just completed a two years journey in creating and scaling a DS for a Scandinavian bank. A business with 19k+ employees across 8 countries and ca3.5 million customers.
This article is for you if:
- 01. You walk out meetings thinking, “I’m sure we all know what a DS is, but probably we use different terms to describe it” (words such as: pattern library, component library, styleguide, UI kit, CVI, digital CVI, online manual, etc.) These terms are used sporadically in your company, maybe also by your client, but they never seem to refer exactly to the same thing.
- 02. It seems people around you crafted their own definition, so it can be explained/sold in their own terms. This confuses you, especially because you thought you understood what a DS is, but their definition doesn’t match yours.
- 03. Teams don’t use the DS. People don’t find it relevant and can’t figure out how to implement it in their workflows. It doesn’t address what they need, and the format isn’t what they are used to. Frustration burns time, especially during a sprint — therefore teams decide to go back to the way they’ve always done, and promise to look at the DS when they will have more time.
In two years…
Big design conferences will be about design systems. DS experts (maybe me?) will be talking about this fascinating practice and amongst the crowd there will be few of our clients. The same very clients, stunned by the truth revealed to them, will knock at our door asking, “I need a design system for my company too!”
With this article, I would like to share some clarity about DS, so that you’re ready for that moment. Let’s get back to the 3 points above, because they touch upon 3 core aspects of Design Systems success: centralisation, ownership and implementation.
01. I’m sure we all know what a DS is, but probably we use different terms to describe it
Wrong! Ensuring that everyone adopt the very exact terms to refer to the same topic is of vital importance. It’d be better to adopt the same wrong terms consistently, than to have everyone naming things in their own way. Adopting a common vocabulary is one of the first steps towards implementing a successful DS mindset within your organisation. FX: a gallery, must be called “gallery” by everyone in my org. It can’t be that some refer to it as a “carousel” some as a “slider” some as “USP cards”.
#DS nugget: establishing and promoting a single, shared vocabulary to facilitate (remote) communication, breaking silos and speeding up processes.
To do it, you could define “dedicated DS teams”, “federated DS teams”, or both. Otherwise, if you believe your company being too green for such a big shift, simply nominate a responsible, find that person a partner, and make sure they sit together 10/15 hours a week. Give them mandate to organise meetings, presentations, games, or anything needed to communicate to their colleagues what they are doing, and ultimately, establish them as the go-to design system experts of your company.
#DS nugget: centralising design guidance for all of your company in one place, easily accessible by everyone.
02. It seems people around you crafted their own definition, so it can be explained/sold in their own terms.
A design system can’t be objectified and sold as fixed formula. It consists in fact in a bespoke framework, rooted in the company’s DNA and working culture.
A DS informs and is informed equally by 3 areas:
- Product: teams take full advantage of its components to build, test and release new features and ideas
- IT: owns the infrastructure, measuring and releasing constant improvements to products
- Marketing: make sure the brand expression is granularly represented across all touchpoint
Yet, someone has to own the DS. Sometimes it’s product, sometimes it’s marketing, sometimes IT. As a consequence, the agenda is rarely based on what the DS needs, but on what that department needs from it — it boils down to budgets after all, and IT will never blow their budget on marketing’s needs. Ideally, It’d require an independent team with separate budget, to operate objectively in servicing the 3 areas of the triangle. They will be the next design system unicorns: a title that’s not invented yet, but the duties are there.
Given how companies are structured now, a profile capable of dealing with such a complex task could be a C-level. That means a very busy figure with a ton of other important things to take care of. I am saying, it’s very rare to catch the attention of a C-level when you are selling a DS — the market is still too green. Realistically, you would reach someone from one of the 3 areas mentioned above: product, or IT. Therefore it’s crucial you change your pitch according to the audience you are taking to:
- A UI/UX design lead: will love the sound of a centralised library, available in Sketch, or their current design software. A file organised draggable components to build flows and wireframes at speed.
- A design/product manager: will welcome the idea of having a shared repository for design principles, to define the brand experience and explain the design process at a granular level. Furthermore they will love the idea of empowering teams with quick, high-fidelity prototypes for testing.
- Marketing people: will want to hear about an effective guideline to help markets and business units to unify the way branded content such as SoMe, newsletters, campaigns, online/offline material are produced. They will also find helpful to have a showcase of best practices for their editors
- Developers and IT people: will love the idea of a shared repository, re-usable styles and components. And the utopia of a wide range of products built with same codebase.
- If they are plain business: play strong on the idea of “it’s an investment, that is gonna get cheaper and cheaper over time, as our knowledge base grows and gets documented”.
Focus on researching the anatomy of the company you want to create the design system for. Find out who should be owning the DS. Develop a strategy for how to approach them. Show what’s in it for them, and only after talk about aligning with the other departments.
! Remember: never stop reminding them about the deep relation that their area has with the other 2 areas of the triangle. FX, Creating a DS that involves only the product department won’t make the DS effective. Instead, use the work you’ve achieved together to pitch to the other departments, show them value, get their buy-in.
— — Tips area— —
#Tip: It’s not about tools. Never mention softwares you plan on using, unless they mention it first. It can cost you the pitch. In my experience I’ve witnessed this:
- Mention Sketch: you’ll lose those using Photoshop/Axure/XD
- Mention Zeplin: you’ll lose those using Github or Bitbucket
- Mention Github: you’ll lose anyone who’s not a developer
Focus on the outcome, explain the first step consist in a diagnostic of their company, to understand deeply their current setup and its frictions. After this research, you would probably be able to make a software recommendation.
#Tip: Read through the lines. There are good chances that your client doesn’t know what a DS is. And most likely, until they attend one of those conferences where the truth will be revealed to them, they’ll look at you as if you were trying to sell them something they don’t need. Pay attention to how they describe their business: if they complain about lack of alignment, dysfunctional processes or slow development processes, you would know it’s your cue to show them how you could help.
#Tip: It must be owned internally. Say your client pays 800 hours of your time to start on their DS. What happens when the hours are finished? It’s a very delicate process, but especially external contractors are supposed to carefully pass their knowledge onto their client teams. As my colleague and coach James Kelway once said “we need to design our way out of it”.
If clients will not eventually own the DS:
- At some point somebody will pull the plug on funding. This means a drastic stop for the ongoing activity of documentation that keeps the DS alive. The reliability of its knowledge will age and become obsolete. Knowing it has been shut down, teams won’t go there anymore to seek for updates, eventually abandoning it. The 800 hours investment in starting the DS will be wasted.
- Contractors building the DS, represent a huge investment of money but especially knowledge. Part of your job is in fact to be the most up-to-date profile regarding design and communication practices within the organisation, the only problem is that you don’t work there!
- Competitors working on other tracks for your client, won’t be too happy to adopt the DS you are building for the client. They will challenge your work, which would be fair, in a constructive fashion. Sadly in my experience they intentionally misused our framework to prove the client the low standard of our work (very dishonest, but very effective). We learned a lesson; from that point onwards the client is the owner, we are only “researchers”. That made us more approachable.
If your client will own the DS:
- Can you imagine the positive effect that bringing a client to autonomous, successful DS governance will have on your own portfolio? Not to mention all the praise they’ll give you for having set them for success. That generated a lot of new business.
- When in trouble, the client will know who to call, and will not hesitate to sign 200 hours and more, to help them along their journey. You could be tasked to implement a new section, run some training, etc.
DS taught me the future of our services is shifting from “the ones who build a winning website for you” to “the ones who teach you how to build a winning website” #foodforthought
03. Teams don’t use the DS. People don’t find it relevant and can’t figure out how to implement it in their workflows.
When a team isn’t adopting a DS, it’s often because they don’t see their needs, nor their workflows being part of it.
“The secret formula for governance is ownership”
We all feel attached to something we created. My suggestion is to use the this strategy to implement a DS. Nobody likes changing their routine, especially if it involves using new tools or new practices: Sketch, Symbols, Auto-layout, Zeplin, Brand.ai, Craft, Abstract, etc. imagine when it comes to adopting a whole new system thinking mindset. In my case the toughest crowd is often senior designers, due to their long experience, they believe they have developed an eye for trends: “Oh yeah, this new DS thing— cool! Not for me though, thanks”. Again, it’s extremely important that we understand how our teams work, before we package a new design work flow for them.
The implementation must be seamless across departments, and generate the minimum amount of friction for its users. An easy one, do not ask them to adopt new tools, try to work with what they already use. This is what my team and I did with Root app: a simple desktop application to enable the DS owner to release an updated component library file for teams to work with. Root users receive a notification when there is an update to the library they are using, all they need to do is to press download, and it will automatically be installed in their default templates folder in Sketch.
— *note from 2022: when we created this app, Abstract didn’t exist, Figma didn’t exist, shared libraries didn’t exist. It was the beginning of all. Read more here
Other articles I wrote about design systems
- FAQ: Design Systems Adoption & Implementation
- FAQ: Design Systems Ownership
- FAQ: Design Systems & Styleguides
Credits:
