The design-engineering
boundary is where I work.

Axion by Downer is the field service platform Downer runs across their Australian operations - the software thousands of tradespeople open on their phone every morning to see the day’s orders, log hours, raise invoices, complete audits, and sign off jobs. Downer is one of Australia’s largest services companies, so this platform runs an operationally critical part of their business. Insight was engaged to build it from the ground up, replacing the legacy MyWork system. I’ve been leading design engineering across React and React Native - building the workflow where coding agents ship components against a design system that holds them to it. Storybook as the verification layer, tokens as the vocabulary, spec files the agents read every session.

The working model

What I’ve built alongside it

How the work was made

The full workflow is written up on Insight’s engineering blog:Inside my AI design engineering workflow (opens in a new tab) - Storybook with MCP, axe-core gates, and Claude Code generating against a real design system. 14 May 2026.

The AxionConnect design engineering workflow, in nine parts. The model has held across a year of continuous delivery.

1. 01

   Context architecture

   CLAUDE.md at the root is ten bytes: an @ import directive that pulls in AGENTS.md. The instructions live in a scoped hierarchy beneath it, so an agent working in src/frontend picks up frontend conventions without loading architecture docs it doesn’t need.

   Because the substance sits in the vendor-neutral AGENTS.md format and CLAUDE.md is only an adapter, one repository serves three agent harnesses without duplication. Four skills carry the domain knowledge an agent can’t infer from the codebase, and two plugins come from team marketplaces - one published by the backend lead. The AI tooling here is shared delivery infrastructure, not a personal setup.

   CLAUDE.md

   @AGENTS.md

   AGENTS.md

   # AGENTS.md
   ## Scope
   Root instruction layer for coding agents working on the frontend.
   ## Directory hierarchy
   - `docs/AGENTS.md` — documentation conventions
   - `src/frontend/AGENTS.md` — frontend implementation
   - `src/frontend/design/AGENTS.md` — design conventions
   - `src/frontend/shared/tokens/AGENTS.md` — token package
   - `docs/architecture/AGENTS.md` — architecture
   ## Rules
   - All colour and spacing values reference `@axion/tokens`
   - New components start in `_backlog/`, promote to `ui/` after review
   - Design conventions live in `src/frontend/design/AGENTS.md`, invoked contextually
   - `pnpm test` and `pnpm typecheck` before requesting review
   ## Portable across harnesses
   Read by Claude Code (via CLAUDE.md), OpenCode, and GitHub Copilot.

   CLAUDE.md uses the @ import directive to pull in AGENTS.md. Ten bytes of adapter, one substantive instruction file, three agent harnesses that can read it.

   Design conventions are a file in that hierarchy rather than a wiki page next to it.src/frontend/design/AGENTS.md is what an agent reads before it writes a component, and the token rules in it are the same rules a reviewer would apply by hand.

   design/AGENTS.md

   # design/AGENTS.md
   ## Scope
   Design conventions for the frontend. Referenced by src/frontend/AGENTS.md
   for design-specific work, and by the axion-design skill for contextual invocation.
   ## Token discipline
   - All colour references use semantic tokens from `@axion/tokens`
   - Prefer `--color-text-primary` over raw hex or primitive tokens
   - Spacing values use the token scale, never arbitrary values
   - Typography classes come from the token type scales
   ## Component composition
   - Components read from tokens, never define their own colour or spacing
   - Layout primitives (Stack, Cluster, Grid) handle spacing between components
   - Interactive states (hover, focus, active) reference interactive tokens
   ## Accessibility
   - Text uses a11y-safe semantic tiers (--color-strong, -default, -muted, -disabled)
   - Interactive elements meet WCAG 2.2 AA contrast requirements
   - Focus indicators use --color-focus-ring at 2px offset
   ## Motion
   - prefers-reduced-motion disables all decorative animation
   - Functional motion (loading, transitions) reduces duration by 50% under reduced motion

2. 02

   Discovery inputs

   Design decisions come from three sources the agent can read: thirteen field specification spreadsheets, one per section of the order detail screen, giving every field its source in the legacy system and its business rules; the architecture documentation; and sixteen recorded client sessions across six months.

   The transcripts are the richest source of intent, and they are deliberately gitignored. Discovery material informs the work without entering the repository. Decisions that come out of it are recorded separately in docs/wiki/Design-Decisions/.

3. 03

   Specification before implementation

   Work moves through a codified command chain rather than ad-hoc prompting - twelve slash commands in .claude/commands/, with specify,plan, refine and implement as the spine.

   The sequencing is the point. The expensive failure mode on this project was building a screen, showing it, and discovering the information architecture was wrong. Specifying and refining first moves that discovery to the cheap end.

   # The AxionConnect workflow: specify before implement
   $ /specify order-detail-page
   $ /plan order-detail-page
   $ /refine order-detail-page
   $ /implement order-detail-page
   # Supporting commands
   $ /analyse        # Analyse existing code
   $ /troubleshoot   # Debug specific issues
   $ /code-review    # Review changes
   $ /review-pr      # Review pull requests
   $ /security-audit # Security review
   $ /bff-e2e        # End-to-end tests
   $ /apim-sync      # API management sync
   $ /save           # Save session state

4. 04

   Storybook as the substrate

   Storybook isn’t a documentation site on this project. It’s the one surface four separate concerns run against: every client review session is conducted against live Storybook, axe checks run on every story as it’s built, the coding agent reads stories directly through addon-mcp, and Playwright tests run against stories rather than application routes. Six months of review screenshots in the project archive are captures of localhost:6006.

5. 05

   One component, two runtimes

   The mobile package runs two Storybook configurations against the same components: one on-device React Native, and one running those components through react-native-web with an Expo native-module stub layer and a full babel and webpack bridge.

   The web configuration exists so mobile components can be reviewed in a browser, in a client call, without a device or simulator in the loop. Building that bridge was a cost paid once to make every subsequent mobile review frictionless.

6. 06

   Verification

   Layer	Tool	Scope
   Component interaction	Playwright 1.58	Web, against Storybook
   Unit	Vitest 4.1	Web, document viewer, validators
   Mobile unit	Jest (jest-expo)	React Native
   Accessibility	axe via addon-a11y	Every story
   Security	semgrep scan --config auto	Whole repo
   Dependency audit	scripts/audit.mjs	Runs on every postinstall

   The security scanning is worth noting: the audit script is wired intopostinstall, so it runs on install rather than waiting for anyone to remember it.

7. 07

   The promotion gate

   src/frontend/_backlog/ holds early component work that isn’t yet part of the system. Components sit there until they meet token alignment and pass review, then they’re promoted into ui/ or patterns/.

   This is what keeps the design system coherent under delivery pressure. A component built quickly for one screen doesn’t silently become a system primitive; it waits until it earns the promotion.

8. 08

   Shipping

   Of the six Azure Pipelines, the one that matters here isstorybook-pipeline.yml. The design system builds and publishes as its own artefact, alongside the web, mobile, BFF API, event processor and Auth0 tenant pipelines. It ships like a product, not as a by-product.

9. 09

   The client loop

   Working sessions ran roughly weekly, plus near-daily short calls. The pattern that emerged, and the one I’d carry to another engagement: bring options rather than a proposal, and name the trade-off of each before anyone asks.

   In one session on an unresolved information architecture problem I brought three built concepts. Three stakeholders held three different positions at the start of that call; it closed with a decision and one refinement in under twenty minutes. Say the weakness out loud, and clear feasibility with engineering first, so the design conversation is never blocked on a technical unknown.

What this workflow doesn’t do

Recognition

Richard Funston (IT Solution Delivery Manager, Downer), across a year of active review sessions:

Stack and tooling

Application

React, React Native, Expo, TypeScript, Storybook 10, @axion/tokens

Verification

Playwright, Vitest, Jest, axe-core, semgrep

Delivery

Azure Pipelines, Azure DevOps

Agent tooling

Claude Code, OpenCode, GitHub Copilot, Storybook MCP, ADO MCP, spec-pilot, context-mode

What I took away

The diversity of users the platform needed to serve

• External advisersCreating agreements, generating invoices, capturing signatures, and managing KYC across 350 to 400 practices.
• Internal relationship managersManaging adviser and practice relationships with a full view individual advisers cannot see.
• Compliance and audit teamsSupervising compliance activity and vetting new advisers across the network.
• Operations teamsRouting workflows, allocating activities, and tracking SLAs across every process in flight.
• Telephony and contact centreHandling inbound queries with quick context on any conversation at hand.
• Audit and vettingIndependent review of adviser practices, compliance evidence, and client outcomes.

The unified experience thesis

Integration as UX scope

What shipped

• 2,500

  External practice users (2,000-2,500)

• 400

  Practices served (350-400)

• 5 → 1

  Systems consolidated

• 100K+

  Client relationships

Stack and tooling

Platform

Microsoft Dynamics 365 with Power Pages

Integrations

GreenID (identity verification), DocuSign (e-signatures), QValent (payment collection), CommPay (payment settlement)

Frontend

Power Pages with custom components

Design

Figma with production-ready developer specifications

Discovery artefacts

Persona workshops, current-state and future-state journey maps, integration architecture, role-based access model

What I took away