Design Systems: Your questions answered

What pain points do you help clients address with the implementation of a Design System? 

Our teams help in a variety of areas. Firstly, in the creation of the initial system, working closely with internal and external stakeholders to provide research and testing support, building repeatable models for research, and, where needed, even creating the initial business case to help secure funding for the project. 

For more established Design Systems, we work to create alignment between the various teams involved, developing processes and tools for governance and product management. We can create internal communications and stakeholder engagement assets to help with the promotion of the Design System, and offer training for internal users and external partners.

How do you support clients to measure the success of their Design Systems? 

We work with our clients to define KPIs across a range of areas keeping the focus on outcomes, not just delivery. 

We look at quality metrics such as speed of implementing new features, building sites, accessibility, adoption and time/money saved. These are as well as the more obvious technical benefits such as reductions in development time, loading times, bug tickets, and others. 

We help clients to document their desired outcomes and then create KPIs that will encourage them to keep them front of mind for decision making. This keeps everyone aligned to a shared goal and vision, and ensures that we don’t end up wasting time endlessly tweaking the system components in ways the customer may never even notice. 

What do you think are the core skill sets needed to set up a Design System?

For the initial set up work, we would expect to see a focus on user research, UX, design, BA (Business Analysis) and QA (Quality Assurance), as well as design operations to ensure that there is a healthy focus on creating solid, reusable components that are ready to be tested with customers and internal teams. 

We recommend having a development team involved as early as possible, creating the components in code and building prototypes that can be shared with stakeholders and tested with customers. Fostering and maintaining a good, close knit working relationship between design and development teams will be helpful. 

The team will need to be organised and very focused on the desired outcomes, ensuring that they don’t get distracted from the work required to get a great baseline system in place, without creating huge amounts of technical debt that needs to be addressed at a later stage. A flexible approach is best, with the ability to flip between ‘net new’ feature design, refinement and innovation. 

Net new definition: ‘net new’ refers to any features that do not already exist in some form of implementation. These features would have completely new functionality, rather than being an evolved or enhanced version of an existing feature. 

What do you see as the common reasons why Design Systems don't get used correctly?

In our experience, the most common reasons are: 

• Lack of alignment between internal and external teams, e.g. Design, Development, Product
• Overcomplicating the governance process or not showing progress often enough can lead to teams disengaging and “going rogue”
• Lack of internal comms and training can mean teams either do not know how to use the design system or do not know it exists
• Changes in senior leadership which create opportunities for off-platform or “one off” projects that live outside the system
• Belief from internal stakeholders that they have “special” or “unique” needs which cannot be accommodated by the design system — most often this is through a lack of understanding rather than any real issue or limitation.

How do you help teams to manage the balance of consistency and creativity?

We usually begin by agreeing a set of guiding principles for the product that we can refer back to throughout the development of the design system. This helps with managing the balance between the need to create an easily scalable and inexpensive-to-maintain design system with the need for design teams to flex their creative muscles. 

Setting up multiple parallel tracks to cover ‘Business as Usual’ (BAU), new feature design and innovation can also be helpful, as you can then rotate designers and developers between these areas. You’ll ensure that everyone takes a turn on the optimisation-based work, as well as the more exciting feature development and “net new” design work.

For internal stakeholders and their creative teams and agencies, managing this balance is essential. A common objection to using the design system will be that it doesn’t work for their specific needs — usually due to very specific branding based concerns that don’t really provide additional value for the users. This is why early involvement and alignment from key players is crucial.

What standards and governance do you typically employ across Design Systems?

At a basic level we recommend standards around accessibility, designing for mobile devices and any bespoke standards for the organisation based on their guiding principles. 

We’d also recommend having a regular user testing programme to ensure that new features are fit for purpose, actually valuable to customers and perform well from a UX perspective. 

In terms of governance around new additions to the design system, this is essential in order to ensure that if users of the design system can’t find a component that they need, or they have questions or concerns, they don’t end up going rogue and creating new components that end up just being used one time and not maintained as part of the design system and ultimately the code base.

Balance is key — be approachable, but firm on process, and you’ll go far. 

What are your thoughts around the team needed to support a Design System?

Broadly speaking the team required to support a design system would be:

• Design, Design Ops: with the ability to split into multiple streams including BAU, new feature development, innovation projects etc 
• Development, Dev Ops, Quality Assurance: responsible for developing new features and implementing changes that arise through ongoing development of existing components
• Product Management or Business Analyst 
• Researcher: having a researcher on board in a part-time capacity to create and run user test is usually enough 
• Senior Stakeholder or Sponsor: needed to secure the budget and resources required to continue development, and have representation in senior conversations within the organisation. 

If clients don’t have all of the above teams in place, this is not a problem. We work with them to assign responsibility across teams and departments, ensuring that the internal structure needed to succeed is always in place, and to keep everyone aligned to the same goal. 

How do you communicate changes to the design system? Is everything versioned?

When versioning design work we primarily use a combination of ZeroHeight and either Figma, or Abstract + Sketch to create numbered or named releases. We would usually also prepare some release notes alongside the new components to enhance understanding, and publish it at the point when the components become available for use in the CMS and other design files. 

Where possible, having a close alignment between when the design system updates are made and when the new components are actually available to use by teams is important. We also recommend making your roadmap public to manage expectations. 

What role do leadership teams for our clients play in ensuring adoption of a design system?

The key role that leadership teams play in ensuring the long-term success of the project are around: 

• Helping the business to understand the benefits of the design system
• Securing funding and resource for further development
• Defining project KPIs and keeping focus aligned to these throughout 
• Conveying the importance of customer research and ongoing improvement to the design system after the 1.0 release
• Assisting with integration into the overall business processes and ways of working outside of the core team
• Influencing and providing a voice in senior strategic conversations
• Sharing great case studies across the business and demonstrating the value 

What are your thoughts on community-led Design Systems? Is that something you have supported before?

Governance is absolutely key if you are to open up a design system to a wider audience, whether the community at large or a community within your organisation and its partners.

You really do need to have the governance process locked down in advance of doing this in order to avoid getting hundreds of feature and component requests that would add little to no value to the overall product and only be applicable for the very specific use case in question. 

Depending on how this is handled there is a risk of design by committee and lack of direction. If you are to take this approach, structure will be key. 

 

Design systems allow you to create solutions that are scalable and can be seamlessly rolled out across multiple digital platforms and products. They provide brand consistency and accelerate growth.

Learn more about Design Systems

Want to learn more about how they can help your organisation? Get in touch today to discuss your project.