Design System Subtasks, by Step

Decompose Your Workflow into Checklists


Top-level steps to develop a system feature-from Propose and Design to Code and Doc-are valuable but not enough. Teammates made different assumptions about what's needed to complete a step. High-level definitions-of-done were helpful. Yet, outputs lacked robustness when smaller substeps were completed inconsistently. Team members called for checklists to identify everything expected along the way.

This post introduces Subtasks per Step organized in Phases. Each of four major steps - Propose, Design, Code and Document-are expanded to include detailed subtasks with examples revealing what subtasks are needed when. The post concludes with advice on assignments, tracking and the balance between not enough and too much

Breaking Down Step into Phases, Per Step

Delivering a feature like a component or visual style upgrade progresses through top-level steps like Propose, Design, Code, Doc and Release.

A typical five-step process for delivering a system feature
A typical five-step process for delivering a system feature

There are many activities in each step. So many that they feel unwieldy. So, when creating a process for a team, I'll encourage them to consider subtasks across phases of work, including:

Each step can be broken down into six phases in a typical sequence
Each step can be broken down into six phases in a typical sequence

Different phases require different lengths of time. Phases like START and DELIVER move swiftly. COMPOSE requires many steps, the most work and the most time. TEST, PRESENT, and REVIEW include checks to ensure quality, involve the community, and trigger iteration to ensure things are made well.

Phases aren't all the same duration; START is quick and COMPOSE can be longer
Phases aren't all the same duration; START is quick and COMPOSE can be longer

Each major process step - Propose, Design, Code, Documentation-shares these common phases from start to finish, even if the subtasks vary for each.

All steps have `START`, Compose, Review, and Deliver phases
All steps have `START`, Compose, Review, and Deliver phases

For example, all steps start from a template, even though a Design template is far different than a Documentation authoring template (or is it?). A Design step tests some accessibility and possibly usability, whereas Code delves into more accessibility along with unit, regression, and functional tests.

Substeps per phase per step
Substeps per phase per step

Organizing work with phases, a teams can identify subtasks needed to deliver a robust, high quality feature predictably. The following sections illustrate common subtasks included in Propose, Design, Code and Doc steps.


The Propose step requires a system to consider not a quick component for themselves, but a robust components for everyone. The step is done when a team decides whether to pursue a feature, scopes requirements, and plans the work. As a result, it demands auditing and collaborating with many people.

Propose process

Common Propose Subtasks

List Group Proposal


Item names, vertically stacked
Linked (Linked or unlinked items)
Size (Large, medium or small)
Microcopy (above OR below but not both?)
Pill (trails title as span element)
Icon (on left)


Sublist (indented, L2 small text within L1 medium text, L2 medium text with L1 large text)
Sublist expand/collapse
Sublist expanded (default false)
Selected / active item(s)
Microcopy location (above or below?)
Eyebrow heading (included or separate component? If so, include ARIA connection between header and list below it.)
Badge (for count of items)
Checkbox (for interactively toggling an item)


pill? (for badge)
accordion? (for sublist expand/collapse)

Other Propose Considerations

In contrast to Design, Code, and Doc steps that follow, REVIEW typically precedes PRESENT during the Propose step.


The Design step solves for interface and visual design. It's considered done when a designer delivers a complete design to a developer to code the feature.

Design process

Common Design Subtasks

Outside Participants

Design may require participation others, here from high-to-low priority:

Other Design Considerations

What of Design Assets built into design software like Sketch or Figma? These may require adjustments as Code progresses and be completed later along with Doc. Therefore, some teams separate a Design Assets from the Design step concluding earlier.


The Code step includes setting up an environment, composing and testing thoroughly, and engaging the system team and developer community before merging an approved solution. Community engagement via presentations is rarer but recommended. However, testing and reviews are quite thorough.

Code process

Common Code Subtasks

Outside Participants

Code may require participation others, here from high-to-low priority:

Other Code Considerations

For defects, minimize needed subtasks commensurate with TEST, PRESENT, and REVIEW needed
For defects, minimize needed subtasks commensurate with TEST, PRESENT, and REVIEW needed

Coordinate community engagement in a timely way. If Review API with Dev Community blocks getting started, then move it backward into INTIATE. If feedback is expected to be light, move it forward (into TEST, PRESENT or… just REVIEW it).

Documentation ("Doc")

There's more to documentation than just code's Props, Methods, and Events (which may be completed during Code). There's design guidelines. There's copious examples with meaningful content. There's accessibility notes, for both designers and developers. Producing a robust feature with rigor? For design systems, that means subtasks for documentation too.

Doc process

Common Documentation Subtasks

Outside Participants

Doc may require participation of those outside the system team including:

Assignments, Integration & Tracking

Woah! That's a ton of substeps! So much work is required to be meticulous and robust. How do teams stay on top of it all?

Per Step, Assign a "Main Owner" and Integrate Others

By breaking down steps into subtasks, we can assign different subtasks to different people.

Per Step, Assign a "Main Owner" and Integrate Others
Per Step, Assign a "Main Owner" and Integrate Others

When a new feature Code step is assigned to a system team developer, they'll complete nearly all tasks except reviews. On the other hand, a less seasoned contributing developer outside the system team may complete START and COMPOSE tasks, partner with a system team developer to TEST and PRESENT, and gradually cede REVIEW and DELIVER tasks.

Best: Integrate Tasks in Tools!

I'm really encouraged by teams and tools like Storybook that build many substeps into directly into tools. For example, Dominic Nguyen exposed tooling that blocks merging code until sufficient reviewers, outstanding comments, and other workflows have been completed.

UI checklist for Storybook in Chromatic.com
UI checklist for Storybook in Chromatic.com

The more designer and developer tools integrate these substeps into tools naturally, bringing the workflow into the work, the better. While I may spend considerable time orchestrating data in Jira, my teammates don't. They'd much rather spend time in their own tools, collaborating and running commands to get work done.

Better: Task Management Details

Nevertheless, tools like Jira and Asana exist for a reason. We're currently far from tracking every subtask across every step for every feature. While we can optimize the heaviest step (Code) for things we make the most (UI Components), tooling Propose, Design, and Doc for things like UX patterns, visual style, and others is reach too far for tools today.

Propose story, with subtasks generated and assigned
Propose story, with subtasks generated and assigned

Therefore, teams integrate common, repeatable checklists as subtasks per step into how they use Asana or Jira for design systems. For example, one team I worked with created checklists consistent with their workflow, easily copied into Jira's Create Multiple Subtasks dialog when the time is right (below, for a Propose task).

- Discover requirements, including audits / assignee:"@current" - Obtain input on scope from communities / assignee:"@current" - Document scope and plan / assignee:"@current" - Present in system team critique / assignee:"@current" - Present in design critique / assignee:"@current" - Review by system product owner - Review by system designer - Review by system eveloper - Approve or decline proposal, including feature name / assignee:"@current" - Add, prioritize and assign Jira tasks / assignee:"@current"

Split Subtasks Across Iterations to Not Overwhelm

Kevin Powell and I work together often across different client engagements. He's experienced workflows like these many times, and bristles at a Code step with so many substeps obviously unrealistic to complete in an iteration.

Process phases split across two sprints

Instead, he prefers breaking down all the substeps into smaller chunks. This model directly suggests how to do so, such as START and COMPOSE in one sprint followed by TEST, PRESENT, REVIEW, and DELIVER in the next sprint.

Subtasks per step offer robustness, lead to quality, and generate confidence and trust that the system is a disciplined, focused effort. However, with rigor comes complexity, wider coordination, and overhead. Things can slow down.

As I work with teams, I encourage two things: balance and gradual, incremental growth. It's hard for a team to adapt to all these steps all at once. It's a lot. So take it one step at a time. Use these categories, examples, and practices to norm operations on a practice that suits you best. You'll get there!

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.