Part 1
Or ‘What I didn’t know I needed to ask before I started.’
In this first of a two part post, I look at getting buy-in for and measuring the value of Design Systems. Part two is coming soon …
People have a strange compunction. They yearn for both order and freedom, and spend an awful lot of time trying to navigate between these two ideals. We want to be unique but not strange. Stable but not stagnant. Practical but fun. Realistic but innovative.
Since this article is about Design Systems, I hope you see where this is going. Design is the expression of this balancing act. As designers we give form to a weird creative impulse, we draw lines across a blank canvas, we articulate solutions to seemingly intangible problems. And we are never truly happy with the results because there is always a compromise between freedom and order. A Design System is one such trade-off.
Are you OK with the trade-off?
Accepting this trade-off is perhaps the first step in creating a Design System. Perhaps the actual trigger was Product Management asking why this button is different from that one, or QA lamenting the plethora of classes used in different instances of the same component, or you yourself becoming frustrated by your own tendency to introduce chaos by designing something a little ‘better’ each time, so that your app has become a map of your own design maturation.
Whatever the impetus for building a Design System, the underlying desire is the same — to create order and restrict variation.
Re-focusing design
If you are reading this, I will assume you have accepted that something must be done to systemise your design. There is an argument that Design Systems limit creativity but really, Product Design itself entails a certain limitation on creativity. Most of us work within business constraints to deliver value to our users and this is a good thing. I would further argue that a Design System shifts the creative focus away from its tangible expression in the user interface to a more rewarding and challenging focus on innovating the underlying user experience. If designers and developers can reach for a set of robust, agreed components, we can devote more of our talent and time to thorny UX issues that defy standardisation.
So, that’s the first question out of the way — do you accept that a system will place some constraints around your creativity? If you see value in order, scale and focus, then you are ready for the next questions. I’ve organised questions worth exploring when first kicking off your Design System into 3 broad categories — Buy-in, Foundations and Processes. I’ll explore the first in this article and address the second and third in a later post.
But before going further, I’d just like to point out that what I am talking about here is not just a Sketch or Figma system. For me, a true Design System encompasses the design and code artefacts. In fact, our North Star should be a cross-functional team working entirely in the user-facing artefacts — designing first in Sketch and then in React or Vue is an inefficient workflow born of technical limitations and is one of the main drivers for creating a system in the first place. As our tooling and skillsets begin to blend, I believe this gap will increasingly blur and eventually disappear. I can’t be bothered with the ‘Should designers code?’ nonsense — declarative frameworks and smarter tooling are coming and designers will increasingly build code artefacts.
In the meantime, we should be pragmatic and realise that any effort expended on components that are not user-facing can be perceived as waste by the business and so a Design System should seek to reduce and eliminate, wherever possible, such inefficiency. Such an approach will prove invaluable when getting executive support. Speaking of which, let’s dive into the first category of questions — Buy-in.
Your business will be different from mine but there is always a bunch of people to consider so it’s really worth identifying them and thinking about how you will get them on board and keep them aligned going forward.
Who cares about your Design System?
A stakeholder map is always a good place to start any complicated project. And boy, are Design Systems complicated.
It’s worth remembering that such maps are not set in stone, but rather the basis of a plan to improve engagement with key people as a project progresses. If you realistically assess at the outset that a particular crucial stakeholder doesn’t give a fart for Design Systems, then it is on you to change that. Highlight those you wish to influence and the direction you want them to move and be intentional in your dealings with them.
A Design System has 4 broad categories of stakeholder that I’ve named Makers, Contributors, Observers and Supporters.
Who are your Makers & Contributors?
Makers are those that will manage, design, develop, document and maintain the system and should include Designers, Developers and, hopefully, Product Managers. Makers must be intimately involved — your documentation and processes will impact them directly — and so it’s a good idea to have a dedicated Slack channel and regular ceremonies to ensure alignment. Who exactly comprises your group of Makers will depend on the kind of contribution model you decide upon (more on that in the next post) but you should have a champion in Product, Design and Engineering. This is the one person in each function that will evangelise for the Design System, put in place its processes, manage its backlog and actively contribute — whether in documentation, design or code.
Contributors are those consuming the Design System and may include members of the development team who can compose with components but are unable to directly contribute to the system itself. It may include testers too at first but probably quite quickly you will find QA sees the value of reuse and standardisation and starts to actively contribute to the project, whether through test scripts or more exacting acceptance criteria. Engage with your Contributors through release notes and the project itself. Consider hosting your Design System project as a single-source-of-truth with usage notes, mock data and configurable, testable components — Storybook is a great way of doing this for React, React Native, Svelte, Angular or Vue projects.
For both Makers and Contributors, a satisfaction survey is a really nice way to engage and gather invaluable feedback on impact, adoption and satisfaction with your Design System. Ryan Lum has some nice ideas on this, suggesting questions like:
- How often do you find yourself using the Design System?
- What is one thing you would improve about the Design System?
- On a scale of 1 (strongly disagree) to 5 (strongly agree), does the Design System improve your workflow?
Who are your Observers & Supporters?
Observers are not actively involved, though they will have an opinion and may check in now and then. You should anticipate this and keep them occasionally informed by including them when sending out major release notes. Blog posts are another good way of including, and perhaps increasing the engagement of, those with low interest and impact.
When mapping out your stakeholders, you may well find that someone you need more actively involved is not entirely convinced (Yes, I’m looking at you Product Management). If you do find that someone whose hands-on involvement you need ends up in the wrong box, then you should have a strategy to get them more engaged and pull them over the line. You may find certain stakeholders’ involvement may evolve as they come to understand the value of what you are building and even surprise you with ideas for contribution that you had not initially considered.
Those in the Supporter category are generally managers whose approval you need. Quarterly reports showing progress against your key metrics are a good way of keeping these executives on side. More about executive buy-in below, but essentially, make sure someone has your back as things can get rocky and someone in power who gets it is an invaluable ally. Your users can also be seen as supporters — albeit unknowing and external ones — as the Design System should have a positive impact on the user experience, which can in turn be used to reinforce buy-in with internal supporters. All of which brings me to the next question …