Design System Triage #3: February 2023

Dan Donald, Design Advocate

February 14, 2023

Each Triage session has a different vibe, as we have a different collection of people on the calls. You can read up about the first sessions we ran late last year to get a feel for how they’ve gone so far. The premise is pretty simple: Ben (from Sparkbox) and I arrange a call that’s an open invite for anyone to attend; we all jump onto a FigJam board, vote on topics to discuss, and attach notes to a topic board for discussion. Attendees are welcome to join over video during the call to share their experiences or propose their own solutions to issues people may be experiencing. We don’t record the sessions so that people feel free to share during the calls.

In this session, we not only moved over to Demio for the event but ventured into the familiar territory of design tokens and exploring what value means & measuring success can look like.

Design tokens

The great thing about revisiting a topic we may’ve already covered is that over time, there’s great thinking shared around the community, continually pushing things forward, and people just discovering the topic.

One discussion was around ownership and maintenance of tokens: should this rest with the designers or developers? Yeah, you know, I’m going to say ‘it depends’ – I think it very much depends on the org and team structure as much as the level of design or tech maturity. For me, tokens should be a point of convergence that bring people together, so something a multidisciplinary team would own together regardless of discipline…but that may be too idealistic for some teams!

There was some anxiety in there about having to get things right from the beginning, which is understandable. I don’t think this is unique to design tokens and is something hard but essential to factor into design systems in general: how to allow your system to evolve and change over time. You likely won’t get the perfect tokens structure and naming convention right away, so need to assume it’ll change. We can accept this as potential debt, should it happen, and try to get a sense of how much effort any change might take. Considering how to migrate between the current set-up and any new structure, while not a fully featured plan, gives a sense of a migration path, which can help mitigate any risk that structural change might bring.

An interesting observation that I’ve grappled with myself is how to deal with native apps (which feels like a blog post of its own!). Should values be stored alongside those aimed at the web? Should the values be transformed into something else through a process like Style Dictionary? Is it better to keep tokens describing design decisions for native apps in a different design system altogether, as deployment is very different from that for websites? While there weren’t any conclusions, I’m fascinated by the various ways in which people might approach this!

Some suggested resources by attendees:

Proving value & measuring success

While tokens feel relatively tangible, the concepts of value and metrics are less so. Spoke initial thoughts from the board:

“It’s hard to measure for us (1000+ UX designers). We try to measure “hours saved” in money.”
“How do you measure the success of a DS in pure $ value?”
“How do you measure which component is successful and which ones to remove or needs improvement?”
“What types of KPIs do you set up to prove the business value?”
“How do we prove value to stakeholders? Design Systems are a massive effort. We only have a handful of designers. Which baselines? Which metrics?”

Terms like ‘value’ and ‘success’ feel incredibly subjective to me, which feels like no wonder it’s a difficult space for people to deal with. When we talk of stakeholders, what stakeholders are there? Are they few or many? Are they well informed about design systems or not? It also relates to how the design system started as a project; was it self-initiated by an individual or team or proposed by leadership? When we consider value, first of all, we could go with some basics like speed and consistency. To define whether we’ve made anything faster, we need some benchmark data. Not all work is of the same size or complexity, so establishing this baseline feels like a non-exact science. Do we measure this more qualitatively through surveys with colleagues that consume from the design system? It may be that if product teams feel they’re able to work faster, that might be a satisfying enough measure for those involved.

Looking at adoption feels uneasy, too: what does ‘ultimate adoption’ look like in your organization? Would everything derived from the design system be the goal? Allowing designers and developers the flexibility to solve the problems for their end users in the right way may end up with some components that have single use cases. This means that 100% adoption may not be possible or certainly not desirable…so establishing an adoption metric needs more nuance. Do you look at the more foundational level and suggest almost everything should use the foundational aspects such as colors and typography?

There were some suggestions on the board, such as:

Reduction of rework or time spent in QA
Increased satisfaction for users of the design system
User qualitative metrics measured from start to progress
“I’ve heard that a good practice is to run usability questionnaires with users before and after the implementation of the design system.”

As Ben said during the session: “if you can figure out and understand what the value is and why everyone would be excited with the success of this system. If you can articulate that, there is probably a way to find a solution. It does require a lot of courage to sit down with folks and ask them that, as they might not be convinced by your DS.”

I think the cultural value is an interesting thing to think about. Can DS projects help us figure out what we value as an organization…the word “value” conjures up “value system” to me, which is by no means universal. Interrogating the assumptions that made you feel like you needed to measure certain things and not others is illuminating and feels good and grounding.

After the session, it was really rewarding to hear that so many participants felt they got value from it. So long as that’s the case, we’ll keep running them! Every time, it feels that we learn so much from people that come along and join the calls. Even very similar-sounding setups can unfold very differently and experience different challenges.

Dan Donald, Design Advocate

Dan is a Design Advocate @ zeroheight. When not bounding up and down excitedly about design systems, he makes loud shouty music like he never stopped being a teenager