The business context
AI increased delivery speed—and the speed of inconsistency.
As designers, product owners, developers, and AI tools all became capable of creating interfaces, UX decisions moved beyond the traditional Figma-to-development handoff.
A component library alone could not tell teams which pattern fit a workflow, which domain rules applied, what context an AI tool needed, or how generated work should be evaluated. Without explicit guidance, AI produced plausible generic UI: invented components, hardcoded values, missing states, and inaccessible interactions.
I reframed the design system as operational context—a shared source that could travel through discovery, requirements, design, generation, development, and review.
The goal was not to automate design judgment. It was to give every participant the same starting constraints, vocabulary, building blocks, and validation criteria.
The constraint
Different roles needed different workflows—not different truth.
Product owners needed discovery guidance and acceptance criteria. UX designers needed research, pattern, testing, and audit support. Developers needed implementation rules and self-validation. AI agents needed concise persistent context, routing, and explicit rule identifiers.
The model also had to survive a design-system transition, support multiple AI environments, cover specialized drilling interfaces, and distinguish required standards from contextual design judgment.
What I did
Turned design-system knowledge into a delivery system.
- Expanded the shared pool.Foundations, tokens, component selection, page patterns, templates, accessibility, domain guidance, prompts, mappings, and audits became one model.
- Created role-specific entry points.Product, UX, and development follow different paths through the same underlying standards.
- Made context native to AI workflows.Always-active rules, agent routing files, and deep context packages let governance travel with the task.
- Started from approved compositions.Full-page examples, framework shells, templates, recipes, and decision trees replaced blank-prompt invention.
- Made rules traceable.Rule IDs connect acceptance criteria, AI prompts, implementation reviews, and audit findings.
- Preserved domain knowledge.Real-time data, alarm states, shift handover, units, dense dashboards, and field constraints extend generic enterprise guidance.
Selected interface work
Governance designed as a usable product.
The playbook is not a folder of standards. It gives each role a clear place to begin, connects guidance to working templates, and makes compliance visible through the same rule language used in requirements and AI context.
Choose a task to load the right guidance, patterns, and AI context.
Representative reconstruction. Rule examples are generalized and no proprietary prompt content is reproduced.
Outcome
A durable model across two system generations.
The first generation proved that a shared pool could serve human and AI workflows. When Tecton became the required enterprise foundation, I translated the operating model rather than discarding it.
The toolkit now provides role guidance, page-template categories, context packages, domain-specific patterns, decision trees, and a documented audit model. Adoption is established across Design of Service, Business Insights, Geosteering, RoxC, and the Collaboration Dashboard.
Quantitative reductions in cycle time or review issues have not yet been measured. The defensible outcome is organizational reach and the existence of a working, reusable governance infrastructure.
What I would do differently
Instrument the operating model from its first release.
I would establish lightweight usage, compliance, and review-cycle measures alongside the first toolkit release. That would show which guidance teams actually use, where AI output continues to fail, and which governance assets create the most delivery value—before the library grows broader.