How we work together
Getting something into the Connected Design System runs through GDI, Platform and the Dev Teams, in that order. This page describes the route a business need takes to become a released component, who holds each stage, and who makes each decision.
It covers both directions: how work gets into the system, and what happens when a team wants something already in it to behave differently. For how to edit and add pages on this site, see Contribute to the Playbook.
General Flow
Section titled “General Flow”Business reaches a Dev Team. A need arrives at a Dev Team’s BA, who take it to design. The requesting team owns those meetings: if your team wants something, your team schedules the conversation.
GDI design it. GDI move legacy components, pages and apps onto the CDS in Figma, iterating with business and the PO until the design is dev-ready and tokenised. “Dev-ready” is the handover bar, and tokenised is part of it: the design expresses its values as design tokens before it leaves Figma.
Platform import the tokens. The token structure and values are GDI’s; getting them into the repository is Platform’s.
Platform and the Dev Teams decide what belongs where. The call is made together, in a meeting — not by either side alone, and not by whoever opens the CSS first. See In or out the styleguide? below.
Platform ship it, then the Dev Teams build on it. Platform implement the CDS update, document the CSS and publish the release. The Dev Teams then build the React component and the app behaviour against that release, and document the React components other teams can reuse.
In or out the styleguide?
Section titled “In or out the styleguide?”Three questions, asked about the thing being built:
- Is it, or should it be, reusable by other teams? Not “could it conceivably be reused” — whether other teams actually have this problem.
- Can primitives be extracted so that it can be reused? Sometimes the whole thing belongs to one app but a layout, a component or a utility inside it does not. Pulling those out turns a one-off into something shared.
- Can it, or should it, be brand-specific? Toyota, Lexus and Kinto do not have to resolve the same way, and a design that only makes sense for one brand is a different proposition from one that has to work for all three.
Yes to the first two makes something Platform’s. No leaves it with the Dev Team, built in their own app — a legitimate outcome, not a rejection.
Change Requests
Section titled “Change Requests”A component exists, and a team wants it to look or behave differently.
Every such request is a design call. Platform triage it; Platform do not decide it.
| Figma says… | It is… | Who acts |
|---|---|---|
| X, and the styleguide does not do X | a bug | Platform fix it |
| not-X, or nothing at all | a design change request | GDI decide and update Figma first, then Platform implement it |
“Figma is silent at this breakpoint” is not “Platform decides.” It is still GDI’s to specify: the request has not been designed yet.
A commit that changes a component’s behaviour cites the Figma evidence for it, so the decision holds up when the opposite request arrives.
Where to send one. A Teams message to Platform. There is no intake form and no queue.
Ownership
Section titled “Ownership”GDI own TME design in Figma, the token structure and values, and the usage and accessibility documentation. Accessibility documentation is part of design documentation: written by GDI, sourced from Figma, and reviewed by Platform both manually and with agentic AI. GDI are formally responsible for this site’s Design documentation; in practice Platform author those pages from GDI’s Figma documentation.
Platform own getting the tokens into the repository, this Playbook, the styleguide, and every component in it, including the CSS documentation.
Dev Teams build the shared React components and AEM structures, and document the ones that are reusable by other teams.
Outside DXP
Section titled “Outside DXP”Teams outside DXP consume the design system rather than contribute to it. Design requests go through the Dev Teams, so they cannot be raised directly. Feedback and support are open: if something in the styleguide is broken, unclear or missing, tell Platform.
Open questions — please correct these in review.
- GDI’s own internal process. GDI have a PO and a lead designer; the steps between them are unknown to us, so the flow above treats “GDI design in Figma” as one box when it is presumably several.
- Who signs off, by name — on the GDI side, and on the Dev Team side.
- Is accessibility documentation really GDI-written and Figma-sourced as described above?
- Should this page say that GDI formally own Design documentation while Platform actually write it?
- The alignment cadence. One to two backlog meetings per month is unconfirmed.
- Where change requests should go. Today it is a Teams message to Platform. Should that be a queue, a recurring support ticket, or a channel?