I’m co-authoring a book on building in-house design organizations. In it, we advocate for what I call the “Centralized Partnership,” where design remains wholly centralized, and broken up into teams that are committed to different aspects of the business. We propose some radical ways of structuring your design organization, and I thought I’d share a rough draft of what we’re thinking.
Donâ€™t just mirror the product organization or business units. In order for your team to successfully collaborate with others, itâ€™s important to understand how the rest of your company is organized. However, itâ€™s insufficient to have your design teams simply reflect that structure. Organizations grow and evolve over time, and the reasons for how they arrive at a particular structure are varied (e.g., acquisitions, firings, failed initiatives) and might not make sense for your team. A design organization that is not wedded to the structure of the broader company can help maintain a stable customer experience when the inevitable reorganizations occur.
If you can organize by customer type, do so. A fallacy is to have designers obsessed with the products and services they work on. Product and service features are just manifestations of parts of a userâ€™s relationship with your company. Instead, you want your designers obsessed with their entire userâ€™s experience. So, organize your teams by types of users. Many companies have clearly distinguished audiences — marketplaces have buyers and sellers; banks have personal/consumer, small business, and institutional customers; educational services have teachers, administrators, students, and parents; and so on. When a design team focuses on a type of user, it can go very deep in understanding them, and that empathy leads to stronger designs that fit the usersâ€™ contexts and abilities. So, for a marketplace, have a â€œBuyer Design Teamâ€ and a â€œSeller Design Team.â€
This kind of organization proves quite radical in certain companies. Banks and other financial institutions typically organize their teams around products or lines of business (basic banking, credit and debit cards, loans, mortgages, etc.) that behave as if in silos, and rarely coordinate. However, the same customer is engaging across these products, and can find the lack of coherence frustrating. To have a â€œretail consumerâ€ design team that works across these products should lead to a better customer experience but will be difficult to maintain in the face of a company that incentivizes business units through their specific productsâ€™ success. This might require executive sponsorship to demonstrate just how crucial a cohesive customer experience is for the whole company.
Organize by the customerâ€™s journey. If your company is successful, youâ€™ll need to grow those teams. Keeping in mind that no team should have more than 7 people, consider splitting them up along a customerâ€™s journey. For example, if youâ€™re a travel service, you could section the teams into â€œPlan Your Trip,â€ â€œBook Your Trip,â€ â€œTake Your Tripâ€ and â€œAfter the Trip.â€ Remember, this is regardless of whether the product or business teams are organized this way. Organizing by the journey allows each team to shift focus from features (search, browse, booking) to the overall experience, and the design work on those features will fit within the broader whole.
These specific teams will still roll up into a broader â€œTraveler Design Team.â€ Itâ€™s important that they remain in contact, even if itâ€™s just a weekly meeting to share out what each sub-team is working on.
A ramification of this approach is that you might have designers from two different teams work on the same feature where your different customer types interact. One example of this is in a marketplace, where a buyer wants to book an appointment with a seller. From a product management and engineering perspective, â€œBook an appointmentâ€ would likely be the responsibility of a single feature team. In a decentralized organization, the same designers would work on the user experience for both the buyer and the seller. When you organize by customer journey, however, the concern shifts to figuring how this feature fits in the buyerâ€™s and sellerâ€™s respective workflows. You want the Buyer Team to design the appointment feature in the context of the broader Buyer experience, and likewise on the Seller side. It might feel like inefficient overhead, but it should result in better conversion as the designs are mindful of context. Â Â