Be ready to accept design system help

A cross-team design system can only flourish if people from outside the systems team are properly equipped to participate and contribute to the system.

These contributions can take different formats: suggestions, feedback, bug reports, proposals for new components, etc. — and you should be ready for them as soon as you kickstart your design system.

Be ready from the start

I’ve never heard of a design system team that isn’t strapped for time, so my guess is that if people from outside the team have the time and disposition to contribute, you better be ready for them.

Start planning for this from the beginning — don’t wait until you have all the components and all the documentation “done” to accept help.

If someone comes to you and tells you they can help — they may have a slower week, have some spare time, or there’s a specific thing in the system they need very soon and are keen to help with — you should be ready and not say “let me get back to you on that”.

Not just design and code

Remember that contributing doesn’t just mean providing final design specs and coded components. It can mean other things, such as:

  • Improving and reviewing documentation
  • Testing components in real life and submitting feedback and bug reports
  • Gathering information for further design work (for example: how are people using tabs right now, which use cases does the system have to account for, etc.)
  • Explore different design directions for a specific component
  • And so much more!

“Start here”

Many open source repos include the labels “good first issue” and “help needed”. These are excellent indicators that make external contributors confident that they are following the right steps to help.

“help wanted” and “good first issue” labels in Airbnb’s React repo.

Different levels of commitment

Consider the amount of time someone has to spare, and triage your work items accordingly.

Triaged issues in the Kubernetes community content repo.

I’ve seen open source GitHub repos where open tickets have difficulty level or time estimate labels, which makes it super easy for contributors to know what’s the best issue to work on.

If someone has a free morning, you don’t want them to focus on a task that may take one week to complete. If they have one available day every week, you could potentially hand them over a task that is not time sensitive, but that may take 2 or 3 days to complete.

Spending time carefully triaging your tickets will mean contributors can pick up an issue that they know they can finish.

Where to get started

If you are going to evaluate contributions based on certain requirements, then write the requirements down and share them with everyone. It’s only fair that, if someone is going to spend time helping you, they know how their work will be reviewed. Consider documenting:

  • Getting started information: everything you need to set up the development environment, design tools, access to projects, etc.
  • Documentation process: how to edit documentation, writing style guide
  • Coding guidelines: standards, browser support, accessibility checklists
  • Where to get help: if someone gets stuck and needs to ask a question, who and where can they go to

As you receive contributions that are missing things or don’t pass your tests, remember to update your contribution documentation to avoid further similar issues.

Being a good citizen

As for any online and offline community where people will interact with each other, you should have a code of conduct in place that can be enforced. What kind of behaviour will you not tolerate? Who can people go to if there’s a problem? And what are the steps you will take if something goes wrong? Think about all of these in advance, so that you know what to do if someone breaks the rules.

Iterate, iterate, iterate

Just as you would for a component, if a process isn’t working, make it better.

As more and more people contribute to your system, you’ll start to hear feedback that you should act on to make the steps easier.

Are people having trouble finding your documentation, or understanding them? Do they keep asking the same question? Do proposals consistently break some of your design guidelines? Do proposals lack refinement or consideration of a variety of scenarios? These are likely not the fault of those contributing, but rather an opportunity for you to improve documentation and communication with people outside of the design system team. Be more vocal and more transparent about your processes, present work in progress, describe your process and how you get to what your team considers a good, complete proposal.

A good way to keep improving your processes is to maintain a regular cadence of retrospective meetings, where participants from different areas (designers, PMs, engineers, etc.) can voice what they feel went well and what could be improved in the past few weeks. This is sadly a step that is often skipped when working in sprints, but, when done well, is key for working better together.

You won’t fix all the issues in a day (or even in one sprint), but the more you advocate for good design, good code, and collaboration, and the more contributions you accept, the better they will be.