By R2 in Design systems — Jul 4, 2022

Design system contribution retrospective

If you set up inbound contribution model in the org, and your design system accepts changes from outside the home team, running a retrospective on such episodes is a great way to improve the process and support other teams.

Meeting

The format of the meeting that I found working pretty well is that of a post-mortem analysis (PMA): reconstruct a timeline, note key decisions that were made along the way, and map causes and effects. But, unlike PMA, retrospective on a contribution is about a positive thing, so it should feel pretty good being there. Plus, a bonus side-effect: people who are a bit far from ops, like designers and UI engineers, get to practice the format.

Timeline

The timeline is all about decisions that were made during the time the group was working on the inbound contribution.

Tools

I found that representing a timeline visually is more pleasant and effective, and probably leverages the spatial thinking that designers and UI engineers end up developing pretty well as part of their job.

My tool of choice is Miro, although FigJam or Excalidraw could work just fine. For example:

The timeline: most sticky notes are events; orange ones are key decisions, and gray ones are just notes.

Use different ways to represent points in time when

a key decision was made
a decision could not be made, because there was no input, not precedent, no guidance for the design system
a change was made in the design system (there’s gonna be many small changes)
someone got stuck or blocked by something else

It’s pretty hard to come up with a universal format for representing the timeline, and I’ve personally never had this goal in mind. Your approach is probably gonna be different and will develop over time through experimentation and feedback. Give it some time and iteration.

Moderating the conversation

You can either nominate a moderator or do it yourself. There’s a few rules that you want the group to follow.

Focus on events

Pay close attention to the events and decisions, not people. If someone made a bad choice, they probably did it because one or more inputs were missing. If someone made a good choice, they probably did it because the corpus of information was good. As the group reconstructs the timeline, these inputs should become apparent.

Lead abstract towards concrete

People in retrospectives tend to talk abstract, like “Contribution process could have been better” or “We have achieved our goal”. You’ll notice that such statements don’t sit well on a timeline, and that’s because they’re not about events or decisions. If you want to keep them, move them to the end of the timeline, pointing out that those summarize the experience, but can’t be attached to a specific point in time.

Encourage people to talk in facts and evidence

There’s a lot of sources of data: bug tracker, source control history, documentation. The contribution itself probably started from a meeting, or a charter doc, or a file in Figma, or, in its simplest form, a chat thread. Whenever you see the group hesitating to pinpoint what inputs led to a certain decision, encourage one of the people in the group to take a few minutes off the conversation and look into information that’s been captured during the contribution, and bring back the information to the group that’s possible to put on the timeline.

Closure

The group will expect something from the retrospective, — there should be a clear next step. Not like “let’s go back to work and do the next two-week sprint”, but a commitment to improve the contribution process (and avoid some mistakes in future), and or support the product team next time they decide to contribute to the design system.

What makes the design system contribution retrospective different from, say, sprint retro, is that the lessons learned can be replicated across the entire organisation. In a lot of cases, you’ll find yourself writing down the findings and seeing that they can be useful to a lot of other product teams that might eventually approach the home team with an idea of a contribution.

I’m not sure if there exists a universal format for distributing this kind of knowledge, but there’s a line between sharing valuable knowledge and spamming product teams with irrelevant stuff while they’re busy dealing with their roadmap. A communication plan should help.

How to support the group as a leader

If you lead the home team, there are three things you could do to support them with the contribution retrospectives:

giving time to actually do the retrospective
keeping the format intact and focused on improvement
being an advocate for the contribution process

The home team probably has much more work than they can comfortably handle, and scheduling a retrospective is rarely top of mind for them. Best case, the design system folks should have this part of the job on the list of role expectations, so take care of that when staffing the team.

Keep the format intact. Don’t let people slide into the four Ls, or Glad/Mad/sad, or start/stop/continue, — these formats, while good for quick retros, aren’t good enough for deep-debugging a process. There should be clear analysis and synthesis phases, and you will sometimes need to pull the group out of abstract talk.

Finally, advocate for the continuous improvement. Yes, another meeting, sure, people are busy. But if we’re talking about a division of, say, 7 teams, that’s seven times the potential loss of productivity, due to a missed opportunity to learn and replicate the lessons, if the team skips the retrospectives. Keeping it all alive will require building a bit of hype around that, which you shouldn’t overdo, but I noticed that some extra encouragement can go a long way. Talk to people’s managers and tell them the retrospective was a success. Talk to people themselves and encourage them to come back next time. And ask for feedback on the meeting structure and format.

Looking back and reflecting on things is a powerful tool, but it’s tricky to implement when it’s supposed to be done by a group of people who work in two completely different contexts: design systems and digital product development. With a little bit of effort and diligence, you can make it part of the collaborative work. Let me know on Twitter what you’ve tried, what worked, and what failed spectacularly. Talk soon!