In my previous post, I laid a foundation for thinking about the emerging standard shape of a product design organization. In the comments and on LinkedIn, a number of questions and comments came through, and by far the most addressed Design Systems and related platform matters.
From what I’ve seen, while the overall shape of a design org is settling into something like I’ve shown, where specifically Design Systems lives varies from org to org. Earlier this year, I supported an enterprise software team building HR tools. From what I gathered, our plan for design org structure is one that’s emerging as a standard within enterprise software. I’ve altered some details for the sake of easier communication (tap/click to enlarge).
Applications (or Experiences) and Platform. For years, working within product development organizations, I witnessed a lot of resistance to the idea of “Platform” or “Shared Services” teams. In the move to “Agile” there was a desire for every team to be an autonomous unit, capable of directly delivering value, with no dependencies on any other team.
As these orgs scaled, this proved to be folly, with teams needlessly duplicating effort, and recognition that dependencies are not a bad thing, just something worth coordinating.
More recently, many companies are moving toward splitting product development into two big areas: Applications (or Experiences) and Platforms. In their latest book EMPOWERED, acknowledge product leadership experts Marty Cagan and Chris Jones write about this at length, defining platform teams as those “which manage services so they can be easily leveraged by other teams,” and experience teams as those “which are responsible for how the product value is exposed to users and customers.”
Applications. In the prior post, there were generic BUSINESS AREAs. Now we’re making them specific. Applications refers to the specific, well, applications within the HR Software suite. If you’ve ever applied for PTO through software, you’ve used such an application.
Application Sub-teams. Given the size of the Applications design org, it’s best to break it up into smaller teams (team effectiveness drops considerably once a team is more than 7 people). One of the arts of organization design is figuring out the size and mandate of such sub-teams. In this case, we have three: Recruit and Hire, Onboard and Work, Comp and Benefits. The idea is for each time to have a meaningful and manageable chunk of the employee journey.
In my observations, it’s common for design orgs to be understaffed relative to the number of product teams or squads they are meant to support. So, for example, the “Recruit and Hire” designers may be working across 7, 10, even 15 Scrum teams delivering Recruit and Hire functionality. How that is handled is the subject for another day. The point here is that all the designers working on Recruit and Hire functionality are part of one clearly defined team.
Platform. This team designs stuff that is not specific to an aspect of the experience, but undergirds everything.
Shared Experiences. In the comment to the prior post, Jorge Arango asked, “I’m wondering who looks after the structural integrity of the system across the org. (E.g., global nav, search results, etc. — IA stuff.)” This team is responsible for that. The integument and scaffolding that contains the rest of the experience. These are specific features and functions, such as global search, logged-in start page with modules specific to that user, and navigation schemes.
Design System. A Design System is the very definition of a “service [to be] easily leveraged by other teams.” This team is staffed with experts in specialized design roles (Visual Designer, Accessibility Designer, Content Designer), since their work is leveraged by the rest of the organization.
These are not the only people working on the design system. The expectation is that this is a cross-functional team with product manager(s) and engineers. These are the people on the design team working on the design system.
As the org continues to grow…
As I mentioned earlier, Applications sub-teams are often understaffed. Let’s say that’s been realized, and those teams are now growing. Instead of being sub-teams, they are now BUSINESS AREAs, each with a design director and teams within. (click/tap to enlarge)
As a leveraged team, the Platform Design team should not need to grow at the same rate as Applications/Experiences team. It can remain stable, supporting a growing design organization (and product development organization) without needing to add people. This distinguishes it from UX Research and Design Ops, which need to grow with the rest of the team.
What’s worked for you?
Design Systems and Structural Integrity is an area where I’ve seen far less commonality across design organizations. But I think our field is maturing such that we should have “better practices” (maybe not ‘best,’ yet) identified that serve as guides. Please share in the comments!
This matches what I’ve seen evolving in the past few orgs I’ve worked for. I think the shared experiences teams have had more challenges depending on the complexity of the platform architecture in relationship to greater or lesser recognition for design architecture roles. Some of the shared experiences teams have succeeded working closer to the surface, like designing the common page zones for menus, but then struggled when going deeper, like designing how the menu navigation models interacts with permissions.
With enterprise products, there also often can be challenges between platform and product definitions of applications or business areas. For example, a suite of applications that build on a shared machine learning engine.
That engine may be product managed to deliver both a specific ML-focused application, and also as the platform for features in other applications. Likewise, the experience design of the engine and features built on it need to explore and deliver in multiple dimensions, on multiple time scales.
So I think this may fall to the design architect and shadow strategy team, to orchestrate — that seems closest to what I’ve seen, myself. But I’m curious if there are less shadowy ways you / anyone has seen this taking shape. In particular, recognition of the shadowy orgs has been inconsistent in my experience, and I’m not sure if org charts (and their corresponding budgets and goal structures) can help solve that directly.