There’s a ton of “How Do I…?” questions to consider as you optimize your design system practice. Whether starting a design system practice from scratch _or_ rebooting that practice, teams may put “everything we do” on the table for review.
This is the perfect time to assess processes from a high-level overall and decide the right time and depth to establish or refine each one. I’ll use a “How do I…?” Design System Practice Cards activity to help a team appreciate the range of processes and prioritize what to focus on.
Convene a cross-disciplinary group of at least the core system team to identify and prioritize developing and/or refining processes, resulting in backlog tickets arranged to define and document each one.
Organize “How do I…?” practice cards on a large table by urgency (as columns) and depth and formality required (as rows).
30 to 90 minutes depending on discussion depth and number of groups.
While it works solitary, it functions well with tables of 4 to 6 participants. With 8 participants at a table, conversation may bog down and contributions become uneven. If running 2+ tables, have each table complete the process independently and then present their results to other tables.
Starting from the questions formulated in my Practicing Design Systems article, I’ll use an InDesign template and it’s exported PDF to print sheets of cards tagged by group. I’ll then take a few minutes to slice up each sheet into cards, with a few blanks just in case.
It’s impossible to define, initiate, and refine all system processes at once. Therefore, I’ll arrange Post-It Notes to form columns of time (such as months or quarters of a year) or — my preference — key milestones in rebooting or starting a design system (such as “Now”,
1.0, and “Later”).
Just as important as timing is how deep and to what quality your process is documented and explained.
Read a card aloud, ensure everyone mutually understands it, establish consensus on where it goes, and place it on the table. While one person can read all cards, I suggest teams pass the deck around the table so that each person reads cards and triggers conversation.
Having run the exercise with many groups, I’m always surprised by the distinct value that individuals and groups place on certain tasks. That said, there are patterns to how teams organize process formation.
While certainly biased because it’s my job as a consultant, teams invariably prioritize many System Team cards in the Now, No Doc area, including:
These are table stakes for a high-performing team, and begin to set the stage for how they soon expand operations to include adopters and contributors. However, documentation for team processes will be required as members rotate in, requiring onboarding.
0.1 release become available, early adopters may swarm, trading off negative potential for breaking changes with a spike in efficiencies. Therefore, getting started efficiently is essentially, requiring answers to:
Some processes take shape over time, release by release. A team should find their groove across sprints, reaching a
1.0 launch by iteratively refining and documenting repetitive processes like:
While some systems can emerge organically from a community, I find it more predictable to set a baseline centrally and then gradually open up to contributions over time. Therefore, serving contributors with well-defined processes spans from the
1.0 period and beyond with:
EightShapes can energize your efforts to coach, workshop, assess or partner with you to design, code, document and manage a system.