How Do I? Practice Cards Activity

Prioritize Processes Your Design System Needs


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.

The Activity


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.

Group Size, by Table

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.

Photo of four stacks of cards
Stacks of “How do I…?” questions by group (System Team, Adopter, Contributor, and Leader)


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.

Photo of printable sheet cut up into cards
Practice “How Do I…?” cards cut up from letter size prints from a template

Prioritize Urgency as Columns

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”, 0.1, 1.0, and “Later”).

Prioritize Depth & Formality as Rows

Just as important as timing is how deep and to what quality your process is documented and explained.

Photo of post it notes arranged to create a grid of milestones versus documentation detail levels
The activity table set up, ready for “How Do I…?” cards to be placed.


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.

Photo of cards placed in a grid of milestones versus documentation levels of detail
“How do I…?” practice cards prioritized part way through the activity, organized by urgency and depth

Resulting Themes

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.

Define System Team Process Now, Yet Skimp on Doc Early

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.

Prep Adopters with Essential Startup & Support Tools

When the 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:

Optimize Repetitive Processes Iteratively

Some processes take shape over time, release by release. A team should find their groove across sprints, reaching a1.0 launch by iteratively refining and documenting repetitive processes like:

Serve Contributors Later, Once the System Forms

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:

Need help with your system?

EightShapes can energize your efforts to coach, workshop, assess or partner with you to design, code, document and manage a system.