I’ve been involved in design systems long enough to see it evolve from an auxiliary asset (“we made a quick design system to help us be more organized”) to a full-fledged part of an organization (“I work on a design system team full-time”). As design systems and dedicated design system teams become more prevalent and official, we need more support structures to help people evaluate and grow. One of the most popular tools for that is a career ladder that articulates leveling, areas that have little if any standardization for design system teams. Let’s change that!
I like how Doordash’s Head of Design Helena Seo describes a team member’s career needs in her article, “Designing” a Career Ladder for Product Design:
I want to understand where I stand currently. I want to know what I need to do to get to the next level.
Those expectations are usually opaque for a design system professional. Fortunately, there are lots of good models and examples to pull from in adjacent spaces. Design system roles often sit squarely between design, engineering, and product roles. While it’s not exactly right to use them verbatim, they can provide great starting points for remixing.
We need to define the criteria that all roles must adhere to, regardless of seniority. The criteria in the Design Team Levels Framework that Peter Merholz originally created for Snagajob is a great starting point:
I added a few things to Peter’s format.
First: levels. I love how Julie Zhuo describes it in her article, How to Work with Designers:
The more senior the [person], the more abstract the problem they should be solving.
Second: I added 2 columns that say “Looks like” and “Sounds like,” something I learned from Emily Meekins and Wil Reynolds at Seer Interactive. I stole this when creating a handbook for SuperFriends and it really helped to make abstract responsibilities much more tangible. For example, a responsibility in “Cross-functional Meetings” for a Senior (Level 3) person might be “Active planner of the meeting.” That could look like “creates meeting agenda with defined desired outcomes and distributes an agenda to all participants 24-hours before the meeting.” That could sound like, “I took the liberty of drafting an agenda for Thursday’s meeting. You can find it attached to this email.”
All of those things have resulted in this Google Sheet starting template. The details aren’t filled in yet, but I’m pretty happy with the structure.
How does this get filled in? I’m glad you asked! I’m facilitating the next Study Hall in the Design System University community around this topic specifically on Wednesday, September 13 at 12pm Eastern. We’ll be workshopping what jobs people do, don’t, should, and shouldn’t have in design systems. Join in and help me shape what design system responsibilities look in our industry! (This event is exclusive to Design System University members, so enroll to attend.)
I’m also going to be sharing some of my own lessons around design system roles and responsibilities at DSW Day on September 20, a free event for the design system community organized by Maria Eguiluz. RSVP to attend.
I consulted many books and resources that helped me develop my own thoughts and opinions on this topic. In no particular order:
Books I haven’t read but are on their way to my house as we speak so I can read them:
Join 30,200+ subscribers to the weekly Dan Mall Teaches newsletter. I promise to keep my communication light and valuable!