The end of a contract and subsequent transition is a plight that’s not in any way unique to design systems. It’s a pain point that contractors of all stripes eventually feel during their contracting careers.
With a nascent design system, this represents a risk: not only will the system potentially sit idle or be forgotten, but the culture change you’ve been trying to effect — a single source of truth, design and engineering working together, a single holistic system instead of siloed parts of a whole — may stop as well. Here are some tips I learned from transition off the Medicare’s Quality Payment Program design system.
Document everything
Documentation takes on another level of importance when it comes time to hand off work to another team. If you’re doing any kind of work that involves discovery, new processes or ideas, document everything, not just the “how this works” of the thing you’ve created. Include the “here’s what we were thinking,” and the “here’s where we wanted to take this.” Make like a journalist and run those 5W’s and an H: who, what, when, where, why, and how. Get a little dreamy, pie-in-the-sky about the future of the design system. You have goals: write them down. Include as much detail as you can.
Check your knowledge gaps
In the best case scenario, you’ve taken the time to check yourself as you worked on your design system. It can be helpful to look at your work as though you’re brand-new to it; it helps you see the gaps in your knowledge and assess any assumptions you’re operating on. Ideally, you’ve worked to backfill gaps and work through assumptions, and those things should be shared. Write down any gaps you’ve found if you haven’t had time to backfill that knowledge; it might be a solid starting point for continued work.
Don’t assume knowledge
When you’re very close to a project, it’s easy to forget that an incoming team might not have the same understanding of words, topics, themes, or concepts that you do. Write down the things that might seem obvious to you. Provide references for tools and dependencies you’ve used. For example, not everyone knows how to set up Webpack (or that there are a thousand ways to do it), so share a link to the resources, or even the exact configurations, you used.
Create a common vocabulary sheet
Semantics are important, as is common vocabulary. A “modal window” might mean something very specific to your team, and something entirely different to another. Providing this kind of documentation can help flatten the learning curve for the next crew. See our previous post on the importance of communication in design systems for more tips.
At the end of the day, if you’ve done the work of documenting everything, you’ll have hopefully set up incoming design system owners and future users for success, even if you’re no longer available to help support the project. To go a step above and beyond, leave some contact information for the incoming team (if your management allows it). A quick answer to even low-level support can help set up the new owners for success.
Read the rest of the Design Systems in Government series: Less can be more, Communication is critical, Improving documentation for better collaboration, and When to start.
