Design System Triage #1

Ben (Callahan, President of Sparkbox) and I got to talking over a few calls and we started to notice what we felt was an unmet need: there are a lot of events or sessions that are talks or interviews (many of them really great) but there is a lot that the community can learn from each other, so how might we do something to help with that?

The idea that we hatched was that the two of us would somehow facilitate an online event for people to share their experiences and issues they’ve come across on their design system journeys. Much as Amy Hupe does with her “Open Spaces” sessions, we opted not to record the sessions to encourage people to share openly. We assumed it’d be relatively small…but ended up with 400 people signing up with 100 joining us on the call!

Using a FigJam board we asked people on the call to vote for topics they have issues with at the moment. Pretty quickly it was clear that this month, contribution was a big topic. We asked for everyone to drop their notes on the board while some explained to the group more about some of their pain points.

There was so much great material to discuss so from each monthly session we run, we’ll collate it into a blog post so we can share back some of the themes that emerged. Here are some of the takeaways that you might find useful.

It depends…

Across the notes and stories we heard, it was evident that there’s a lot of variability in team and org structures that have a direct impact on how contribution might work. There were a few examples of centralized design systems teams that ranged from accepting requests or suggestions, accepting components to be adapted to the system for inclusion to that team effectively making all of the components. That felt really interesting as it can be too easy to lump large, diverse experiences into a bucket, like being in a centralized team.

Each of those scenarios had different challenges that also related to the scope of what that team was responsible for; whether their design was scoped as being within a design tool or included code ready to be consumed by product teams. This landscape of how teams work is a really interesting space and before looking at the systems themselves, shows how impactful structures and workflows can be on everything that comes after.

I think there’s some comfort in knowing that not everyone has this solved. When you’re looking at shape of your team or org structure, there are many ways that these similar forms play out. These stories really served to underline how important they can be too many other factors of your design systems, so worth spending the time on and designing this as much as other, more visual aspects of your system.

Workflows

Given that variety in structures (which was evident beyond centralized teams), there was discussion about how contributions actually play out for people at the moment. Again, there are differences in team composition as well as structure so processes are different. From a design perspective, something like:

• Logic/flow for if/when a new component is needed
• Guidelines to help with the creation of a new component
• A form you can submit if you’d value the help of a DS designer
• Regularly scheduled check-in meetings for updates and questions for the team

…through to a workflow that encapsulated engineering in the process:

• UX team working in Sketch and sharing through InVision
• Added to the JIRA backlog
• Work is pulled into the sprint and allocated story points
• Developers work on the component (in their case using Angular and Sass)
• Released to Storybook
• Functional review by the UX team

As can often be the case, when diving into a topic you can end up with more questions than answers:

• When should a component be added to the design system?
• If components are created by product teams for their user journeys, how many times feel right to be promoted to the system?
• How many variants of a given component feels right?

This link between structure and workflows could (and may in the future) make a session of its own. While oversimplifying design systems as being a bunch of components can make them all seem equal, the way we get to that varies massively and is a really interesting area to learn about.

Maintaining quality

Linked to the example workflows that were discussed was the question about how quality could be preserved through contribution.

• Is there a team or some kind of collective that are reviewers responsible for helping maintain standards?
• How much of making things to design system standards should be the responsibility of contributors?

Where the responsibility for ensuring high-quality output sits and how it plays out is really interesting and could be as simple as design crit sessions through to forms of automated testing for your code. It’s understandable that notions such as this vary quite a lot as it’s dependent on team or org structure and so many other things when it comes to who should ensure quality. It’s something that can very much be a team sport with guidance but with a centralized team, the emphasis may be on them to legitimize work in the system.

Resource shared: Design System Contribution Template by Chad Bergman (Figma)

Why contribute?

There may be times when there are limited skillsets or passion for design systems that can be hard to win round. If adoption is already an issue then clearly contribution might also struggle. The question was raised around whether anyone uses any incentives to encourage participation.

There were a couple of places that use a service as a way of awarding people with points that could be redeemed for money, gift cards, etc.

• Does there need to be some kind of reward?
• Is contributing an altruistic act?

It’s a fair challenge; as people creating a design system we hope that people would want to contribute and help improve it but is there any innate motivation to do so?

Resources shared: Amy Hupe’s talk at Converge this year is a must-watch as her 5 lessons in enabling contribution blog post.

Educating, awareness and advocacy

During the session, it was also touched upon what some of the differences might be between the focus and considerations of product teams and those working on design systems. Mostly this seemed to revolve around “systems thinking.” Is this something that’s easy to teach? Is it something that people that aren’t working on the design system should be conversant in?

Working with the context on a specific layout or user journey, it can be really jarring to step back and consider your solution in the broader shared/global context. There’s a very different mode of thinking that’s needed so is it ever fair for contributors to submit work in the way that the design system and consumers of it actually need? It may be that people don’t often see how their problem might stem from not having a more systematized approach, resulting in an inconsistent UI, poor UX, and long development times, which is where a design system can add real value.

• In various forms, advocacy or some form of regular outreach came up. While this might be seen as a tool to raise awareness or solicit feedback, it can also be a great driver in setting expectations and encouraging contributions.
• Having a visible roadmap that helps with transparency and prioritization can help root contributions in a more tangible process.

—

There was so much great material shared which was amazing to witness. It certainly felt like it could’ve been a half-day session to really get under the hood of parts of this one topic – so a huge thanks to all that participated in this experiment of ours!

While the format was experimental and no doubt some teething problems, it was so great to hear how people were finding their time in design systems and through the sharing and notes on the board, hopefully getting a sense of solidarity and a better understanding of how others are finding problems and solutions around this topic.

Design Systems Triage will be a monthly event. We’ll keep working on the format and hope it grows into something really useful for the community to be able to help each other along their journeys! You can also read Ben’s write-up over on the Sparkbox blog!