Breaking Down Design System Effort by Week

Breaking Down Design System Effort by Week

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.

No alt text provided for this image

Here’s how that would break down across the 4 separate roles.

No alt text provided for this image

Here’s a breakdown of work to be done each week.

No alt text provided for this image

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.

No alt text provided for this image

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.

Angie Badillo

Fluent @ Microsoft Design

1 年

"The more natural pairing for design system product work is Engineer + DesignOps" This is an interesting insight that I haven't thought about but it makes sense as someone who wears multiple hats in the team. Thank you for explicitly calling this out!

Emrah Kara

Product Designer | Strategic Contributor in Shaping TransferGo's Future | Design Systems Engineer | AI Enthusiast

1 年

This is really insightful, Dan Mall. Comparing to the design system projects that I involved in the past, I must admit that this looks like a near-perfect approach. It would’ve been nice if I had a design ops person and a writer. Most of the time, I had to undertake the design evangelist role on top of being a maker. Content writing has also remained as an overlooked aspect in most projects. I like how you demonstrated the work allocation across people. This is something I should keep in mind for future.

CHESTER SWANSON SR.

Next Trend Realty LLC./wwwHar.com/Chester-Swanson/agent_cbswan

1 年

Thanks for Sharing.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了