Nechunaev.com

Creating Dedicated Design System Team

Timeframe:
≈12 months
Role:
Team Manager
Org Context:
RnD department of 200+ people
Stack:
Web, iOS, Android
group

Organisational design of new department: processes, goals, responsibilities, management. When to decide that you need a dedicated team?

Creating Dedicated Design System Team

Header

1. Context

The company had reached saturation in its core market and was preparing to expand into adjacent ones. In that situation, one of the most leverageable strategic assets is the brand, and a coherent design language is one of the most direct ways to carry a brand into a new market. This was the strategic frame in which the initiative sat.

The operational picture was less coherent. The product line served private customers across Web, iOS, and Android, and users routinely moved between platforms within a single scenario, like adding goods to the basket on a phone, then completing payment on a laptop. UI was consistent within each platform but not across them. Patterns drifted, navigation diverged, and users lost their place when switching. The order history screen offered a small but representative example: it looked different on each platform, and on iOS it sat behind two extra taps. None of this resulted from any one team’s decisions. It was the natural consequence of a fast-growing organization shipping in parallel on three platforms without a shared system holding them together.

A self-organized group had been attempting to address the problem. A handful of designers and engineers, distributed across product teams, maintained Figma mock-ups and component libraries in their spare time. The group was flat, well-intentioned, and structurally unstable: every member’s manager carried product deadlines, and design system work was consistently the easiest item to defer. Over time the libraries became chaotic and partially abandoned. The failure mode (not absence of effort, but absence of dedicated mandate) was the clearest signal that the next stage required a real team.

The wider RnD organization comprised roughly two hundred people, organized into:

Web had come first, so mobile was perpetually catching up: fewer features, lower polish, and a backlog shaped more by deadline pressure than by deliberate design.

2. Constraints and non-goals

Before describing the approach, the boundary conditions are worth stating precisely.

Operational constraints:

Environmental constraints:

Non-goals. Four exclusions were set explicitly at the outset. The team would not build domain-specific patterns or features, would not rescue product teams from deadline pressure, would not focus solely on a component library, and would not assume ownership of UX research. Each exclusion corresponded to a known failure mode in similar initiatives, and naming them in advance proved more important than naming the goals.

3. The decision / approach

The mandate was to create the team, define its responsibilities and processes, establish communication flows with internal customers and stakeholders, set the technical strategy, write the yearly and quarterly plans, and hand the team off to another manager within twelve months.

The right design system model depends on company maturity. Early-stage organizations rely on informal, shared effort focused on speed and basic components. Growing organizations introduce design reviews and a common language through loosely coordinated groups, often anchored on platform champions and a guild. Mature organizations shift the design system from a productivity tool into a strategic one, supporting brand identity and quality at scale, which typically requires dedicated ownership. The interesting questions are when an organization crosses that line and how responsibilities should redistribute when it does. The model itself is covered in detail in a companion post: <LINK: How to choose the right design system model>.

Several signals tend to fire when the line has been crossed:

Any one of these is sufficient to begin the conversation. Most of them were present simultaneously in this case.

Three lighter alternatives were considered before settling on a dedicated team:

Management’s stated priorities: lifting mobile UI/UX quality, achieving homogeneity in UX patterns across cross-platform scenarios, and producing a more deliberate end-user feel. It was mapped cleanly onto a dedicated team’s leverage points, and the headcount was approved.

The harder question was how to design the team itself. To do so without hand-waving, it is useful to describe a team’s activity through a model that traces how intent becomes output. The full model is described in <LINK: Team Activity Model for Managers>; in summary, any team’s work decomposes into seven elements:

Pic 1. Team Activity Model
Pic 1. Team Activity Model

The model matters because it forces clarity on the boundary between this team and everyone else. Each responsibility transfer, each non-engagement rule, and each adoption metric ties back to one of these slots. The dominant risk in standing up a design system team is not design quality but governance, which is why the operating model and not the technical artifacts is the focus of the implementation that follows.

4. Implementation highlights

The team activity model, applied

Mission. Create and evolve a unified design language that ensures a consistent, high-quality, and recognizable user experience across all platforms with a strong development experience for the engineers and designers building on it, and supporting the company’s brand expansion into new markets.

Goals.

Tasks.

Resources. The team had four roles, deliberately lean:

The decision to staff a single engineer across both mobile platforms was the riskiest call in the team composition. Hiring two specialists would have been safer on paper. The reasoning rested on three points. First, maintaining a design system library does not typically require top-tier platform specialists; the work is repetitive enough that strong specialists would be under-utilized within a quarter. Second, what was required was someone who understood the differences between platforms well enough to make trade-off calls, with the tech lead available to backstop on harder problems. And third, one cross-platform engineer fit the salary budget in a way that preserved flexibility on the other roles. The decision proved sound in practice.

Beyond people, the team relied on Figma, Confluence, Jira, and a small VPS to host internal services and the showcase. Equally important were standing access to the UX research team in Marketing and established working relationships with product team leads, native platform leads, and brand and marketing stakeholders. These relationships functioned as a resource in the strict sense: they required ongoing investment to maintain.

Methods. The team’s working rules grouped into three categories.

How decisions are made. The contribution model was a federated structure with centralized coordination. Product teams could propose patterns; the design system team owned the core, reviewed contributions, and promoted patterns to platform-wide status once validated. New patterns went through a lightweight RFC, reviewed by a recurring design council with product team representatives at the table. The most consequential rule was the explicit non-engagement list: the team would refuse domain-specific work and deadline-rescue requests, routing them back to the requesting product team. This rule existed specifically to prevent the failure mode that had ended the predecessor group.

How work ships. Token-based, atomic structure: tokens to primitives to components to patterns to scenario templates, mirrored across platforms. Each component library was versioned with semantic versioning and a published deprecation policy. The Definition of Done for any pattern was non-negotiable: WCAG-accessible, implemented and tested on all three platforms, documented, and shipped with a migration path. Migrations rolled out scenario by scenario in coordination with product team roadmaps, never as a single coordinated redesign.

How priorities are set. Inconsistencies entered a standardization workflow: identify the inconsistency, compare implementations across platforms, define the canonical pattern, validate (with UX research where needed), then document and release. Prioritization was adoption-driven: features and patterns were scheduled by usage volume, inconsistency severity, and brand impact.

Materials. The team’s raw inputs were:

Product. The team’s deliverables fell into the following groups:

Lead Designer competence model

In partnership with HR, a competence model was developed for each role on the team. It served as the foundation for hiring, leveling, and growth conversations. The full Lead Designer model is covered in a companion post (<LINK: A competence model: why you need it and how to use it>); the Key Result Areas are summarized below.

  1. Design system vision. Creates and updates the design system’s principles and rules. Collects and documents requirements from the Art Director.
  2. Functional requirements. Identifies developer needs and translates them into design system requirements. Analyzes design creation processes inside product teams, identifies pain points, and proposes solutions. Conducts qualitative and quantitative research with design system users.
  3. Figma component library. Creates and maintains components in Figma. Adapts the library as the system evolves. Analyzes product designers’ mockups for emerging interface patterns and folds them into the library.
  4. Principles, formalization, compliance. Articulates the working principles for designers and developers and the system’s internal rules. Writes documentation. Conducts design reviews of frontend and mobile work. Gathers feedback and uses it to evolve the system.
  5. Promotion inside the company. Articulates the value of the design system from the client’s perspective and proposes solutions to product teams.

Design Review process

The design review process was the team’s most visible interface with the rest of the organization. A review process already existed. Art Director signed off on major changes and lead designers approved smaller fixes, so the new process integrated with that backbone rather than replacing it. The additions were a structured framework with an explicit checklist for design system compliance, and a formal sign-off from the team’s Lead Designer. The result was modestly heavier and more formal, but also more deliberate, with fewer opportunities for mistakes to pass unnoticed.

Pic 2. BPMN chart of Design Review process
Pic 2. BPMN chart of Design Review process

RACI for the process:

ActivityDSPrUX
Prepare feature designIR/AI
Check against design systemIRI
Submit review requestIRI
Classify request (standard vs new)R/ACI
Review standard usageR/ACI
Provide feedback (compliance issues)RAI
Analyze new pattern / deviationR/ACC
Validate with UX research (if needed)RIR/A
Decide on pattern acceptanceR/ACC
Define/refine patternRCC
Update design system (docs, components)R/AII
Communicate updatesRII
Approve/reject feature designR/ACI
Implement featureIR/AI

Roles:

SLAs: standard reviews ≤ 2 days, new pattern reviews ≤ 1 week.

Yearly OKRs

Four objectives, written to map directly onto the constraints and management priorities established earlier. They are reproduced in full because they are the artifact most useful to others working in this seat.

5. Rollout

The first year was sequenced to derisk the organizational dimensions before the technical ones. The predecessor group had not failed for lack of skill; it had failed because no one owned the work in a way the organization respected. Without securing the new team’s mandate, scope, and processes before it began shipping, the same failure pattern would have recurred at greater cost.

The year proceeded in four phases:

Considerable activity ran underneath that timeline. Once the team activity model was clearly defined and aligned with adjacent managers, responsibilities transferred cleanly. The Core team handed over showcase development and maintenance, continuing to produce the underlying tools for components and libraries while the design system team became a consumer of those tools. The Native Mobile teams transferred ownership of the existing component libraries.

In parallel, working with HR, competence models were developed for each role. These yielded two benefits: sharper hiring criteria, and a clear picture of growth paths for the people hired. The same effort produced the foundation for OKR planning, since each role’s outcomes mapped naturally onto team-level objectives.

The processes were then designed. The four most important were:

Each was backed by metrics, and tying those metrics to company goals turned OKR planning from an annual exercise into something the team could actively use.

The rollout was gradual and front-loaded with conversation. By the time the first hire started, every relevant manager knew what to expect, what they were giving up, and what they were receiving in return. That investment up front was the single largest contributor to the smoothness of the rollout. Hiring the lead designer internally substantially eased the early adoption push, because he was a person who had already worked across several products and was known to product designers and managers.

The first year’s goal was deliberately modest: make the team operational. Ship deliverables, integrate with product teams, run the processes, and ensure that internal customers reported real value from the team. Volume and craft of the design system itself came second. The original failure had been administrative rather than technical, and the rebuild had to address the administrative dimension first.

6. Results

At a glance:

The most consequential result is also the one most easily understated: the team outlived its founder. After the first year, ownership transferred cleanly to another manager, the operating model held, and management renewed the team’s mandate with new goals for the following year. Most design system teams do not survive the transition out of formation phase. This one did, and the metrics below should be read as supporting that outcome rather than replacing it.

Across the four yearly OKRs, the team scored above 80% on every objective. The most concrete results, by objective:

Operational metrics worth naming:

Some figures here are reconstructed from memory and rounded conservatively, since current dashboard access is no longer available. Directions and magnitudes are accurate; presenting precise decimals would imply otherwise.

7. What I’d do differently

The contribution model was too heavy. The formal RFC process made sense for new patterns and large changes, and remained appropriate at that level. For small components, however, it became overhead. The round-trip of writing the RFC, gathering comments, and approving could exceed the time required to implement the component. The team and its clients quietly let it lapse for smaller work, and after the management transition the process evolved into a lighter model anchored on a dedicated Slack channel, with the formal RFC reserved for changes that genuinely warranted it. A two-track model from day one would have been preferable.

Twelve months was a tight horizon. By the end of the year the team had stopped fighting fires and had just begun working on the deeper structural problems. That is the worst possible moment to swap managers, since it discards the contextual knowledge accumulated over the year. An additional six months under the founding manager (twelve would have been ideal) would have produced a substantially stronger handoff position. The constraint was contractual rather than judgment-driven; within it the work was compressed into the available time, but the better shape would have been longer.

8. Further reading