Agentic AI
·
Design System
Building the Invisible Infrastructure of Trust
A design system built from zero for an AI-agentic workflow platform engineered to feel equally trustworthy to a CFO who's never run a query and a data scientist who questions everything.
MY ROLE
Senior Product Designer
DURATION
5 Months
OUTPUT
Figma System + Dev Handoff
Type
0 → 1 Design System
0 → 1 system build
3 layer architecture
150+ component groups
CFO to data scientist range
AI assisted throught
A product without a shared language
TransOrg IQ was being actively built with no design system no shared tokens, no component library, no documented patterns. Every screen was solving problems that had already been solved elsewhere.
Zero
Shared tokens, components, or documented patterns at project start
Every screen designed in isolation
4
Distinct, high-complexity surface with no visual system to lean on
Chat, Agent visualisation, dashboards, decision screen
User 1: Power Users
Highly Technical
Analytics teams
Know exactly what good data visualization looks like. Apply professional skepticism to any AI-generated analysis. Will notice immediately if something is technically imprecise.
"A cluttered or inconsistent interface only increases their doubt in the output."
User 2: Decision Makers
Non - Technical
Marketing managers
Senior executives making budget and performance decisions. Have never run a SQL query. Need every screen to feel immediately legible and trustworthy they're evaluating the output, not the methodology.
"Expects the same polish from a data tool as the enterprise software they already pay for."
Design debt
Every new feature re-solved problems already solved elsewhere debt was compounding before the product had shipped its first major release
Handoff friction
Developers were making interpretation calls that should have been documented decisions handoff was slow and conversation-heavy
Trust at stake
The AI agent visualization - the thing that builds trust in an AI system had no visual language to lean on at all
No legacy to untangle. No system to learn from, either.
Building a system for a product that doesn't have one is a different problem than retrofitting one. Every foundational decision carries more weight there's nothing to react against.
Approach
Before the first token
01
Mapped every interaction surface before touching a component - chat interface, AI agent workflow visualisation, data dashboards, decision-making screens, admin panel. Each had its own UX demands that needed understanding before deciding what the system should support.
02
Identified the chat interface as the most cognitively loaded screen in the product multiple action options at any point in a conversation, with real risk of overwhelming the user without careful constraint.
03
Studied reference systems built for technical enterprise audiences:
Linear
How handles density without clutter
Notion
How flexes across content types
Looker/Tableau
How handles data-viz UI without sacrificing usability.
Build
Four stages - AI woven in where it actually helped
Stage 1
Brand & Foundation
Color, type, spacing, stroke tokens - semantic naming, WCAG AA checked
Foundational decisions
Stage 2
Core components
150+ components groups - buttons, nav, inputs, icons, built in dependency order
Variants & layout scaffolding
Stage 3
Complex patterns
Chat interface, agent decision flow, dashboards - assembled from stage 2.
Flow & interaction logic
Stage 4
Handoff docs
Usage guidelines, do/don't examples, token to CSS mapping for engineering.
AI + Git - Docs & dev mapping
Figma
Generated base variants & auto-layout cut scaffolding time ~40% across 15 component groups
AI (claude)
Wrote component documentation and usage guidelines across all handoff docs
Github
Mapped token variables to CSS custom properties for the engineering handoff
Token architecture, component hierarchy, and every interaction decision were made manually AI accelerated production volume in Stages 02 and 04 only, never judgment.
UX challenges
The hard part
01
Chat threads aren't messages they're summaries, charts, agent logs, and decisions, all in one view
Strict content hierarchy: text response on top, viz secondary, decisions contained, agent log collapsible by default.
02
First chat version gave users too many visible actions at once cognitive overload, confirmed in early review
Reduced default visible actions, moved secondary options behind a "more" menu, grouped AI output types visually.
03
Nav panel had to serve standard users and admins differently without feeling like two products
Responsive panel icon rail to full label state with admin-only items (metrics, reports) appearing contextually.
Tradeoff
Call tht shaped everything after it
Component first VS Token first
System architecture · Build order
Considered
Component first
Build components immediately, extract shared tokens from them later once real usage patterns emerge across the product.
Chosen
Token first
Lock the entire foundation layer: color, type, spacing, stroke before building a single component.
What this bought us: Without a stable token layer, every component would need rebuilding whenever a brand or theme decision changed downstream. Token-first eliminates that rework at scale a single edit at the source, not a manual sweep across 15 component groups.
What it Cost us: Delayed visible output by 3–4 weeks. Stakeholders saw zero components while the token system was being built requiring active, ongoing expectation management to hold the line on the approach.
Three layers. built in order.
Foundation → Components → Patterns. Each layer had to be load-bearing before the next one started — the screens below are pulled directly from the shipped Figma system.
01
Foundation · Tokens & Variables
The Non-Negotiable base
Color, typography, spacing, radius, stroke, and effects all built as Figma variables, not static styles, named semantically (color/primary/default) rather than by value. A global color update or spacing adjustment became a single-source edit instead of a manual sweep across dozens of files. Every color was checked against WCAG AA contrast requirements.
Scale
9 typography styles, 12 spacing steps (2px–64px), full light/dark token pairs for every color role.
Design Decision
8-point grid for every spacing value eliminated the "is this 12px or 14px?" conversation at handoff entirely.
Interview talking point
Explain why token-first was a tradeoff, not a default see the tradeoff card in Section 02.
02
Components
The building blocks
Built in dependency order atoms first, then molecules, then organisms. The master button system covered six types across six states each, fully variable-driven. The navigation panel was built responsive collapsible to an icon rail, expandable to a full labeled view, with admin-only items appearing contextually.
Hardest component
Chat interface the challenge wasn't building it, it was deciding what the components even were. A thread isn't a messaging app.
Design Decision
Every icon ships with default, hover, active, and disabled states baked in no one-off states created downstream.
Interview talking point
The nav panel went through 2 iterations based on product feedback speak to how admin-only surfacing changed.
03
Patterns · Assembled flows
Where components become trust
The AI agent decision flow and data-insight surfacing the screens where users decide whether to trust what the AI found. Built with progressive disclosure throughout: a clear primary finding always visible, supporting detail available on expand, raw output (SQL, Python) legible in purpose-built code blocks for the technical half of the audience.
Pattern shown
Insight cards surface what the AI found (new insights, anomalies, data quality issues) with severity-coded labels scannable before reading detail.
Design Decision
Code blocks were purpose-built for AI response surfaces SQL and Python rendered in a legible, developer-readable format, not a generic text card.
Interview talking point
This is where the Aesthetic-Usability Effect mattered most explain why visual polish here directly affects whether a skeptical data scientist trusts the output.
Miller's law
Max 3 action options per interaction moment in chat secondary and tertiary options accessible, never immediately visible.
Progressive discloser
Primary output always visible, supporting detail always available never forced on CXO users who need answers, not methodology.
Usability effect
For senior executives trusting an AI with business decisions, visual polish makes outputs feel more credible not a nice-to-have.
From disconnected screens to one product
Measured after the restructured chat interface, decision screens, and navigation system shipped.
Task completion and feature adoption are measured product analytics, tracked pre/post-system rollout. Handoff speed and UI consistency are qualitative outcomes observed by the design and development teams.
Measured · Product analytics
+18%
Task completion speed
From the restructured chat interface and decision screens fewer unnecessary decisions per query.
Measured · Product analytics
+22%
Feature adoption rate
From improved navigation structure features that needed "knowing where to look" became discoverable.
Qualitative · Dev team
↓
Design to dev revision loops
Token-driven documentation let developers implement independently significantly fewer back-and-forth cycles.
Qualitative · Dev team
1 of 1
Product, not a scren collection
Before: felt like screens that shared a URL. After: something a CFO could trust with a serious question.
What help up. What i'd push earlier.
What I'd do differently
Run a component usage audit at the midpoint, not just at handoff. About three months in, some carefully built components weren't being used as intended not from misunderstanding, but because the product's needs had evolved since I designed them. I'd also push for real CFO/CXO testing on the chat interface earlier the cognitive overload in version one wasn't subtle, and a single test session would have surfaced it before a full redesign cycle was needed.
Core learning
Document the "why" as rigorously as the "what." The handoff specs were precise about values and states, but not always about the reasoning behind a decision what alternative was rejected, and why. That context is what lets a system survive contact with a developer who joins six months later. A system without its reasoning attached is just a style guide that will eventually drift from the product it was built for.