Hi, I’m Jiri (in short J+). I’m a product designer who has coded since 1992. Before creating a design system, I built a wealth of brand guidelines and marketing packages for small, medium, and large businesses.
Over the years, I have always asked questions about how successful, impactful, or revenue-generating the things we designers create are. How can we measure the impact, and how well can we articulate the reach of our work? Assuming that someone, somewhere, somehow uses the artefact that we were perfecting for a week or so to be used again for a greater benefit of consistency or the overall company?
The learning I’m about to share comes from work ranging from building multi-platform systems from scratch, updating existing design systems in highly regulated environments, debranding, and tokenising more than +3k components to creating the CTV ecosystem, which touches 17 different viewports across 14 none-Latin based languages.
As much as we can generalise these learnings, I want to focus on the business, design department or individual member impact;
- You do not need a design system?
- If you need one, do start from scratch.
- Transparency over consistency.
- Go faster
- Be smarter
- Strong adoption
- Feedback loop
- Business Integration
- Scale
You do not need the design system.
Many opinionated debates argue that every proposition needs a design system. I always mock up ideas, and I do not usually use my own well-defined RUNWAY Design System. Why? Because it creates constraints.
It has all relevant components from aviation, transportation, finance, retail, education and broadcast, yet I prefer a clean sheet of paper when mocking up new behaviour.
That said, I always design from components. When I reach +30 components, I create a separate file called CORE. (The naming convention will be part of a different article) Then, the “CORE .DS Client_Name” plays the role of the design system when we need to scale even further. +300 components get me to the structure where I introduce “CORE .Foundation” – the file that holds all the primitive values like colour, font, grid, space, radius and so on (it does not necessarily have to be tokenised). This is followed by the “CORE .Integration” that holds all the components and their appropriate variants for different viewports.
If you need one, start from scratch.
The current generation has built very little—that is not a critique but an observation. What we all essentially use was built by decades of free tutorials and librarians stacked on top of each other in various shapes and forms. Very few designers start from scratch — and that is the fact!
When I start from scratch, it is only when the design system is so unique it can not be further modified or integrated with any other style. This brings up two very interesting points. One is where the creativity starts and where it finishes. Because, at some point, it is only the token value that controls the viewport, style, size, spacing, radius, and surface. The second is who drives the DS proposition.
Using the UI kits to create your DS is a direct way to hell. If someone stating otherwise, here is a quick thought to share. The time you spend refactoring three different UI kits to achieve consistent output (renaming them, recolouring, resizing and adjusting them) – a team of one can make it 3-4x faster. The secret source is the content audit and visual direction. This includes three different viewports covering auto-layout. Everything else becomes a variant once bases are agreed upon, recorded, and implemented.
If you are dealing with a multi-platform, multi-brand scenario, the foundation and governance are far more important than the diversity of the design system in different parts of the business. That is also when you need the business's buy-in. (Techniques for RIO and position will be in a different article)
The fastest and most common way is to reskin an existing system (not a UIKit) that encompasses your required component. Some designers and non-designers experience this when proceeding in such a direction: the work increases exponentially, and maintenance outnumbers creation. Therefore, you spend more time on DS’s changes, which does not produce value for the company.
The bottom line here is to build as you go alongside your development team.
Do not underestimate the power of a well-connected and well-integrated design system with GitHub or BitBucket repository. Small (2-3 member) teams can outperform 20+ member design teams in less than a week as they require less management and have 85% of their operations automated.
Transparency over consistency
You’ve built your very first design system – well done! Now, you’ll spend the same if not more time documenting it. There are two reasons. First, no one likes documenting past work for the sake of documenting – that is why most of the documentation is not read as attempted. The second majority of the documentation lives in design space (preferably Figma, Sketch, etc.), and none of the development or business team members has or want access to it. Why?
Because they are not designers.
When reviewing the work of other teams, you see that something is constantly off. Why? Because no one read your spec. In fact, we spend 30% of our weekly communication replicating facts that we can document once. It’s about location, not consistency and precision.
Let’s start with documentation, which we call knowledgebase—no guideline, editorial guide, non-functional spec, or design requirements—these are all different entities and have different purposes.
On the other hand, knowledgebase has a singular purpose: to keep and share knowledge between different parties. I use Confluence as I work in regulatory-heavy development environments, but you can use Notion or anything else. The purpose is to replicate the structure of your design document in a written format, where you compile all agreements and verbalise all assumptions about behaviours, models, themes, and so on.
Design at Scale™ Academy runs workshops and webinars where we show these examples in practice.
Some might say, "But that is so much work that I do not have time to do." Leading by example and creating such a repository is beneficial to you, as it is to all designers. I guarantee you that when the same is presented back to your engineering team soon, you’ll have a code-related repo and accessibility criteria embedded in your designs. And within the moment, you have a knowledge base that everyone refers to.
Go Faster
This brings us to the following point: speed. Very few businesses measure the velocity and ROI of design. With all the available data, I would think that in the 21st century, we’d understand our burn rate and how best to position automated DS in our business model.
Simple theory into a practice
Creating a component takes a day or so; creating a fully automated tokenised component will eventually take the same time. The first component must be copied and constantly adjusted to the viewport, theme, copy, image types, illustrations, etc. The fully tokenised component is added to the scene, and it carries the behaviour within.
Creating 5 brands, four themes, seven templates, and three viewports requires 420 screens, which a team of 6 designers can complete in two months (assuming the brand is fully defined). The tokenised version can be completed in less than a week.
But this is not the selling point.
The selling point here is that if we want another brand or theme, we create only values for this theme. All screens will be automatically adjusted, sharing the same values and properties. There will be fewer errors on the component level and zero errors on design development handover—usually a 60% time decrease due to automated testing and less refactoring.
Let’s stay with the engineering team for a little longer. A design system is not only a definition of primitive values that can be stored in a digital repository. It is a written manifesto reflecting brand behaviours and mental and navigational models embedded in the code so that our engineering team can translate brand equity directly into the code.
Writing a knowledge base is step one. Smarter businesses often validate the velocity (speed of delivery) and create their own functional spec for a unique digital property—whether a website, app, or online store. That involves the basic scope of engineers, business analysts, and solution architects.
Be Smarter
Once the design system has its foundation, “the design architect” becomes the “design advocate”. This is a pivotal role for the business, and all businesses that did not choose “maker” as “design advocates” burned a substantial amount of money (a cross my 10+ year research, 27-37%) on design transformation and their design systems were always broken.
Being an advocate does not mean you have to be good at public speaking. However, it means that you are very good at translating the impact of the DS on the business. And that means talking less about controlling pixels and colours and more about integration, transparency, budgets, time to market, standardisation, classification, assets management, releases, device support, and so on. We explore these topics at Design at Scale™ Academy.
Being practical means understanding that 40% of your components will be broken (well, I mean in a state of testing/improving branches), and that’s fine as long as you are transparent about it. More requirements will come with mode domains and/or different viewports. Have a triage system that allows you to communicate demands to the team. Quality control needs to be intact and aligned with company standards.
Adoption – is about informing, not preaching. Say what you’ll do, do it and then broadcast it. This way, you reach the cadence that will allow you to address most operational pitfalls. In many cases, I run teams with this set-up – one super strong brand designer who sets the direction and articulates why we do what we do. The second person is the Design System Architect – a technical (almost code-level) designer who understands how to translate a brand into values and behaviours. The last one is the artworker – the maker, the person who rolls the sleeves and makes things happen, no question asked.
Stronger adoption
Looking for stronger adoption – introduce “Show and Tells”. I’ve run Show and Tell successfully in broadcast and finance corporations for over a decade. Starting small is the hardest but also a lot of fun. Create five slide decks and invite one person or two. Ask them for feedback, and next time, invite one more person. Better adoption of your system means more people talk about it in their own time. Give them the assets they can discuss so your team can become an internal advocate running their internal campaigns.
“Did you know that J is doing his little shows on Thursday _ Let’s check it out.”
Soon enough, it will have business leaders on it, and you’ll be answering business questions and building separate teams. Presenting and documenting are not everything. You must be meticulous in organising and prioritising tasks and understand who consumes what and how they find it. They all provide feedback as an action well broadcasted and integrated after prioritisation. Do not integrate all feedback a/ it’s impossible, and b/ it’s not practical.
I often ask, “Should we have a Slack channel?” Slack channels are fine, but I’d recommend them as a temporary solution. What you are building is a product that needs to be serviced 24/7 – 365 days a year. Any delay, ambiguity or potential lost reference costs money. And I haven’t seen any business that makes money on Slack.
On the other hand, Jira (or equivalent) is a different cup of coffee. You and your team, including the business, know where you are, what you have done, what is missing, what has been prioritised, and how long it will take to the next release. As far as I can tell, my Slack can not tell me any of these. If your Slack does, bring it to the game.
Feedback Loop
That brings us back to the feedback from your team.
Listen, build, test, (document) release, measure. This is not a double diamond, agile, or any other jargon framework. It is a simple, pragmatic test-and-learn loop—please do not call it a process as all of these interactions happen simultaneously.
Listen – to all the feedback, and I mean literally all. Have a method to record it. Ideally, you should find a place where you can track it, organise it, prioritise it, and assign it to another designer colleague. I use Jira, not Miro, Muro, Mural or Jams. Here is a simple why. Having all the bugs and future tasks in one backlog allows my team to prioritise things that matter and see the garbage from people and wat they think about DS. With this lens, we have resolved several challenges before they become a problem.
Build—build it fast and release it as often as possible. Building in small chunks allows your team to focus on one item very well and make well-informed decisions about the very specific release. Honest feedback is better than 100, so-to-be-called “senior assumptions.”
Test—Internal and external tests in the production line help you recognise that even the greatest design does not have a real impact on revenue. Do not dump it. Find different ways to improve it. This is the place where you gather essential feedback to articulate the feature's value proposition. Sadly, some teams use testing to kill things with high customer value yet need better education.
Document it—it’s kind of obvious, but let me say it again: Documenting your work is not against you and does not take much of your time. It’s for you and your team, especially development and business. If you want to know more, jump on the DaS™ Grid.
Release—make sure you propagate your release and broadcast your changes. I have always run weekly releases. This way, we provide ourselves with two things that allow us to make better decisions. First, our engineering team can see the foundation and integration level. Second, our business has an RAG report to which they can refer when things go sideways. It also protects your design team from “what have you worked on last week two months ago, type of questions.”
Measure—The design system without KPIs and ROIs is just an online text file with many values. Sure, you can do things faster, but you still do not answer the fundamental question of what value the design function creates in your organisation. Our team has a solid matrix that allows us to measure delivery speed, velocity, quality, risk reduction, and more.
Business Integration
Business representatives will inevitably ask the curious question, “Why do we have or need a Design System?” – designers used to say, “We’ll have it all in one place” or “to have better control” or worse “we’ll be faster on delivering”.
If your team is not a total mess, you can have everything in one place semi-friendly organised, but that is not real value. Do you need more control? Yes, if you and your team are disorganised, this is the way to address it, but businesses do not care. Being faster is a currency, but I guarantee this trade will most likely cost you a job.
The real value lies in transparency. With an incremental demand on the performance of more complex systems (assuming you are dealing with at least one brand with three digital properties and six different viewports), the design system offers assurance and standardisation to end-to-end product design development. It closes the loop of the Business, Design, and Development tied by one simple string called DS that usually lives in parallel with its code counterpart.
The abovementioned measurements, alongside a track record, allow all companies to decrease risk by monitoring what, when, and where was released. We measure and control 80% of the DS pipeline, delivering transparency across a 300+ member digital team.
Scale
Design is here to scale, and scale is the only thing that matters. If you build things (even in the digital world) and they do not scale, chances are that you’ll spend more time on maintenance than on creation and growth.
Design st Scale™ offers articles, materials, and courses, sharing the knowledge of 90+ design directors from all over the world. The creative work we have seen has an impact used by millions.
My thanks go to all contributors, students, and design directors for their insight and comments, which shaped this article.
Jiri Mocicka is a London-based Designer, Trusted Advisor and author of Design at Scale™ — A method that allows individual contributors to shape the future organisation through design.
Design at Scale™ offers a variety of articles in Grid Magazine, an Online Academy, and Supplies. Visual stories @designatscaletm, for direct messages and questions, please reach us: @designatscaletm.
Stay tuned; thanks for reading!
