Code analytics

• Custom-built scripts
• Github
• Gitlab
• zeroheight
• Omlet

Website analytics

• Google Analytics
• Amplitude
• zeroheight

Research tools

• Maze
• Google Forms
• Typeform

DSM

• zeroheight

Communication tools

• Slack
• Microsoft Teams

Accessibility

• Axe
• Lighthouse

Data tools

• Datadog
• Power BI
• Qualtrics

Product Management tools

• JIRA

Design tools

• Figma

🔍

Tooling for measurement is incredibly fractured

Aside from Figma, there are no standout individual tools, and it seems a lot of tooling is custom, requiring teams to know what they want to measure, and actively maintain it. However, there are some inroads being made, with folks starting to use inbuilt analytics in DSMs, and specific tooling like Omlet. However, a lot of teams are still relying on manual qualitative measures. While this is a good thing, we anticipate that this space will grow over the coming years.

🔍

Design tokens are here to stay

Design tokens have gone from 56% in 2024 to 84% this year, which shows that design tokens are at a point of mass adoption in design systems.

💡

UI Patterns are still less prevalent than they should be

Only 64% of teams include UI Patterns in their documentation. As the most opinionated pieces of a design system, this is mildly concerning.

These are the markers of high trust

Strong foundation in collaboration

Collaboration was a common marker of high trust, with product, engineering, and design feeling involved and valued around their needs, contribution, and insight.

Stability at the core

A lot of the more mature teams suggested that a well-cultivated sense of stability and robustness in the system, built over years, is one of the key factors in their system having high trust.

Responsiveness and a culture of improvement

Teams that are open to feedback and then action the feedback with regular updates and optimization are also more likely to have higher levels of trust.

“The design system is not just a tool but a dynamic resource that adapts to the changing requirements of the organization.”

These are the markers of low trust

Dealing with legacy

One common theme in systems with low trust was having components that are inconsistent or outdated, usually because of legacy. While this is a reality a lot of teams face, it's also something that should be actively worked on to avoid low trust.

Insufficient resource

Unsurprisingly, a very common theme with low trust was a lack of people and time, coupled with a lack of 'buy-in' from leadership. Lack of resource often ends with ruthless prioritization and important elements like accessibility or documentation being left to rot.

Lack of communication that leads to lackof adoption

Another area, often combined with lack of resource, is lack of attention to communication, resulting in teams deviating from the system and a lack of awareness about what the design system offers.

👍 Successes

Focusing on long-term strategy

Recognizing that design systems aren’t a one-off project and that you need to establish a strategy that goes beyond this quarter or year.

Focus on adoption and engagement

Having a clear focus on adoption and engagement across the organization, with clear steps for communication and what’s being released.

Performance metrics and continuous improvement

Measurement has never been more important for design systems. Focusing on performance metrics and effective feedback loops leads to more trusted systems.

Managing expectations and deliverables

Another key success has been effective product management practices – setting expectations and effective communication are key to success.

👎 Challenges

Aligning with company goals

One of the most significant hurdles is aligning with the broader company goals, especially when goals and OKRs are focused on product and go-to-market teams.

Organizational changes

Frequent restructuring, shifting priorities and changing company strategies have been huge headwinds for teams when setting an effective strategy for the design system.

Having the time to focus on strategy

Unsurprisingly, resource constraints are a very common complaint when it comes to creating an effective strategy. If you don’t have enough people to do the work, you will not have the time and space to zoom out.

A culture of resistance

Sometimes, overcoming embedded practices and habits within the product organization can be difficult, and this can prevent the implementation of an effective strategy.

🔍

Securing buy-in for design systems is a challenge

While just under 50% are satisfied with their ability to get buy-in, there are still over half of the respondents who find buy-in a challenge. The common themes all seem to revolve around a lack of understanding and perceived value in senior leadership, competing priorities with the rest of the product org, and communication gaps in communicating the value of the design system to the wider organization.

“The team spent a lot of time on promoting a design system and we secured buy-in for the design system from the executive levels. Once we got buy-in from them, it was a bit easier to promote the design system.”

Team makeup

Dedicated design system teams

Hybrid model

While a dedicated design system team was as prevalent as other teams, the use of a ‘hybrid’ model seems to be more common in well-established, adopted system teams.

Stability and trust

High trust in their system

High stability in their system

Well-adopted systems have fostered a feeling of trust in their system, as well as building something that is viewed as ‘stable’

Buy-in from leadership

Ability to get stakeholder buy-in

One big correlation is that well-adopted systems are satisfied with their ability to get stakeholder buy-in. However, is this a chicken-and-egg situation?

Communications

Satisfaction with communication

Another big correlation is satisfaction with communication. This matches with many reported problems in non-adopted systems as well, as communication is one of the biggest challenges.

AI usage

Useage of AI in their design system team

It’s probably still too early to tell, but one interesting trend is that well-adopted teams are actively using AI less than other teams (4%), with fewer also experimenting with AI. Do we need AI to have well-adopted design systems? Possibly not…

💡

Why do a third of companies restrict contribution?

A third of the respondents either only allow contribution from members of their design system team, or specific people on product teams. Restricting contribution to your design system could be seen as authoritarian or like an ‘ivory tower.’ At the same time, having a poorly thought-out or documented contribution model could also lead to a lack of trust in the system and subpar contributions.

Communication

For folks that have a contribution model, communication is a key issue. How do you effectively communicate your contribution model and it’s importance in a way that product teams understand and respect?

“It is simple enough, but not widely communicated or taken up – it’s mostly a communication issue.”

Integration

At a deeper level, there are common issues with integration of the design system with the product org. A lack of respect and integration means that the design system work ends up siloedand ignored.

“Engineers do whatever they want. We don’t have clear processes to stop them doing that, but when we do, they complain they get blocked by those processes.”

Time & resource

Underpinning this is our favourite challenge with design system – having enough people and time to make a significant impact. Both having time to establish a contribution model, having time to communicate it effectively, and the product team having enough time to actually contribute.

“Because teams prioritise shipping features, they want to use what already exists rather than spend time adding to it.”

💡

Something doesn’t add up with our satisfaction with communication

Interestingly, a common frustration through all the responses has pointed to communication being a major issue with respondents. At the same time, the rate of dissatisfaction on this particular question doesn’t match. It points towards communication being an under appreciated area in design systems, despite it being extremely important to gaining high adoption.

💡

“Build it and they will come” is not a good communication strategy

Documentation is important. However, documentation alone is only going to get you so far. Far too few teams are focusing on in-person training and other education opportunities to communicate progress and educate about the value of your design system!

💡

Is basic governance enough?

With relatively low dissatisfaction rates with your governance practices, we looked into the reasons why, and a common theme was having light, basic governance. This tracks with the conversations we have with customers, where figuring out your ‘just enough’ level of governance is the happy place for effectiveness and widespread adoption of governance models.

💡

Why are we only syncing tokens from design to code?

One of the major promises of design tokens is that we will have a way to effectively keep our design decisions in sync between design and code. However, those design decisions aren’t only made in the design tool… Wouldn’t it be valuable to have a way to centrally manage tokens that can push and pull to both design and code, with the appropriate levels of governance to make it so?

💡

Tokens are the one area we all seem to be quite satisfied

While there’s always room for improvement, tokens seem to be the one area where we’ve seen the value realized relatively early on. Teams talk about the improved consistency and collaboration, and having a shared language to talk about design decisions via tokens, as well as the ease of streamlining the processes via automation. However, there is a point to call out on the dissatisfied few, as some teams are getting to a level of maturity where token architecture is growing in complexity and surfacing problems when new needs arise.