# Creating Dedicated Design System Team ## Header - Timeframe: ≈12 months - Role: Head of Department - Org Context: RnD department of a couple hundred people - Stack: Web, iOS, Android ## 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: - Several product teams shipping web services - A single Native iOS team covering all products - A single Native Android team covering all products - A Core team focused on PaaS and DX - An IaaS team - A UX research team that sat in Marketing for historical reasons 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:** - The team had to be operational within one year. Not only hired, but producing deliverables actively used by product teams. - Headcount was capped at five. - The team had no mandate authority. Adoption had to be earned, every time, against the alternative of teams building their own solutions or sourcing externally. **Environmental constraints:** - The UX research team sat in Marketing rather than RnD, so access required ongoing negotiation rather than direct allocation. - Each platform had a different ownership model: Web was distributed across product teams, while iOS and Android each had a single dedicated platform team. - Existing component libraries were already embedded in product codebases, and the new team would need to take ownership of them without breaking what worked. - The predecessor group, while structurally broken, included real people with real political stakes. **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: . Several signals tend to fire when the line has been crossed: - The product is stable in its home market and management is preparing to expand internationally. - The portfolio is broadening into new business domains. - The organization has grown past the point where horizontal coordination scales naturally. - Teams are building workarounds because the central system cannot keep pace; backlogs grow rather than burn. - Teams produce visibly different components while still claiming to follow the existing guidelines, which indicates the guidelines have stopped functioning as guidance. 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: - **Allocating formal time (e.g., 20%) to the existing virtual group.** This would have left product managers choosing every sprint between visible product work and abstract platform work, and in practice the choice will always be to work on product. - **A champion-per-product-team model with a small core.** Coordination cost grows with the number of services, and convergence on a single decision becomes increasingly difficult. Granting the core veto authority effectively reinvents a dedicated team with less authority and more meetings. - **Splitting into a tokens-and-foundations team plus per-platform leads.** This addresses component drift but not divergence at the scenario and pattern level, where the user pain actually lived. 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 ; in summary, any team's work decomposes into seven elements:
Pic 1. Team Activity Model
Pic 1. Team Activity Model
- **Mission** — why the team exists. Long-term, stable, not directly measurable. - **Goal** — what the team is trying to achieve now, within the mission. Time-bound and observable. - **Tasks** — what the team does within a given cycle. - **Resources** — what enables the team to operate: people, money, tools, relationships. Used but not consumed. - **Methods** — how decisions are made and work is structured. Processes, frameworks, rules. - **Materials** — what the team transforms. Used up or transformed. - **Product** — what the team delivers to others. Tangible or intangible. 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.** - Align UX patterns across Web, iOS, and Android for the key cross-platform scenarios. - Lift the perceived quality of mobile to match or exceed Web. - Increase reuse of design and interaction patterns across products. - Replace large-scale redesign cycles with continuous incremental improvement. - Strengthen brand recognition through a consistent design language. **Tasks.** - Auditing existing UI/UX across all three platforms to map gaps and inconsistencies. - Defining and evolving cross-platform UX patterns (not domain features) and design tokens (color, typography, spacing, motion, elevation). - Maintaining and versioning the three component libraries in sync. - Reviewing cross-domain feature designs from product teams for design language compliance. - Facilitating cross-team design syncs to broker decisions when product teams propose overlapping patterns. - Publishing migration guides and supporting product teams through adoption. - Collaborating with the UX research team in Marketing to validate pattern decisions with evidence. - Producing internal documentation and a single source of truth for designers and engineers. - Tracking adoption and consistency metrics, reporting to management. **Resources.** The team had four roles, deliberately lean: - One tech lead — a generalist architect comfortable across all three platforms. - One native mobile developer — covering both iOS and Android. - One web frontend developer. - One lead UX designer. 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: - Existing inconsistent mock-ups and screen flows from Web, iOS, and Android - Cross-platform user journeys (browse → basket → checkout, and similar) - Brand guidelines and assets from Marketing - UX research outputs from the Marketing-side research team - Cross-platform telemetry and analytics, particularly on platform-switching scenarios - Bug reports and support tickets describing UI confusion or inconsistency - Product team feature briefs and edge cases - App store reviews and customer feedback **Product.** The team's deliverables fell into the following groups: - The design language itself: principles, tokens, motion language, voice, and brand-aligned visual identity. This was the asset most directly supporting market expansion. - Three platform component libraries (Web, iOS, Android), kept in sync, versioned, and documented. - A pattern library of cross-platform UX patterns covering shared scenarios: navigation, lists, forms, checkout, auth, profile, and others. - A documentation portal with usage rules, do/don'ts, accessibility requirements, and migration guides. - Design reviews and approvals for cross-domain features. - Consistency audits and quality reports for leadership and product teams. - The set of processes the team owned end-to-end: design review, contribution and governance, internal CustDev, and others. ### 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 (); 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: | Activity | DS | Pr | UX | | --------------------------------------- | ------- | ------- | ------- | | Prepare feature design | I | **R/A** | I | | Check against design system | I | **R** | I | | Submit review request | I | **R** | I | | Classify request (standard vs new) | **R/A** | C | I | | Review standard usage | **R/A** | C | I | | Provide feedback (compliance issues) | **R** | A | I | | Analyze new pattern / deviation | **R/A** | C | C | | Validate with UX research (if needed) | R | I | **R/A** | | Decide on pattern acceptance | **R/A** | C | C | | Define/refine pattern | **R** | C | C | | Update design system (docs, components) | **R/A** | I | I | | Communicate updates | **R** | I | I | | Approve/reject feature design | **R/A** | C | I | | Implement feature | I | **R/A** | I | Roles: - DS = Design System Team - Pr = Product Team (Design + Engineering) - UX = UX Research Team 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. - **Objective 1**: Establish a credible, single source of truth for the design language.
_Rationale:_ Without a defined and trusted core, nothing downstream is enforceable. The previous library was chaotic; rebuilding trust is prerequisite to adoption. - **KR 1.1**: Ship v1.0 of the cross-platform design token set (color, typography, spacing, radius, elevation, motion) consumed by all three platform libraries, with automated pipeline from Figma → code on Web, iOS, Android. - **KR 1.2**: Release v1.0 of all three component libraries covering the top 25 components by usage volume, each with documentation, accessibility annotations, and visual regression tests. - **KR 1.3**: Launch a public-internal documentation portal with 100% of v1.0 components documented (usage, do/don't, code snippets per platform) and ≥80% of designers and frontend engineers reporting in survey that they "know where to find authoritative guidance" (baseline at start of year, target ≥80% by end of Q4). - **KR 1.4**: Reduce the number of distinct, divergent implementations of the top 10 component types (button, input, modal, list item, etc.) across the codebase from current baseline (to be measured in Q1) to at most 1 sanctioned implementation per platform. - **Objective 2**: Achieve measurable cross-platform consistency on the highest-impact user scenarios.
_Rationale:_ This directly addresses the management priority on UX homogeneity and the documented user pain (cart on mobile → pay on web, profile/orders hidden behind two taps on iOS). - **KR 2.1**: Define and publish cross-platform UX patterns for the top 5 cross-platform scenarios: authentication, cart→checkout, profile, order history, and primary navigation. Each pattern shipped as a spec with parity expectations across Web/iOS/Android. - **KR 2.2**: Drive product team adoption such that at least 3 of those 5 scenarios reach feature and interaction parity across all three platforms by year-end (measured by parity audit against the spec: same information architecture, same tap/click depth, equivalent components). - **KR 2.3**: Reduce the median tap/click depth gap between platforms on the top 5 scenarios to ≤1 step (current example: orders list takes 2 extra taps on iOS). - **KR 2.4**: In quarterly cross-platform usability tests run with the Marketing UX research team, ≥70% of participants completing a cross-platform task (start on mobile, finish on web or vice versa) report no "moment of confusion" — establish baseline in Q2, hit target by Q4. - **Objective 3**: Improve mobile UI/UX quality to approach web parity.
_Rationale:_ This is the explicit top priority from management. Mobile lagged because of deadline pressure; the design system team's leverage here is via patterns, components, and review, but not by writing product features. - **KR 3.1**: Eliminate the top 20 UI/UX defects on mobile identified in the Q1 audit (consistency, accessibility, interaction feel), tracked to closure with product teams. - **KR 3.2**: Achieve WCAG 2.1 AA compliance for v1.0 components on iOS and Android (baseline today: unmeasured/inconsistent). - **KR 3.3**: Establish a "mobile interaction quality" rubric (motion, haptics, gesture consistency, transitions) and bring at least 3 of the top 5 scenarios up to the defined bar by Q4. - **Objective 4**: Establish governance and ways of working that are sustainable past Year 1.
_Rationale:_ The previous group failed structurally, not creatively. Product managers reprioritized design system work away. Year 1 must lock in the operating model so this doesn't happen again, and so the team stays out of the four "must not do" traps. - **KR 4.1**: Stand up a federated contribution model with a published RFC process and a cross-team design council meeting on a regular cadence (e.g., bi-weekly), with ≥80% of cross-domain feature proposals going through review before implementation by Q4. - **KR 4.2**: Publish and get leadership sign-off on the team charter, including explicit scope boundaries (no domain features, no deadline rescue, no research ownership, no library-only focus); zero deadline-rescue tickets accepted into the team backlog over the year. - **KR 4.3**: Reach an adoption rate of ≥75% for v1.0 components in newly built or refactored screens across product teams by Q4 (measured via codebase scans / Figma library usage). - **KR 4.4**: Establish a monthly release cadence for component libraries (≈10 minor releases shipped in Year 1) and publish a public-internal roadmap covering the next two quarters at all times. ## 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: - **Q1 — Foundation.** Hiring, audits of the existing UI across all three platforms, transfer of ownership of the existing libraries from the platform teams, and sign-off of the team charter. - **Q2 — First deliverables.** The token pipeline, the first components shipped on all three platforms, and introduction of the design review process to product teams. - **Q3 — Cross-platform patterns.** Pattern work began on the top scenarios. The federated RFC process opened for contributions. - **Q4 — Adoption and handoff.** Adoption push across product teams, the first conversations about the management transition, and the OKR retrospective. 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: - Internal CustDev interviews with product teams - Product and UX pattern research - Design review - Tech support 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 team outlived its founder; ownership transferred cleanly and the operating model held. - Management renewed the mandate with new goals for the following year. - All four yearly OKRs scored above 80% completion. 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: - **Objective 1 (single source of truth).** Tokens shipped to all three platforms. v1.0 component libraries shipped on Web, iOS, and Android. The documentation portal went live. Divergent implementations of the top 10 component types collapsed from approximately four per type down to one sanctioned implementation per platform. - **Objective 2 (cross-platform consistency).** Four of the top five cross-platform scenarios reached parity, against an original target of three. The order history tap-depth gap was eliminated. - **Objective 3 (mobile quality).** The top mobile UI/UX defects identified in the Q1 audit were closed. v1.0 components reached WCAG 2.1 AA on both mobile platforms — the first time accessibility had been measured systematically on those platforms. - **Objective 4 (governance).** The federated contribution model was operating. The design council met on cadence. Adoption in newly-built and refactored screens landed well above the 75% target. The team accepted zero deadline-rescue tickets across the year. The latter was the single most important number, indicating that the non-engagement rule was holding. Operational metrics worth naming: - General adoption of rules and tokens reached effectively 100% by year-end. - Component library adoption was lower but trending up consistently; the lowest line was approximately 84%. - Standard review SLA halved, from approximately three days to two. - New-pattern review SLA reduced from approximately two weeks to one. - Average time from "new component requested" to "shipped" was three days. 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 - Team Activity Model for Managers (coming soon) - A competence model: why you need it and how to use (coming soon) - How to choose right design system model (coming soon)