Design System & AI-Assisted Design Exploration

Designers direct the system.
AI compresses the groundwork.

AI is being applied as an acceleration and systems-intelligence layer to support the foundational setup of the Tourism Australia Design System. Human-led, AI-assisted — designers direct, curate, and own all decisions; AI compresses the time-intensive work of discovery, extraction, and structuring.

01

The Experiment

AI is being used to audit multiple Tourism Australia domains and sub-properties — surfacing recurring UI patterns, shared foundations, divergent behaviours, and inconsistencies the design system will need to reconcile. From there, it assists in extracting and organising the underlying design primitives and identifying the components doing the majority of the UI heavy lifting across properties.

  • Cross-domain auditing — systematic review of multiple TA domains and sub-properties to surface recurring UI patterns, shared foundations, divergent behaviours, and inconsistencies the system will need to reconcile.
  • Foundation extraction & organisation — typography (scale, families, weights, line-height, responsive behaviour), colour systems (brand, semantic, surface, state, accessibility-paired), spacing, layout grids and breakpoints, elevation and shadows, radius, responsive and adaptive patterns, motion and interaction primitives, iconography, localisation (multi-script, RTL readiness, content expansion), and accessibility baselines.
  • Component intelligence — identification of high-frequency components doing the majority of UI heavy lifting across domains, including variant patterns, states, and contextual usage. Informs prioritisation of what gets systematised first.
  • Token & variable architecture — assistance setting up a scalable Figma variable and token architecture: primitive → semantic → component-level layering, with mode/theme structures anticipating future expansion (dark mode, sub-brand theming, campaign overlays).
  • Taxonomy & documentation scaffolding — support for naming conventions, taxonomy structures, and documentation frameworks so the system speaks a consistent language across Figma, code, and written guidance.
  • Where the time savings go — designer effort is redirected toward governance, accessibility, UX quality, system thinking, pattern coherence, and long-term maintainability.
Important

AI is not autonomously designing the system. Every output is reviewed, curated, and refined under designer direction. Final decisions on UX quality, governance, accessibility, visual consistency, naming, and system architecture remain human-led and human-owned. AI is treated as a capable assistant for pattern recognition, extraction, and structuring — not as a decision-maker.

02

Risk Mitigation

Every AI-surfaced output passes through validation, review, and governance before it can influence the live system. Controls are designed to catch hallucination, over-fitting, bias, and accessibility regressions early — and to keep accountability with the design team end-to-end.

  • Manual validation of extracted foundations, tokens, and component inventories against source domains.
  • Design + Dev review for token accuracy, naming, and implementation feasibility before adoption.
  • Governance checkpoints before any pattern enters the live system.
  • Version-controlled variable architecture, naming conventions, and documentation; changes require an ADR.
  • Accessibility verification — contrast, focus, semantic structure, WCAG conformance — on every foundation and component before sign-off.
  • Source traceability — every AI-surfaced pattern links back to the domains and instances it was derived from; uncited patterns flagged for rejection.
  • Bias & over-fitting check — designers verify AI hasn't over-weighted recent redesigns, the most visually prominent property, or surface-level repetition mistaken for system intent.
  • Human approval gate — no foundation, token, or component goes live without designer sign-off.
Operating principle
AI surfaces candidates. Designers decide. The system's quality bar belongs to the people who own it.
03

Fall Back Plan

If AI assistance becomes unavailable, restricted, or deprioritised, the work reverts to a traditional manual design-system workflow. The outcome remains fully achievable — the trade-off is in time and operational overhead, not capability or quality.

  • Manual cross-domain audits
  • Manual token and foundation extraction
  • Manual component inventory creation
  • Manual Figma variable and library setup
  • Manual documentation authoring and governance tracking
Factor
With AI assistance
Manual fallback
Foundation discovery & extraction
Accelerated
Materially extended
Designer load during setup
Reduced
Increased
Time for governance, a11y, quality
Preserved
Compressed in window
Final outcome quality
Equivalent
Equivalent
Bottom line
The system can be built end-to-end through conventional methods. The trade-off is time and operational overhead — not capability, and not quality.
04

Migration Milestones

Where the design system sits on the Tourism Australia AEM → Sitecore XM Cloud + Content Hub migration. Dates come from the live client dashboard; deliverables under each milestone come from the sprint plan (12 × 3-week sprints, 29 Jun 2026 → 7 Mar 2027). Items marked are design-owned.

3 Jun 2026 M1 · Discovery
Kickoff — Discovery underway
Discovery runs through June in Sydney: business overview, content & DAM, multilingual, technical and content immersions.
  • Design system build window opens — the plan assumes the system runs 6 weeks from w/c 1 Jun 2026, in parallel with Discovery. W/C 1 JUN → 9 AUG
12 Jun 2026 Design
Design Immersion
Syd 1:30–3:30pm. The design deep-dive of Discovery — where the system's audit findings and foundations get put in front of the wider team.
18 Jun 2026 Design
Design System early review
First formal review of the design system itself — foundations, token architecture, and component direction need to be presentable by this date.
30 Jun 2026 Sign-off
M1 — Discovery sign-off
Discovery wraps 26 Jun (CMS wrap-up) and is signed off as Milestone 1. Sprint 1 starts 29 Jun — the build machinery stands up around the design system.
  • Component sign-off window opens — design overlap for TA sign-off of components lives in Sprints 1–2 only. 29 JUN – 9 AUG
  • Storybook set-up begins — the code-side home of the system. S1–S3
  • Repo, CI/CD pipelines, QA process, Sitecore project set-up. SPRINT 1
  • CMS overview training. SPRINT 1
Jul 2026 M2
Foundation
Content Hub, Sitecore, and frontend foundations stand up — the window where the design system's tokens, themes, and core components have to harden.
  • Design system complete — the hard date for the system. SPRINT 2 · 9 AUG 2026
  • Design system sign-off (TA, 3-day SLA) — gates all component build. 9 AUG 2026
  • All components signed off by TA — gates build progression beyond Sprint 2. BY 9 AUG 2026
  • First 10 components delivered; QA (Ben, TA) begins. SPRINT 2
  • Content Hub DAM configured; SSO & user profiles. S1–S4
Nov 2026 M3
Build & Migrate
Site-by-site build and content migration on the new stack, with phased releases — smallest sites first, australia.com last. Components must be stable, accessible, and consumable by the build team throughout.
  • 90 components delivered in sprint waves (10–15 per sprint) — each wave needs design QA & sign-off in-sprint. S2–S8 · BY 13 DEC 2026
  • Page templates per site — Signature S3 · Business Events S5–6 · Corporate S7–8. AUG–DEC 2026
  • Phased go-lives begin — Signature S4 · SEP 2026 · Business Events S6 · OCT/NOV 2026 · Corporate S8 · DEC 2026
  • UAT cycle runs continuously. 31 AUG 2026 – 14 FEB 2027
  • Sitecore Search, OneTrust & integrations; CMS 1st training enablement SPRINT 3
Jan 2027 M4
Go Live
Staggered go-live per site and locale, with the design system underpinning every market build.
  • Aussie Specialist launch — UAT sign-off then go/no-go. S11 · 25 JAN – 14 FEB 2027
  • australia.com UAT & sign-off — final and largest site. S10–S11 · BY 14 FEB 2027
  • australia.com go/no-go & cutover — flagship go-live confirmed mid-March 2027. S12–S13
  • Design supports UAT triage — visual parity, accessibility and component fixes on a 3-day sign-off SLA.
Feb 2027 M5
Hypercare
Active monitoring and handover — the system moves into maintenance and governance mode.
  • Hypercare runs ~30 days post australia.com go-live. MID-MAR – MID-APR 2027
  • Design system hands over to governance mode — documentation, change control, and contribution model need to be in place.
  • Adobe licence ends (migration backstop). END APR 2027
What design owes the plan

The design system is a Sprint 1–2 deliverable, not a background workstream. It must be complete and signed off by 9 Aug 2026 — that sign-off gates all component build, and the design-overlap window for component sign-off closes with Sprint 2. From there, 90 components flow through build at 10–15 per sprint, each needing design QA and sign-off inside a 3-week cycle on a 3-day SLA.

Sources · TA Client Dashboard — timeline & key dates ↗ · CMS Migration — sprint plan & deliverables ↗

LIVE

System Progress & Health

A live reading of how far the system is built and how sound it is. The meter tracks overall build progress; the figures beneath it — variables, components, styles — are pulled from the live Figma library and refresh on each daily sync. Foundations are substantially in place; the element and component layers are where the remaining work sits. The dashboard syncs daily, drawing from the connected Figma library, the source-of-truth workbook, the Confluence page, and the project plan.

0 50 100
0%
Design-system build progress
Awaiting first sync Source · live Figma library
Definition of done

A component counts as complete only when all of its variants, every theme, and its documentation are finished. Partial builds report their true partial percentage — never rounded up. For example, Buttons reads as done only once every variant, every theme, and the written documentation are in place; until then it contributes the real fraction it has reached, not a rounded-up figure.

Health flags — what a hygiene pass should clear before the system scales:

  • Scope pollution — a large share of variables are still on ALL_SCOPES, which clutters every property picker. They should be narrowed to their real use (fills, text, gap, radius…).
  • Empty component-token layer — the 08 Component collection exists but holds no variables; component tokens haven't been defined yet.
  • Sparse component documentation — only of component families carry a written description; naming and usage guidance need to catch up to the build.
  • Sound layering — tokens are aliased rather than held as raw values, and theming is cleanly separated across brand modes, locales and breakpoints. The architecture is holding up.
Overall health
Architecturally sound and scalable — the foundation and token layers are mature and well-structured. The open work is breadth, not rework: componentise the remaining elements, populate component tokens, tighten scopes, and document as you go.
The shape of the bet

AI doesn't replace the design team.
It buys back their best hours.

The foundational phase of a design system is where the most consequential decisions get made — governance, accessibility, system thinking, long-term maintainability. It's also where the heaviest, most mechanical work lives: audits, extraction, inventory, scaffolding.

AI takes the mechanical layer. Designers keep the consequential one. If the assistance is pulled, the work continues — slower, heavier, but on the same trajectory.