An agentic UX system that shifted what UX ships into a room.

The UX problem no one was designing for

Most UX work focuses on the interface a user touches. This initiative started with a different question: what is the experience of the people who build that interface? Product managers translating vision into tickets. Designers maintaining consistency across silos. Engineers interpreting Figma under sprint pressure. QA chasing inconsistencies caused by fragmented frontend behavior.

I was leading design across multiple banking domains inside a large-scale enterprise core banking platform — payments, deposits, customer management, billing, taxation, standing orders, pricing, workstation, and more. The organisation already had mature infrastructure: a shared component library (SBNG), a design system, agile delivery, and component-based frontend architecture.

Yet the delivery experience was broken — for everyone in it.

A typical delivery flow:

This produced compounding enterprise-level problems:

• Sprint churn from requirements evolving mid-cycle
• Frontend inconsistency across teams optimising locally
• Repeated clarification loops between PMs, UX, and engineering
• Designers consumed by handoff support instead of design work
• Engineers rebuilding similar UI logic across features
• QA inconsistencies caused by divergent implementation behavior
• Accessibility treated as a retrofit, not a baseline

The insight: AI quality is a context architecture problem

Most AI-assisted workflows obsess over prompts. I focused on structured organisational intelligence.

The breakthrough was treating an AI execution layer not as a code generator but as a domain-aware delivery system — one capable of consuming UX heuristics, design system rules, persona research, domain workflows, architectural dependencies, edge cases, and accessibility standards simultaneously and consistently.

If I could structure everything the organisation already knew into a form a system could navigate, the pipeline wouldn't just generate faster code. It would generate correct code — code that already understood the guardrails, the patterns, the edge cases, and the accessibility requirements before a single developer looked at it.

This was a UX problem in its purest form: how do you structure complex, fragmented human knowledge into something a machine can act on — without losing fidelity, trust, governance, or the human judgment that makes enterprise software safe?

The system: an end-to-end agentic UX execution platform

I architected the pipeline as a layered system — every layer earning its keep, every layer governed. The full repository structure looked like this:

enterprise-ux-pipeline/
│
├── .kiro/                                ── BRAIN  (always-loaded behavioral rules)
│   ├── agents/sbng-companion/            ── SBNG component library agent + conventions
│   ├── steering/                         ── UX principles, design system, gold standards
│   │   ├── enterprise-ux-pipeline.md
│   │   ├── sbng-showcase.md              ── Single source of truth: component inventory
│   │   ├── zeroheight-guidelines.md      ── Design system guidelines (Zeroheight)
│   │   └── Guardrails/
│   │       ├── accessibility.md          ── WCAG 2.1 AA enforcement
│   │       ├── design-guidelines.md      ── Table/form/list conventions
│   │       ├── quality-first-generic.md  ── No tradeoffs · Code hygiene
│   │       ├── structure.md              ── Project structure conventions
│   │       └── tech.md                   ── Tech stack rules
│   └── skills/                           ── Migration + audit skills (e.g. ptable→mattable)
│
├── intelligence/                         ── REUSABLE INTELLIGENCE (referenced by ID)
│   ├── personas/                         ── Persona registry · banking 2026 archetypes
│   ├── patterns/                         ── sb-data-table, sb-forms, sb-form-stepper, sb-consult
│   ├── workflows/                        ── approval-flow, bulk-actions, search-filter
│   ├── shared-components/                ── Component API contracts
│   ├── rules/global/ux-rules.json        ── Enterprise UX enforcement rules
│   └── contracts/templates/              ── API contract templates (e.g. crud-list)
│
├── domains/                              ── 22 ENTERPRISE DOMAINS
│   ├── AIC · BILL · CAM · CARE · CPTF · CRD · CTM · DCM · IASB · IPCE
│   ├── MKTP · MPCE · OSAAM · PAYCE · PRICE · RTPM · SHARED · STORM
│   └── TASK · TAX · TDM · TRANSVERSAL · WKS
│       └── domain.json + architecture + reference docs
│
├── feature-packs/                        ── DELIVERABLES  (one folder per Jira ticket)
│   ├── PRICE-4521-commission-list/       ── docs-only state (design phase)
│   └── PRICE-5100-commission-family-crud/── fully generated, production-ready
│
├── runtime/                              ── LIVE ANGULAR PREVIEW APP
│   ├── core/mock-api.service.ts          ── Mock API interceptor
│   └── preview/preview-shell.component   ── Locale + viewport controls for PMs
│
├── validations/                          ── AUTOMATED GOVERNANCE
│   ├── validators/                       ── Structure + i18n validators
│   └── schemas/feature-pack.schema.json  ── JSON schema enforcement
│
├── scripts/                              ── PIPELINE AUTOMATION
│   ├── scaffold-feature-pack.js          ── `--jira PRICE-5100 --feature commission-family`
│   ├── validate-feature.js               ── Run full validation suite
│   ├── export-feature.js                 ── Package for developer download
│   ├── create-snapshot.js                ── Version snapshot
│   └── lint-structure.js                 ── Repo structure lint
│
├── exports/                              ── Packaged downloads
└── docs/                                 ── git-strategy.md · scalability.md

The full pipeline at the repo level. Every folder is a UX decision — what to encode, what to enforce, what to leave to human judgment.

Four layers of design intelligence

feature-packs/PRICE-5100-commission-family-crud/
├── feature.json                         ── Manifest · Jira link · status · execution version
├── README.md                            ── Overview + developer quick-start
│
├── requirements/                        ── UX DISCOVERY INPUT
│   ├── requirement.md                   ── User story · acceptance criteria · API
│   ├── initiative-sheet.md              ── Business value · KPIs · timeline
│   └── tech-constraints.md              ── API limits · SBNG gaps · permissions
│
├── source/                              ── DESIGN INTENT (drives generation)
│   ├── ux-goals/goals.json              ── 4 measurable goals
│   ├── business-rules/rules.json        ── 7 rules
│   ├── edge-cases/edge-cases.json       ── 9 enumerated edge cases
│   ├── workflows/workflow-refs.json     ── CRUD flow definition
│   └── prompts/generation-prompt.md     ── Full generation prompt
│
├── generated/                           ── PRODUCTION-READY ANGULAR
│   ├── models/commission-family.model.ts          ── Typed interfaces
│   ├── constants/commission-family.constants.ts   ── Patterns · test IDs · error codes
│   ├── services/commission-family.service.ts      ── HTTP CRUD service
│   ├── components/
│   │   ├── family-list/                ── List page · signals · MatTableDataSource
│   │   ├── family-create/              ── Create form · reactive · typed
│   │   ├── family-edit/                ── Edit form · prefill · code disabled
│   │   └── family-delete-dialog/       ── Confirmation · focus on Cancel · warn button
│   ├── routing/commission-family.routes.ts        ── Lazy-loaded · permission-aware
│   └── i18n/en.json                                ── 18 translation keys
│
├── contracts/
│   └── commission-families-api.json    ── Full API contract (GET/POST/PUT/DELETE)
│
├── configs/                            ── AUTOMATED GOVERNANCE
│   ├── validations/ux-validation.json  ── UX rules audit: PASS
│   ├── accessibility/a11y-audit.json   ── WCAG AA audit: PASS
│   └── i18n-validation/i18n-check.json ── 18 keys · 0 missing · 0 hardcoded
│
├── docs/                               ── HANDOFF
│   ├── design-handoff.md               ── HTML structures · routing · nav flow
│   ├── ux-specs.md                     ── Persona · goals · edge cases · keyboard
│   ├── component-inventory.md          ── SBNG + Material components used
│   └── i18n-keys.md                    ── Complete key structure
│
└── executions/
    └── v0.1.0-1/snapshot.json          ── Versioned execution record

Designing governance into the system

Enterprise AI without governance is enterprise risk. Three governance systems were built directly into the pipeline — not bolted on as review processes.

How delivery changed

We stopped walking into reviews with static prototypes. We walked in with working systems that could be altered at a single click.

Empowering Product Managers

Equipped with the KIRO brain, Product Managers were empowered to directly generate and iterate on screens at runtime. Product vision could now be presented with unprecedented clarity, as requirements were already refined against functioning interfaces. By shifting validation to the earliest possible stage, downstream change requests dropped significantly.

Team and organisational impact

I initiated and architected this pipeline solo, as a strategic initiative running alongside my team's product delivery work. The rollout, however, was deliberately collaborative — because adoption, not invention, is the harder design problem.

The pipeline never replaced my team's product work; it accelerated it. While I led the strategic initiative, my designers continued shipping incremental product features for our banking domains — and increasingly used the pipeline themselves to move faster. Design leadership, for me, meant making the entire system better, not just the work I personally touched.

What stayed human — by design

The pipeline was never about removing people. It was about directing human attention toward work that required human judgment — and designing the trust boundary deliberately.

What designers became responsible for was the quality of intent— how clearly we could articulate user needs, system behavior, and edge cases. The pipeline amplified the precision of UX thinking. It did not replace it.

Impact

What this changed about how I think about UX

As implementation becomes increasingly automated, the role of UX expands upward:

• Systems thinking — designing delivery frameworks, not just screens
• Intent architecture — structuring what users need into machine-consumable clarity
• Trust design — deciding what stays human, and defending why
• Organisational alignment — synthesising siloed knowledge into shared intelligence
• Strategic evangelism — making the case for UX at the system level, not the feature level

The new bottleneck is not implementation speed. It is the ability to understand what users actually need, structure that intent clearly, and align organisations around it before a single line of code is written. That is the work UX leadership exists to do.

"We stopped entering reviews with static prototypes. We entered with working systems capable of evolving in real time."

Reflection

The hardest part of this project was not building the pipeline. It was understanding the organisation well enough to build it correctly — synthesising architectural diagrams, domain flows, business rules, and component patterns from teams who had never needed to share that knowledge in one place before.

Preventing hallucinations required sustained governance: structured guardrails, automated validation, runtime preview, and a human review step at every push. Governance wasn't a constraint on the system. It was a feature of it.

The future of enterprise UX is not faster wireframes. It is the ability to transform human intent into executable systems — and to design those systems with the same rigour, empathy, and craft we bring to the interfaces they produce.