Learning

Lessons learnt designing a design system

While I was at Backbase, I had the great opportunity to work on building their mobile design system from scratch. Having previously worked on other system building blocks and component kits, this was a challenge that I embraced wholeheartedly.

Along with this healthy dose of enthusiasm came a whole bunch of questions. Who should be involved? Where do I start? What was the history? Timelines? My head was spinning with questions and the different directions, people and departments that had to come together to make this a success.

We eventually formed a rag tag motley crew of engineers, designers, product owners and a delivery manager to launch what would become the first version of Backbase's mobile design system. Here's a few things that I learnt along the way, which I hope will help you on your journey creating a design system.

Research

The biggest piece of the puzzle when starting a project like this is research. Pairing up with a researcher would be the best option or you could start it yourself if the project doesn't have a research allocation.

Reach out to your customers

A design system helps companies scale their design effort and be more efficient. This means that you'll have many customers. Internally your customers will be your fellow designers, engineers, product owners & managers to name a few. Speak to them to understand their needs and pain points. Empathising with them is best way to ensure you start off on the right foot.

Don't skip this golden opportunity or you'll risk building something that doesn't solve the problems your customers are facing.

Attend their critiques, guild meetings, reach out individually, send out surveys to understand the challenges they're facing and how the system can help solve them. Clarify what you're seeking to learn and explain to them that you're in the early stages of building something to better frame the feedback you receive. Look for critical problems, workflow issues, technical mismatches and flaws in the product or way of working, that your system can help solve.

Don't forget to look inward

If you have access to existing customer feedback, dive into that as well. At Backbase, we had a mature web system and feedback from existing customers (banks that we sold our product & design system to). Sift through that feedback to uncover requests and understand what works and doesn't work. Use this opportunity to not make the same mistakes again! Lastly, if you have an existing internal systems team, reach out to them as well. We uncovered a ton of insights from them —ideas, pain points, deprecations past & scheduled, which we used to inform how we built the new system.

Educate

Don't assume that everyone knows what a design system is, what atomic is, what design tokens are, how to contribute or building according to standards.

Take your team on a journey

In the early stages at Backbase, it became clear there was a knowledge gap and we had to elevate the teams knowledge on the foundations that modern systems are built on. It's important to make everyone feel welcome, acknowledge those gaps and focus on aligning the team. This'll help you move together faster and streamline the efforts of building the system from scratch. Further down the track, this will help ensure consistency in implementation, design and code standards as the system matures and more people start contributing to it.

Clarify contribution model & workflows

As your system grows and gathers momentum, so will the number of participants involved. The more people get involved, the larger and slower the momentum of that system and you slowly end up with more questions around ways of working and contributions.

Explain what contribution is:

A design system contribution is…any proposal, design, code, documentation, or design asset of a new feature, enhancement, or fix completed by someone not on the system core team and released through the system for other people to reuse.

Follow that up with the process of how to make a contribution.

Along the way, establish clear ways of authoring documentation for the system, its patterns and component specification. This is not only key for contributors growing the system, but it also provides a central access point for everyone to learn and educate themselves on the system and its parts.

Keep your workflow simple and straightforward. The goal is to reduce friction publishing useful documentation and component specifications. Add statuses like draft, in review and published (find what works best for your organisation / team) to streamline the publishing process. Lastly, make sure contributors are creating these draft guidelines and presenting them in feedback and review sessions.

Appoint system stewards

Contributing to a design system can be a nerve wracking process even for skilled contributors and there will always be gaps to fill throughout a contributors journey. One the best ways to fill in those gaps is to appoint a steward to help contributors along the way.

Stewards are selfless, knowledgable, attentive and warm people who guide contributors through their work. They help contributors feel welcomed, valued, supported and empowered. Stewards guide contributors and alleviate any anxiety associated with contribution.

You've probably identified stewards in your systems team or are in the process of doing so. Heres a few ways stewards can put their best foot forward:

  1. Lead with conversations instead of pointing to a design system website or contribution guidelines. Ask people what are they trying to achieve, how do they envision helping assisting their goals?
  2. Ask questions around what a contributor is comfortable doing — everyone has different strengths and weaknesses. As a steward, you should assist them in areas they need help on or connect them with people who can help.
  3. Check in regularly and help manage the community so the contributor can focus on the work
  4. Anticipate and fill in gaps (states, dark mode, appropriate tokens, etc...)

Finally, as your system grows and the number of contributors increase, be sure to nurture and mentor others into stewardship.

Communicate

One of the biggest lessons I learnt was the importance of communication. Throughout every stage of your journey, communicate with your customers as much as you can. Its ok to over communicate; its actually better for you as a systems team. Communication can come in many forms, like sending launch emails, posters around the office, company wide slack channels for information or questions, release notes, open office hours or critiques or weekly and quarterly department stand ups.

It's important to establish and maintain a healthy cadence. Doing this will increase the visibility of your system, cement your team as the the go to for all systems related questions and make it easier for people to reach out with questions, feedback, bugs or requests.

Measure

Coded components, UI libraries and documentation are parts of a systems output and shouldn't be confused with a successful outcome.

The real value or success of a system is when your customers start shipping products that use your systems parts.

Therefore, it's critical to establish goals and results to measure the success of your system. Measuring helps you from multiple angles. Depending on what you choose to measure, here's a couple of ways measuring can help guide your system and the team behind it:

  • Feature prioritisation and backlog grooming
  • Understanding adoption rates
  • Identify who, how and when your system is being used
  • Candidate teams for beta testing (if you find that they're updating frequently)
  • Systems team participation & productivity

Start small with some key goals and results to measure and up the ante as your system matures. Connect with business analysts or a data science team if you have one to learn how you could measure better and get more reliable results.