Tech defines what to build in Confluence, TA signs it off, then it feeds the /ta-component Figma prompt where Claude does the research, live-validation and build. Here's the hand-off — and where each person steps in.
The flow
Decisions are made and signed off before Figma. Today they're worked out mid-build, which puts the load on design and surfaces problems late.
In Confluence
1 · Define
What the component does, its variants, and any merges — written down.
Tech leadsDesign supports
→
Sign-off
2 · Approve
High-level review of the spec before any build effort is spent.
TA
→
In Figma · /ta-component
3 · Build
The signed spec feeds the prompt; Claude researches, validates & builds.
Claude runsDesign directs
Why it helps: a wrong merge or variant call is caught on a Confluence page, not after a 40-variant set is built and re-cut. The design-heavy thinking moves upstream to tech + TA.
In the build phase, Claude runs ~84% of the operations (scraping, variants, tokens, migration, docs); every decision and the final review stay with people.
How a component gets made
Two halves: define it in Confluence (tech-led), then build it in Figma through the /ta-component prompt.
Define · in Confluence
Tech leadsDesign supportsTA signs off
1
Functional definition
What it does, its states and behaviour — led by tech, since it drives implementation.
2
Variants & merge decisions
One component or several, and the full variant list — e.g. Footer 7→1, Featured Banner 2 sets merged.
3
Authoring model
The AEM / Sitecore fields, defaults and optionals a content author will see.
TA High-level sign-off — the batch is approved before Figma
↓ the signed spec feeds /ta-component ↓
Build · in Figma via /ta-component
Claude runsDesign directs & reviews
4
Research & gather sources
Claude scrapes the 5 live brand sites + pulls the linked Confluence spec.
5
Validate against live
Claude measures each breakpoint; the live site wins on any conflict — e.g. the Accordion's mobile padding (16→20) and black vs teal toggle.
6
Build the component
Variants, tokens, responsive sizing; you make direct edits and eyeball each breakpoint.
7
Document it
Claude fills the component's doc page; you check tone and template leftovers.
8
Review & sign off
Claude groups the client comments and drafts replies; you and Brooke decide — e.g. the "should be 6xl" fix.
The design craft — building the experience as a system
Beyond redrawing production, design's real job is to turn each component into a consistent, reusable part of the system that still holds up as brands, breakpoints and content change. That systematising is design-led, through two lenses:
System POV — fits the whole
Standardised & reusable
Reuse shared Elements — Button, Icon, List — never rebuild an atom.
Everything bound to tokens — colour, type, spacing; no raw values.
Consistent variants, states & on/off toggles across components.
One documentation pattern — anatomy, do/don't, accessibility.
Consistent naming & structure so anything is findable.
HZTL-local only — nothing tied to the old library.
Future-proof POV — holds up over time
Built to scale & adapt
Device-backed responsive tokens — one change flows to every breakpoint.
Theme / brand modes — 5 brands + China from one component.
Language modes — Noto font swaps per locale.
No hardcoding — a single token change updates every instance.
Accessibility built in — focus, contrast, touch targets.
Booleans over new variants — extend without exploding the matrix.
The design value-add: this is what makes it a design-system component, not a one-off drawing — consistent to use today, and cheap to change tomorrow when a brand, locale or breakpoint shifts.
Where people step in
The calls that need human judgment, and who owns each.
Merge or keep separateA business + implementation trade-off — decided in the spec.
Tech + Design
Variant scope & authoring modelWhat variants exist and how it's authored.
Tech
Approving the batchHigh-level sign-off before build.
TA
Which source wins on a conflictLive vs Confluence vs Figma vs code — usually live.
Design
Reading terse client feedbackPins like "WGEA?" or "should be 6xl" need context.
Design
Final visual sign-offDeciding it's faithful enough to ship.
Design + TA
What to change
Four practical moves, biggest first.
01
Tech-led Confluence definition, TA-signed ★
Behaviour, variants and merges written by tech (design supporting) and approved by TA before Figma.
02
A finite, numbered component list
Work in fixed batches so scope is clear and sign-off is one pass per batch.
03
Feed the spec into /ta-component
The prompt runs the repeatable build steps — research, live-validate, tokenise, document — the same way every time.
04
Write decisions down once
A simple decision log so merges and grid rules aren't re-argued each time.