Laying an organizational foundation

As a consultant focused on the org design of design orgs, I work across a variety of contexts—established businesses (banks, retail); software as a service (enterprise software); scale-ups (pre-IPO and growing); start-ups. And repeatedly over the past couple of years, I’ve found myself drawing some variation of the following generic digital product design org chart (click/tap for full size).

Generic digital design organization chart

Let’s look at the various bits.

VP Design. A true executive role, with budgetary and headcount authority, often reporting to an SVP of Product Management (and occasionally to an even more senior executive overseeing all product development, including engineering).

BUSINESS AREA. We’ll further explore this concept later, but for now, the idea is that there are design teams, lead by Design Directors, dedicated to some discrete business goal (in a marketplace model, one Business Area would be the seller side, and the other would be buyer side; in enterprise software, one business area may be Applications, the other Platform). 

Design Director (and below). Each team has between 10-25 designers, lead by a Design Director, supported by some number of Design Managers (this example is generous, with a manager for every 4 designers; usually it’s closer to 7 or 8 designers). The Design Managers are responsible for an aspect of that Business area. So, if this were marketplace model, and Business Area A were the Buyer side, each manager is responsible for a stage in the Buyer journey, in this case it could be Research and Discover, Purchase, and Post-Purchase. 

Designer. These are Product Designers, with a range of experience: Lead, Senior, mid-level, and Associate/Junior. 

UX Research. A small team of (Lead to Junior) researchers who support the organization, reporting to a Director/Manager responsible for the practice. This group is distinct (as opposed to being woven into the Design Directors’ teams), so as to support their career development as UX Researchers, reporting to a manager who has explicit responsibility to coach and grow them professionally.

Design Operations. Similar to UX Research, a distinct group that supports the organization, reporting to a leader who is both developing the practice, and managing the professional growth of their team. 

DPM. Design Program Manager.

People Ops. The beginning a “shadow HR” function within Design, to account for the fact that standard HR practices for recruiting and hiring, onboarding, professional development, and performance reviews often don’t apply well to design teams.

Research Ops. UX Research practice requires significant effort in planning, coordination, communication, scheduling, paying, etc. If your UX Researchers are doing this work, it’s taking away from their practice. I place Research Ops under Design Ops as I’ve found it more typical that Research Ops people want to grow their careers within Ops, not in Research. 

Redrawing to show relationships as it scales

That typical hierarchical org chart does not depict the relationships between different parts of the team. Instead, I prefer a diagram that looks like this. (click/tap for full size)

The BUSINESS AREAs are ‘verticals’ within the design org, with UX Researchers and Design Program Managers dedicated to them, while reporting to their function lead. 

UX Research. With two researchers supporting a business area, one should be truly senior, and the other more junior. 

Design Program Management. As shown here, the DPM is oriented on the Design Director. The two of them essentially ‘run’ their part of the organization, which the Design Director focused on creative and managerial leadership, and the DPM addressing the operational needs.

This diagramming helps us see how such an organization may scale (click/tap to enlarge).

Drawing of the generic org scaling

Because of the genericness depicted, there is a lot that I’m not (yet) addressing, and which I plan to in subsequent posts. But one thing I’ll briefly touch on, as I hear Kristina Halvorson yelling it in my mind’s ear, is

What About Content?

And there is a simple answer to this. Either:

  • some of the Designers in the design teams are Content Designers
  • or Content Design functions analogously to UX Research and Design Ops, as a ‘horizontal’ team, reporting to a Head of Content Design, and with specific content designers

(I’d love to hear from folks on what organizational model they’ve found works best for Content Design.)

What’s Next?

This post is meant to be a foundational building block for further thinking on emerging standards in the shape of design organizations. Subsequent posts may include:

  • Digging into BUSINESS AREAs
  • The New (Shadow) Design Strategy Team (it lurks within this structure)
  • Experience Teams vs Platform Teams
  • Design Systems and Accessibility teams
  • How big this scales before needing a new model


11 thoughts on “The Emerging Shape of Design Orgs (first in a series of I don’t know how many)

  1. This model looks great, Peter — thanks for sharing.

    I’m wondering who looks after the structural integrity of the system across the org. (E.g., global nav, search results, etc. — IA stuff.) I assume the VP of design is too busy for this type of thing, and the model doesn’t have lower-level roles whose purview spans across businesses.

    You’ve mentioned the emergent architect roles for this sort of thing in the past. Where would those fit? (I wonder if it’s part of the design strategy team you’re hinting at.)

    • Jay Fienberg says:

      I also was curious about both the platform / structural design roles and the principal-level placements in the buckets.

      My sense (influenced by Peter’s earlier article) is that principal-level folks can fit into different places, depending on how they might specialize in the org at any time / or as their career specialties. Or do super senior roles map into another org structure?

      And I’ve lived with and seen a quite a lot of tension of doing platform / architecture focused design when managed in a vertically-imagined design team buckets. I think this is maybe a larger org and/or design leadership challenge, e.g., supporting the people doing work in the problem space as well as those doing work in the solution space.

      Perhaps this will be covered more in the discussion of “The New (Shadow) Design Strategy Team (it lurks within this structure)?”

      • We’ve been deploying Principal Designers as connectors who work on strategic efforts that cross design teams, which seems to be working well.

  2. This is how my teams are structured at Zendesk. The Eng/PMs are also aligned similarly.

    Content Design is similar to UXR and DesignOps, but are often also aligned with the sub-business areas too.

    What’s missing is Design Systems, Platform and Foundation efforts – how they connect and inform the different business areas. They are horizontal – impacting all business areas.

    • “What’s missing is Design Systems, Platform and Foundation efforts – how they connect and inform the different business areas. They are horizontal – impacting all business areas.”

      THIS! Would love to know how orgs conceive of these roles. Peter lists these in the “what’s next” section and I can’t wait. I suspect my team is the “New (Shadow) Design Strategy Team” and we work closely with the platform teams (the horizontal platforms you mention) that impact all of our business units.

  3. With us, the content team works as a horizontal team. We also have a dedicated Design team, horizontal do handle Design Systems, UI, IxD, and more.
    I share the concern of Jorge Arango and I do feel in our org the need for a horizontal team specifically with information architects and with senior experience architects, covering the holistic and continuity aspects with the ecosystems and all the journeys.
    We have also considered moving ResearchOps under DesignOps.
    And anyone has or is missing a horizontal team fully dedicated to “experimentation”, providing the capabilities to quickly build and iterate prototypes/experiments with no dependencies from dev teams?

    p.s. “click to zoom” in the diagrams is not work with the exception for the 1st one

  4. Exactly how we’re set up at Clover. We started with Content Design similar to UXR and Ops, but eventually shifted to embedding Content Designers into each design team.

    Curious where you see Communication/Brand Design. We treat that as another team, which we call Brand Experience. But that sometimes has its political challenges, as Design is seen as “part of Product.”

  5. This is very similar to how we’re set up at Rocket. We’ve found that having (using the terms of this diagram) design directors focused on leading teams within a business area allows those leaders to provide much more impactful feedback and direction to their team members than discipline-based leaders. It does create a slight vacuum of discipline leadership, but we’re working on building a center of excellence model within design ops to fill that gap. Thanks for keeping this conversation going, Peter!

  6. What you outline above clearly speaks to a larger orgs and a larger hierarchy I believe. To me that means lots of coordination and structure that is in place. At minimum you have 15+ designers and a more mature design org, that’s when maybe you get to start thinking about roles of Design Manager, Dedicated UX researcher, Design Ops etc. I wonder ‘how might we’ speak to a model that may be more nimble where we have small teams (large or small company) executing to specific initiatives with guided objectives. I like Kate’s comment of the ‘missing design systems’ service, if that was in place then that puts the rails or constraints for the teams to operate within and could be very freeing. I see value in having a well formed small team (has skills in UR, UX, Prod, Engineering) that takes ownership in defining customer needs, problem solving to those needs, and delivery, and all within the confines of what is acceptable within the design system. BTW I also like the Jay’s comments of having Principal designers operate across teams, that’s a great idea to have senior folks work like that, again, if you have the capacity and team size to support it.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>