AI Native UX Workflow

Problem

Developers could implement Cense's interfaces quickly, but not the meaning behind them. Component purpose, data requirements, research findings, and open questions lived in tickets, Figma files, conversations, and scattered docs: nowhere they could reach while building.

Cense turns incomplete crypto-wallet data into evidence bank teams can scan, investigate, and defend. Feature requests arrived deceptively simple: "show token quantities over time," "add the risk score," "surface a wallet warning." A faster design handoff looked like the fix, until the UI could still ship looking right and meaning the wrong thing. That created four distinct failures:

‘The ticket says add the risk score. Matching the component is the easy part. What I can't tell is whether this is a proven risk, a screening signal, or just incomplete data.’

FRONT-END DEVELOPER

Needs the product meaning of a request at the moment of implementation, not only the visual pattern to ship.

‘Every time a developer asks what a label means, the answer is in research, a Figma comment, or my head. By the time I reply, the UI is already in a PR.’

UX DESIGNER

Needs product rationale to reach implementation without routing every front-end decision back through UX.

The design question: How might we make product meaning, research findings, and open questions available at the moment of implementation, without turning UX into an approval bottleneck?

The progression

Eight stages, from a static skill to a live knowledge layer wired into research.

Click through the stages to watch the architecture grow from a static skill into a live knowledge layer.

Approach

1. Starting with a skill

Built a Markdown-based skill for the IDE agent, encoding parts of my UX process as instructions. Before generating code, it made the agent:

1. Clarify the user's goal and the decision the interface should support
2. Inspect the existing codebase and component patterns
3. Identify reuse opportunities
4. Compare a simple, advanced, and visual direction
5. Leave consequential product decisions to the developer

Proved the concept: design reasoning could live inside the dev workflow instead of waiting on a handoff.

2. Discovering the limits of static instructions

The skill became another artifact to maintain: every terminology, behavior, or evidence change meant a manual update. Even when current, developers had to remember it existed and choose to use it. Adoption stayed inconsistent.

The structural flaw: a changing product, encoded in a static document. The skill could teach the agent how to think, not supply the latest facts.

3. Connecting the agent to Figma

Added MCP access to Figma for better visual and structural context, so the agent could reuse existing components instead of inventing new ones.

Figma answered structural questions well: what exists, what variants, what states, where it's used. It couldn't answer the ones that mattered most: why the component exists, which decision it supports, what data must be present, or which research challenges its current behavior.

4. Choosing organizational fit over Claude Design

Evaluated Claude Design, and passed. The company had already standardized on a different LLM environment, so adopting it would've meant separate personal accounts for the team: fragmented tooling, and a workflow dependent on individual access instead of company-supported infrastructure.

Key insight: the best tool isn't the one with the strongest isolated capability. It's the one the whole team can access, govern, and use consistently.

5. Realizing the pixels were not the hard part

An audit showed most components (tables, cards, status indicators) were straightforward. What changed was the meaning of the data inside them.

A risk indicator isn't just an icon and a color; it depends on score source, contributing signals, confidence, wording, and what action follows. The design system already encoded this: color is informative, not advisory; red signals attention, not loss; uncertainty belongs in the copy, not hidden behind a value.

Reframed the problem: the agent didn't need more screenshots. It needed the product's semantic rules and the evidence behind them.

6. Moving the knowledge layer to Notion

Moved evolving UX context into Notion, connected via MCP, as the source of truth for four knowledge types:

The skill became a lightweight orchestration layer, pointing to live sources instead of carrying a stale snapshot. Clean separation: process in the skill, product knowledge in Notion, visual assets in Figma, implementation patterns in the codebase.

7. Treating component usage as a product contract

Documented each component's role, not just its anatomy:

Step through the contract fields to see where visual similarity stops being functional equivalence.

Result: the agent could tell visual similarity from functional equivalence. Two tables might share a layout but serve different purposes, a quick scan versus an auditable investigation, so reusing the shell didn't mean reusing the hierarchy.

8. Connecting implementation to active UX research

The highest-leverage step: linking component guidance directly to the research system.

The Insights database held findings like: risk scores need contributing flags to be trusted; ambiguous labels trigger false alarms for non-experts; summary surfaces carry outsized decision weight; AI can't compensate for missing structured data.

The Questions database captured open unknowns: what evidence makes a risk indicator actionable, what audit traceability requires, which scoring rules need to be configurable.

Connected, the agent could now distinguish a settled rule to follow, a research-backed recommendation, an open question to surface, and a genuine blocker needing a human call.

An illustrative developer story

A developer is asked to add a "medium risk" summary to a wallet page.

The old path: find the status component in Figma, match the color and label, connect the score, ship a PR. Visually consistent, but easy to get the interpretation wrong.

The new path: the agent inspects the component, pulls its usage contract from Notion, and learns risk can't be communicated by color alone, and the copy can't sound like an approval or rejection. It checks research insights (users over-weight an overall score without understanding it; ambiguous labels create unnecessary alarm) and open questions (what evidence do analysts need to trust a risk indicator; what does audit traceability require).

Instead of shipping silently, the agent flags it:

‘The visual component is reusable, but the data isn't yet sufficient for this decision. The score should ship only with its contributing signals, source, and calculation state. Audit traceability is still an open question, review the 'view evidence' interaction before finalizing.’

It proposes two paths:

1. Safe first release: informational score, rationale, and timestamp, no implied recommendation
2. Richer investigation state: evidence, source lineage, and escalation actions, once the open question resolves

Toggle the two workflows: ship a pretty chip, or surface the open question before the PR.

The developer ships the safe version now while the unresolved decision stays visible to UX and Product: a specific blocker, not a vague "needs design review." When research later answers the question, the insight and contract update in Notion, and the next developer inherits that guidance automatically.

The resulting workflow

Feature request → inspect codebase & Figma → retrieve component contract → query insights & open questions → identify assumptions & blockers → propose implementation options → capture the decision & update the knowledge base

The agent acts autonomously on reversible implementation details, but never silently decides data meaning, required evidence, or acceptable uncertainty.

What changed

Challenges

Role

UX Engineer

• Translated the design process

  into a repeatable reasoning framework for an AI agent.

• Defined the questions

  the agent should ask before generating an interface.

• Established documentation standards

  for component purpose, data requirements, edge cases, and evidence.

• Connected interface decisions

  to the needs of analysts, compliance teams, and non-expert readers.

UX Researcher

• Structured the research space

  around validation experiments, open questions, and reusable insights.

• Converted findings into design implications,

  not just interview summaries.

• Surfaced unresolved questions during implementation,

  feeding development back into the research roadmap.

Tooling Architect

• Connected the IDE, Figma, the codebase, and Notion

  through an MCP-based workflow.

• Separated stable reasoning

  (the skill) from frequently changing product knowledge (Notion).

• Defined agent autonomy boundaries:

  when to proceed, when to offer options, when to surface a blocker for human judgment.

Learnings