Imagine that you have 12 weeks (roughly 90 days or 3 months) from the start of next month to create a design system from scratch. You’re given a team of a designer, a lead engineer, a writer, and a DesignOps person (all senior level individual contributors), and you’re forecasting what each of their involvements might look throughout.
How would you do it?
(For some of you that I’ve even heard from directly, this isn’t a hypothetical; it’s the exact situation you’re in.)
I’ve worked with teams in this situation many times before, and here’s the average of where we landed. This isn’t broken down by time. It’s more about relative effort week to week. Here are some questions these kinds of views can answer:
- How does group effort change week to week?
- How does individual effort change week to week?
- How does each person’s effort compare to everyone else’s each week?
- Who drives the team each week?
Here’s a look at how the overall team effort waxes and wanes over a 12-week period, using an oversimplified unit of “quantity of tasks” as a reference point.
| Team Effort | |
|---|---|
| Week 1 | 48% |
| Week 2 | 100% |
| Week 3 | 67% |
| Week 4 | 70% |
| Week 5 | 59% |
| Week 6 | 44% |
| Week 7 | 41% |
| Week 8 | 48% |
| Week 9 | 67% |
| Week 10 | 48% |
| Week 11 | 63% |
| Week 12 | 52% |
Here’s how that would break down across the 4 separate roles.
| Engineer | Designer | Writer | DesignOps | |
|---|---|---|---|---|
| Week 1 | 31% | 31% | 15% | 23% |
| Week 2 | 30% | 26% | 15% | 30% |
| Week 3 | 39% | 28% | 11% | 22% |
| Week 4 | 37% | 26% | 16% | 21% |
| Week 5 | 25% | 25% | 19% | 31% |
| Week 6 | 17% | 8% | 17% | 58% |
| Week 7 | 45% | 18% | 18% | 18% |
| Week 8 | 31% | 15% | 23% | 31% |
| Week 9 | 17% | 28% | 17% | 39% |
| Week 10 | 23% | 23% | 23% | 31% |
| Week 11 | 24% | 24% | 24% | 29% |
| Week 12 | 29% | 21% | 21% | 29% |
Here’s a breakdown of work to be done each week.
Week 1
Days 1–7
- Assemble the North Star (1-4)
- Assemble Design and Code Assets for Audit (1-4)
- Create an Influence Map (2-4)
- Collect Feature Teams’ Roadmaps (5–9)
- Identify Existing Paradigms in Design and Code (5-14)
Week 2
Days 8–14
- Collect Feature Teams’ Roadmaps (5–9)
- Identify Existing Paradigms in Design and Code (5-14)
- Identity Emerging and Interesting Paradigms in Design and Code (10–14)
- Interview Potential Design System Customers (7–19)
- Identify Potential Pilot Teams (9)
- Schedule Pilot Product Walkthroughs (9)
- Identify Key Stakeholders and Schedule Interviews (9)
- Visualize Your Technical Ecosystem (10–13)
- Interview End Users (10–22)
- Interview Stakeholders (10–29)
- Conduct Pilot Team Walkthroughs (10–29)
- Create New Design System Repository and Package (14–15)
Week 3
Days 15–21
- Identify Existing Paradigms in Design and Code (5-14)
- Identity Emerging and Interesting Paradigms in Design and Code (10–14)
- Interview Potential Design System Customers (7–19)
- Interview End Users (10–22)
- Interview Stakeholders (10–29)
- Conduct Pilot Team Walkthroughs (10–29)
- Create New Design System Repository and Package (14–15)
- Set Up Public Workshop Environment with Branch Deploys (16-17)
- Teach HTML & CSS to Designers (20)
- Teach Figma to Engineers (21)
Week 4
Days 22–28
- Interview End Users (10–22)
- Interview Stakeholders (10–29)
- Conduct Pilot Team Walkthroughs (10–29)
- Teach Git to Designers (22)
- Teach Storybook to Designers (23)
- Practice Hot Potato (25–26)
- Join Pilot Teams’ Sprint Planning Sessions (26–∞)
- Practice with an Existing Design System (27–28)
Week 5
Days 29–35
- Interview Stakeholders (10–29)
- Conduct Pilot Team Walkthroughs (10–29)
- Join Pilot Teams’ Sprint Planning Sessions (26–∞)
- Conduct a Practice Pilot (29–30)
- Create a Glossary of Shared Vocabulary (31)
- Identify 3 Initial Components to Pilot (32)
Week 6
Days 36–42
- Join Pilot Teams’ Sprint Planning Sessions (26–∞)
- Synthesize Themes & Insights from Stakeholder Interviews (36)
- Send First Stakeholder Update (36)
- Create Design System Coverage Map (36)
- Set Up Slack Channel for Design System Conversation (36)
- Create Reference Website V1 (36–37)
- Create Component Implementation Roadmap (39)
- Propose Collaboration Plan to Pilot Teams (39)
- Abstract Component Through Hot Potato (39–43)
Week 7
Days 43–49
- Join Pilot Teams’ Sprint Planning Sessions (26–∞)
- Abstract Component Through Hot Potato (39–43)
- Share In-Progress Component Abstraction Work with Pilot Teams (44)
- Iterate on Component Through Hot Potato (45–47)
- Chronicle the Process (48–50)
- Issue Pull Request to Contribute Newly Abstracted Component (48-50)
Week 8
Days 50–56
- Join Pilot Teams’ Sprint Planning Sessions (26–∞)
- Chronicle the Process (48–50)
- Issue Pull Request to Contribute Newly Abstracted Component (48-50)
- Usability Test Component with Pilot Teams (52–54)
- Final Iteration on Component (55)
- Send Stakeholder Update (57, weekly)
- Extract 3 Overarching Principles (57)
- Create a List of Potential Design System Names (57)
Week 9
Days 57–63
- Join Pilot Teams’ Sprint Planning Sessions (26–∞)
- Send Stakeholder Update (57, weekly)
- Create Design System Logo v1 (58)
- Add “Design System Office Hours” to Calendar (58)
- Make Design System Swag (59)
- Send Slack Post about Component #1 (59)
- Host “Systems Week“ (60–65, then monthly)
- Send Design System Name and Logo Finalists to Brand & Legal Team (60–69)
- Repeat Activities 34–40 for Component #2 (60–77)
Week 10
Days 64–70
- Join Pilot Teams’ Sprint Planning Sessions (26–∞)
- Send Stakeholder Update (57, weekly)
- Host “Systems Week“ (60–65, then monthly)
- Repeat Activities 34–40 for Component #2 (60–77)
Week 11
Days 71–77
- Join Pilot Teams’ Sprint Planning Sessions (26–∞)
- Send Stakeholder Update (57, weekly)
- Host “Systems Week“ (60–65, then monthly)
- Repeat Activities 34–40 for Component #2 (60–77)
- Repeat Process for Component #3 (72–89)
Week 12
Days 78–84
- Join Pilot Teams’ Sprint Planning Sessions (26–∞)
- Send Stakeholder Update (57, weekly)
- Host “Systems Week“ (60–65, then monthly)
- Repeat Process for Component #3 (72–89)
- Congrats! Release Design System v.1.0.0
If we average the amount of work each role would have to do across an entire 3-month window, here’s how it would break down.
| Role | Effort |
|---|---|
| Engineer | 57% |
| Designer | 47% |
| Writer | 35% |
| DesignOps | 59% |
A few interesting observations that might be a bit askew from typical expectations:
- The more natural pairing for design system product work is Engineer + DesignOps, surprisingly not Engineer + Designer or Designer + DesignOps.
- Even though Engineer + DesignOps is the most natural pair, each role’s work acts as a counterpoint to the other. For most weeks, when the Engineer’s work is highest, the DesignOps person’s work is lowest, and vice versa. That makes a lot of sense when you think about the fact that design system work is equal parts tactical and operational but not always at the same time.
- Despite being called a design system, the Designer’s work is typically to support the Engineer and drive marketing/branding efforts when it’s time to socialize and/or broaden the design system reach.
This is the kind of deep work and analysis we’ll be exploring more of in my newest program at Design System University called Design System in 90 Days. It’s a live cohort where I’ll teach you and your team every week for 12-weeks how to get a design system up and running—and adopted!—by the end of the year. Registration opens Monday, August 21 at 10am Eastern.
Were you surprised by any of the observations here? How closely does this match—or not—your design system experience? Reply and let me know.
Read Next
The Rest is History
Join 50,100+ subscribers to the weekly Dan Mall Teaches newsletter. I promise to keep my communication light and valuable!