Dear (none)Designer,

Welcome back to the forty-fifth Design at Scale™ Newsletter – focusing on innovation and how design drives change in a large organisation or an agency.

While building my first design system in 2003, I was asked a very simple question. How do we measure the success or performance of the design system? Obviously, as a new designer in the field, I was slightly confused by the question of why I would need to measure something. Is it not enough if I just do it?

I quickly realised that doing something and producing the output doesn't necessarily mean that we achieve the proper outcomes. And that is where I first discovered KPIs – Key Performance Indicators.

I wonder why we need KPIs, and why we need KPI for the Design system? Since Mr. McKinsey laid down the foundation that everything in the business can be measured, the entire generation of managers and designers chased that rabbit to achieve operational excellence. Arguably, not everything can be measured; we know how much time is needed to design the feature, how long it takes to adapt the feature to an existing branding, and whether we can change the mode from green to blue. We also know how many atoms, elements and components are within the feature. Quite rightly, we know how many times we can reuse these components by designing the other elements. That said, it has been considered that we can measure the output of our work.

In reflection of the business, we can measure how much money we can save by using the design system to increase productivity and shorten the time to market.

Regrettably, this formula only creates more pressure on designers to deliver faster, often leading to detaching components from the actual design system and reducing the impact of the design system for the entire organisation.

The ongoing debate about one comprehensive design system has been around for close to a decade. Leaving some parties in discussion that not everything can be automated. Where others are reaching the point of automation between Figma, JSON and a very basic REPO that allows the Front-end Engineering team to convert a JSON file to a working CSS style, in other words, it impacts the E2E workflow without human intervention.  

So what shall we measure, you might kindly ask?

• Is it the time saved?
• Is it money saved?
• Is it money spent?
• Is it allocation or resourcing that has been added or reduced?
• Is it the reusability of components?
• Is it increased accessibility?
• Is it a smooth integration from the business idea to the final code?
• Oh, is it a learning, knowledge, transparency or improvement of the company culture?

Since McKenzie's model states that everything in a business can be measured, all the above questions might be relevant to you or to your business. If the time to market is something that you value the most, the quality of the design system does not play a role.

If you, however, are trying to create an ultimate production line between an idea and the code and minimising the bridge that design creates, you can start measuring and shortening the time every single time you deploy a simple increment, leaving you and your designer in the process of constant optimisation.

You might consider the design system as the ultimate bridge of your organisation's common language, the source of truth, or an intellectual property that your business must protect at all costs.

These three examples give you guidance for what to measure at what time in order to achieve your primary objective. In the following series, we examine specific topics related to value creation, value proposition, and key performance indicators for a design system, an integrated design proposition.

For more information, please visit Designa at Scale™ – GRID Magazine, where you can find additional relevant articles that explore high-performing teams, self-organising teams of 001, teams of 010, and teams of 100 that deliver the value proposition within a product-led environment.