Product design team structure: How to build and scale across multiple products and verticals

This is a full guide of designing the design team: how to structure and scale a product design organization across multiple verticals?

As a product company scales across multiple lines of business, an ad hoc design team stops working. This is a practical blueprint for structuring design across verticals, embedding it where products are built, while keeping it coherent through horizontal support teams.

(I searched and do lots of meetings, with Revolut, Delivery Hero, N26… to create/find & refine this method and guideline to create and refine our design team structure and workflows.)

Why design teams break at scale?

Most design organizations start the same way: a small group of talented generalists who are close to the product, fast to ship, and deeply embedded in every decision. It works beautifully until it doesn’t! As a company adds products, verticals, and geographies, the centralized design team that once kept everything coherent becomes the bottleneck that slows everything down.

The symptoms are recognizable. Designers are stretched across too many products to do any one of them justice. The visual language fragments because there’s no single source of truth. Product teams build features without design involvement because the queue is too long. Research becomes reactive, done to validate decisions already made, not to inform decisions still open.

“A 2025 survey of 557 UX and design professionals found that design teams with no dedicated operations support reported significantly lower design quality, slower delivery, and higher designer burnout than those with structured DesignOps functions.”

NIELSEN NORMAN GROUP, DESIGN TEAM STATISTICS, 2025

The problem isn’t a shortage of talent. It’s a shortage of structure. Design at scale requires a deliberate organizational architecture, one that keeps designers close to the product decisions they need to influence, while ensuring that everything they create is coherent, consistent, and reusable across the company.

This article sets out that architecture. It’s drawn from our own design organization model built for a multi-vertical fintech/banking product and informed by the organizational models used by Revolut, Spotify, and ING Bank in their respective scaled product teams.

“A design org is not a pool of resources to be allocated. It is a product in itself and it requires the same intentional design as everything else you build.”

The model: squads, tribes, domains, and ventures

The foundational vocabulary of this structure is adapted from the Spotify model originally a 2012 whitepaper by Henrik Kniberg and Anders Ivarsson describing how Spotify organized its engineering teams across autonomous squads, tribes, chapters, and guilds. What Kniberg himself has repeatedly clarified is that the whitepaper was never meant to be a prescriptive framework: it was a snapshot of how one company worked at one moment. We take the same spirit here.

We’ve adapted the model to fit the specific dynamics of a design organization in a multi-vertical product company.

The units we use are: squads, tribes, domains, product lines, ventures, and — at the top — the branch. Each level represents a different scale of design accountability.

THE PRODUCT VERTICALS OUR VENTURES

Each vertical is a distinct product with its own user segment, design language nuances, and squad structure. But all of them share a common design system, visual identity, and UX research infrastructure; which is where the horizontal layer becomes essential.

The two pillars: embedded design and horizontal support

At the core of our design organization model is a deliberate split between two types of design work that need fundamentally different organizational homes.

This distinction matters enormously in practice. The embedded designer on the X Business lending squad cares deeply about the loan application flow. They should not be pulled into debates about what the primary button radius should be. That’s the design system team’s decision, documented, version-controlled, and propagated automatically. The embedded designer uses the system. They don’t maintain it.

“Organizations that separate design system maintenance from feature design report 40% higher design velocity in their product squads. The cognitive overhead of maintaining a system while also shipping features is a significant source of design team burnout.”

DESIGNOPS 101, NIELSEN NORMAN GROUP, 2024

The two-pillar model is not new. It’s the design equivalent of the distinction between platform teams and product teams in software engineering. The platform team builds the rails; the product teams run on them. Both are essential. Neither replaces the other.

Mapping the roles from squad to branch

With the structural vocabulary established, here is how design roles map onto each level of the hierarchy and what each role is actually responsible for.

WHAT A SQUAD ACTUALLY LOOKS LIKE

Every squad in this model is cross-functional and complete it contains all the roles needed to define, design, build, and measure a feature without depending on another team to unblock it. Here is the composition of a typical squad, using the X Business Lending squad as an example:

ℹ️ A note on researcher allocation: Not every squad needs a full-time UX researcher. In our model, researchers can either be dedicated to a high-priority squad (large, complex user journeys like onboarding or lending) or shared across 2–3 squads within a tribe. The key is that research is never optional every squad has access to research resources. The question is only whether it’s dedicated or shared.

The three horizontal teams

The horizontal layer is what keeps a multi-vertical design organization from fragmenting into isolated silos. Three teams operate across all verticals, serving every squad and every design manager without belonging to any single product line.

THE DESIGN SYSTEMS TEAM

The design systems team is the single most leveraged investment in a multi-product design organization. Every hour spent building a reusable button component pays dividends across every squad that uses it. Every accessibility guideline documented in the system reduces the probability of a compliance issue in any product it touches.

The design systems team’s responsibilities span three areas:

• First, component creation and maintenance, building, versioning, and deprecating UI components in a shared library (typically in Figma and mirrored in the front-end codebase).
• Second, token management, maintaining the design tokens (color, typography, spacing, border radius, shadow) that translate design decisions into implementation-ready variables.
• Third, documentation and governance; writing the usage guidelines, the accessibility annotations, and the decision rationale that help embedded designers use the system correctly without needing to consult the systems team for every question.

ℹ️ The systems team serves, it does not gatekeep. A common failure mode is a design systems team that becomes a bottleneck where no component can be built without their approval, and no exception can be made without their sign-off. The right model is the opposite: the systems team builds infrastructure that makes the right thing the easy thing, and then trusts embedded designers to use it well.

Critically, the design systems team should have a direct line to every design manager and design lead in the verticals. Their work is only valuable if it’s adopted and adoption requires trust, regular communication, and a feedback loop where embedded designers can surface gaps in the system without friction.

THE VISUAL DESIGN TEAM

The visual design team owns the brand layer the illustrated characters, the motion language, the icon style, the photography art direction, the marketing template system. This is distinct from product design, which focuses on interaction and user flow. A product designer ensures that the loan application screen is clear and usable. A visual designer ensures it feels like it belongs to the same world as the savings screen, the marketing landing page, and the app store screenshots.

In practice, this team operates as a service layer for both product squads (when they need illustrations, empty states, or visual components beyond the standard system) and for the marketing and brand function (when they need campaign assets or visual storytelling). Their work is horizontal by nature no vertical should develop its own visual language independently, or the brand fragments.

THE UX RESEARCH AND ANALYTICS TEAM

The research team’s horizontal role is methodological and operational, not delivery-focused. They don’t run all the research, embedded squad researchers do much of that. What the horizontal research team provides is the infrastructure: the participant recruitment panel, the research tooling subscriptions, the synthesis templates, the research repository where insights are stored and searchable across all verticals.

This team also provides specialist expertise for research types that individual squads don’t have the depth to run themselves large-scale diary studies, concept testing with novel methodologies, accessibility audits, and cross-vertical analytics synthesis that requires seeing data across all products simultaneously.

“Where UX research has no dedicated home — no shared repository, no common methods — the same research questions get answered independently across product teams, wasting resources and producing contradictory findings. A centralized research infrastructure reduces this duplication significantly.”

NIELSEN NORMAN GROUP, WHERE SHOULD UX REPORT?, 2021

Cross-vertical collaboration in practice

The model described above creates clear homes for every type of design work. But it only functions well if cross-vertical coordination is actively designed not left to chance conversations in Slack channels.

We use three mechanisms to ensure that the horizontal and vertical teams stay genuinely connected rather than drifting into silos:

• Design critique as a cross-squad ritual A weekly open critique session where any designer from any squad can share work-in-progress for feedback from peers across verticals. This is not a gate nothing needs approval to move forward. It’s an ambient awareness mechanism that surfaces patterns, prevents duplication, and catches mistakes early when they’re cheap to fix.
• Design lead sync A fortnightly meeting of all design leads across all tribes, facilitated by the design director. The agenda: what’s shipping this sprint, what decisions have been escalated, what patterns are emerging that the design systems team should codify. This is the primary coordination mechanism for the embedded design layer.
• Researcher rotation Researchers who are shared across squads within a tribe rotate intentionally, spending concentrated periods on one squad before moving. This prevents superficial involvement while ensuring research resources remain flexible. Rotation schedules are set quarterly, aligned with product roadmap priorities.

ℹ️ The guild as informal connector: Borrowed from the Spotify model, guilds are voluntary interest communities that cross all organizational boundaries. A UX writing guild, an accessibility guild, a motion design guild anyone from any squad can participate. Guilds can cross different tribes; there is no formal leader. Rather, someone raises their hand to be the guild coordinator and helps bring people together. These are low-overhead, high-value connective tissue for a distributed design organization.

Designing for future verticals

One of the core requirements of this structure is scalability: as new product verticals are added, the design organization should be able to accommodate them without restructuring everything that already exists.

The model handles this cleanly. Adding a new vertical; say, X Insurance or X Lending as a standalone product; means:

The horizontal teams absorb the new vertical automatically they’re already set up to serve any number of product lines. The design director adds one new design manager to their reporting line. The design system gains new consumption but no fundamental new structure.

This is the scalability promise of the squad-tribe model: growth happens at the squad level, and coordination happens through the lightweight mechanisms already in place. The Spotify model is particularly suitable if you are looking for a flexible framework and are willing to adapt it to your context. That adaptation is the work — not the framework itself.

The design organization is not a headcount problem. It is an architecture problem. Get the structure right and growth becomes additive. Get it wrong and every new product makes coordination harder.

A note on what this isn’t

This structure is not a rigid blueprint to be implemented verbatim. The Spotify model dates back to 2011 when Henrik Kniberg and Anders Ivarsson published a whitepaper and Kniberg is the first person to tell you it was never meant to be something that people copied. We take the same view of this design org model. It is a set of principles and a structural pattern that must be adapted to the specific culture, product stage, and team maturity of the company applying it.

Some organizations will find that the researcher-per-squad model is too expensive and should default to a fully centralized research team until revenue supports embedding. Some will find that the design systems team should sit inside engineering, not design, for better implementation fidelity. Some will find that design managers don’t belong at the product-line level and should sit at the tribe level instead.

All of these are valid adaptations. What is not valid and what produces the fragmentation and bottleneck problems described at the start of this article is having no structure at all: a pool of designers allocated ad hoc to wherever the fires are burning, with no clear ownership of coherence, no horizontal infrastructure, and no career ladder that reflects the actual complexity of design at scale.

ℹ️ The minimum viable design org: If you are building toward this model but can’t staff all of it immediately, start here. Embed at least one designer in every squad that ships user-facing product. Create a part-time design lead role in each vertical, even if the lead is also a practitioner. Stand up a design system — even a minimal one — before you have three products, not after. These three moves prevent the fragmentation that is expensive and disruptive to fix later.

About Me

I’m Mostafa Esmaeili, a Product Design Director with 10+ years in FinTech and Web3, specializing in scaling design systems and cross-platform design infrastructure across multi-squad organizations.

I’ve built unified design systems from scratch, led teams of designers, and owned end-to-end platform decisions that reduced feature development time by 30%. I turn the complexity of financial products into lean, scalable, and beautiful systems.

Let’s connect: Linkedin | X | Portfolio

[embed]Scaling Small: Effective Design Team Management and Task Distribution Managing a small design team comes with its own set of unique challenges and opportunities. When resources are limited…medium.com

**FURTHER READING & REFERENCES** → Discover the Spotify model — Atlassian → Typical design team structures and alignment — Nielsen Norman Group, 2025 → DesignOps 101 — Nielsen Norman Group → Where should UX report? Three common models — Nielsen Norman Group → Five DesignOps team structures — Nielsen Norman Group → Design guidance: principles, patterns, heuristics, and team charters — Nielsen Norman Group → A design system isn’t a project, it’s a product serving products — Nathan Curtis, Medium → The anatomy of a successful team squad — Nicola Ballotta, Hybrid Hacker → The Spotify model: squads, tribes, and chapters explained — Peerdom → How Spotify scaled product development with the squad model — Ideaplan → Design team structures at the world’s top companies — InVision

……

💡 Stay inspired every day with Muzli!

Follow us for a daily stream of design, creativity, and innovation. ***Linkedin | [Instagram](https://www.instagram.com/usemuzli/) | [Twitter](https://x.com/usemuzli)***