AI Native UX Workflow

Overview

How I connected front-end development, component guidance, and ongoing UX research so developers could make better product decisions while they built.

Cense helps bank teams understand a client's crypto wealth. Its interfaces need to turn complex, incomplete, and sometimes ambiguous wallet data into evidence that analysts can scan, investigate, and defend.

The original challenge appeared to be a design handoff problem: developers needed faster UX guidance when building the front end. I first addressed it with an AI skill, then connected the development environment to Figma. Both approaches helped, but neither solved the deeper issue.

The real constraint was not pixel complexity. It was context.

A table, card, badge, or chart was usually straightforward to build. The difficult questions were what data belonged inside it, what a label meant, which state required attention, what evidence a user needed before acting, and whether an unanswered research question should block the implementation.

I therefore moved the source of UX guidance into Notion and connected it to the development workflow through MCP. Component documentation, design-system rules, research insights, and open questions became a live knowledge layer that the agent could consult while a developer was working.

The resulting workflow did more than generate UI. It helped the team decide what the UI should communicate and exposed uncertainty before it became code.

The progression

The work moved through eight stages—from a static skill to a live knowledge layer connected to research.

Problem

Product requests often arrived in deceptively simple language: “show token quantities over time,” “add the risk score,” or “surface a wallet warning.” A developer could implement any of those requests quickly, but the request did not explain what the user needed to understand or decide.

For example:

• Was the analyst checking an exact historical value or looking for a trend?
• Did “high risk” describe a proven risk, a screening signal, or incomplete data?
• Which evidence made a score actionable?
• Was a table more appropriate than a chart?
• Did an existing component support the same purpose, or did it merely look similar?
• Was the necessary data available and reliable?

Without immediate UX context, developers had to reconstruct the product rationale from tickets, Figma files, conversations, and the codebase. This created cognitive load and encouraged teams to settle on a UI direction before the user need was clear.

The UX Research space in Notion was already intended to reduce guesswork and unnecessary iteration. It organized validation experiments, current questions, and recent insights as shared product knowledge. Separately, the UX Design space held the design system and product guidance. The missing piece was bringing that knowledge into the moment a front-end decision was being made.

Approach

1. Starting with a skill

My first solution was a Markdown-based skill for the AI agent in the developer's IDE. It translated parts of my UX process into instructions the agent could follow.

Before generating code, the skill asked the agent to:

1. clarify the user's goal and the decision the interface should support;
2. inspect the existing codebase and component patterns;
3. identify opportunities to reuse or extend an existing component;
4. compare a simple, advanced, and visual direction; and
5. keep the developer responsible for consequential product decisions.

This was a useful proof of concept. It showed that design reasoning could be embedded in the development workflow instead of waiting for a separate handoff.

2. Discovering the limits of static instructions

The skill soon became another artifact I had to maintain.

Every change to terminology, component behavior, risk language, or research evidence required a manual update. Even when the file was current, developers had to remember that it existed and deliberately use it. Adoption remained inconsistent.

The problem was structural: I had encoded a changing product in a static document.

The skill could tell the agent how to think, but it could not reliably supply the latest facts. It also placed the maintenance burden on UX; every source change had to be copied into a second location.

3. Connecting the agent to Figma

I next explored MCP connections to Figma. This gave the agent access to the design library and made it easier to inspect components, variants, layout patterns, and design tokens.

That improved visual consistency. Instead of inventing a new pattern, the agent could find an existing component and use it as a starting point.

But Figma mainly answered questions about structure and appearance:

• What component exists?
• What variants does it have?
• What are its dimensions, styles, and states?
• Where has it been used?

It did not consistently answer the questions that mattered most:

• Why does this component exist?
• Which user decision does it support?
• What data must be present before it is safe to use?
• What should happen when data is missing or uncertain?
• Which research findings challenge its current behavior?

4. Choosing organizational fit over Claude Design

I also considered Claude Design as part of the workflow, but did not adopt it. The company had already selected a different LLM environment as its standard. Using Claude Design would therefore have required other team members to create and maintain their own personal Claude accounts for work.

That would have introduced avoidable barriers to adoption, fragmented the team's tooling, and made the workflow dependent on individually managed access rather than a company-supported setup. For the system to become part of everyday development, it needed to work within the LLM environment the organization had already chosen.

This clarified an important product constraint: the best solution was not simply the tool with the strongest isolated design capability. It was the one the wider team could access, govern, and use consistently.

5. Realizing the pixels were not the hard part

An audit of the product patterns changed the direction of the work. Most components were not especially complex. The same table, card, status indicator, or disclosure pattern could support many parts of the product.

What changed was the meaning of the data inside them.

A risk indicator, for example, is not only an icon and color. Its usefulness depends on the source of the score, the contributing signals, the confidence or coverage, the wording, the user's level of crypto knowledge, and the action available after the signal appears.

The design system already reflected this distinction. Color is informative rather than advisory; red is reserved for attention and escalation, not financial loss; risk should be communicated with a consistent combination of color, shape, and text; and uncertainty must be expressed in the wording instead of being hidden behind a value.

This reframed the problem. The agent did not need a larger collection of screenshots. It needed access to the product's semantic rules and the evidence behind them.

6. Moving the knowledge layer to Notion

I moved the evolving UX context into Notion and connected it to the developer environment through MCP.

Notion became the source of truth for four kinds of knowledge:

• Design rules:

  durable principles for color, copy, values, risk, uncertainty, spacing, and interaction.

• Component contracts:

  what a component is for, when to use it, required data, variants, edge cases, and known constraints.

• Research insights:

  findings that could change the way information should be presented or explained.

• Open questions:

  uncertainties still being researched that a developer should not silently resolve in code.

The agent could now retrieve the latest context when needed instead of carrying a copied snapshot inside the skill. The skill became a lightweight orchestration layer: it defined the reasoning process and told the agent which live sources to inspect.

This separation reduced duplication. Process lived in the skill; changing product knowledge lived in Notion; visual assets lived in Figma; implementation patterns lived in the codebase.

7. Treating component usage as a product contract

The next step was to document more than the anatomy of a component. Each component description needed to explain its role in the product.

This made component reuse more deliberate. The agent could distinguish between visual similarity and functional equivalence.

Two tables might share the same layout but serve different purposes: one could support a quick case scan, while another could support a detailed, auditable investigation. Reusing the shell might be appropriate; reusing the information hierarchy might not be.

8. Connecting implementation to active UX research

The most valuable step was linking component guidance to the research system itself.

The Insights database contained findings such as:

• risk scores need contributing flags to be trusted and defended;
• ambiguous labels can create false alarms for non-expert readers;
• the first pages or summary surfaces carry disproportionate decision weight;
• dense reports need progressive disclosure;
• AI cannot compensate for missing structured data; and
• case history should survive handoffs and staff turnover.

These were not abstract design principles. Each finding implied changes to hierarchy, copy, states, or data requirements.

The Questions database captured what the team still needed to learn, including which evidence makes a risk indicator actionable, what traceability an audit requires, where handoffs happen, and which scoring rules need to be configurable.

By connecting both databases to the development workflow, the agent could distinguish among:

• a settled design rule that should be followed;
• a research-backed recommendation that should influence the solution;
• an open question that should be surfaced; and
• a genuine blocker that needed a human decision.

An illustrative developer story

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

Previously, the likely path was straightforward: find the status component in Figma, match the color and label, connect the score, and open a pull request. The interface would be visually consistent but could still create the wrong interpretation.

With the connected workflow, the agent first inspects the existing component and retrieves its usage contract from Notion. It learns that risk cannot be communicated through color alone and that the product must avoid language that sounds like an approval or rejection.

It then queries the research insights and finds two relevant patterns: users put significant weight on an overall score without always understanding it, and ambiguous risk labels can trigger unnecessary alarm. The current guidance recommends showing the contributing indicators and a plain-language rationale.

Next, the agent checks the open research questions. One asks what evidence and context analysts need before they can trust and act on a risk indicator. Another asks what traceability is required for second-line review or audit.

Instead of silently completing the card, the agent tells the developer:

The visual component is reusable, but the available data is not yet sufficient for the intended decision. The score can be displayed only if we also expose its contributing signals, source, and calculation state. Audit traceability remains an open research question, so the interaction for “view evidence” should be reviewed before implementation is finalized.

The agent proposes two paths:

1. a safe first release that presents the score as informational, includes its rationale and data timestamp, and avoids an implied recommendation; or
2. a richer investigation state that adds evidence, source lineage, and escalation actions after the research question is resolved.

The developer can continue with the safe parts of the front end while the unresolved decision is visible to UX and Product. The blocker is specific—missing evidence requirements—not a vague request for “design review.”

When the next interview clarifies what evidence analysts need, the insight and component contract are updated in Notion. The next developer receives that guidance automatically without waiting for a new skill file or a separate handoff.

The resulting workflow

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

The agent can act autonomously on reversible implementation details, but it does not silently decide the meaning of data, the evidence required for a compliance action, or the acceptable level of uncertainty.

What changed

• UX guidance became available at the point of implementation

  Developers no longer had to leave the development context and reconstruct the rationale across several artifacts. The agent could bring the relevant component rules and research context into the conversation when a feature was being shaped.

• Research became operational rather than archival

  Insights were no longer only findings to present in a readout. They could influence component selection, copy, hierarchy, data requirements, and implementation sequencing.

• Open questions became visible dependencies

  The workflow prevented unresolved assumptions from disappearing into the UI. A question about evidence, traceability, or scoring logic could be surfaced as a named product dependency and routed to ongoing research.

• Component reuse became more meaningful

  The team could reuse components based on purpose and data contracts, not only on appearance. This reduced avoidable variations while protecting important differences between summary and investigation workflows.

• Prototypes became decision tools

  Figma and front-end prototypes remained useful, but they were no longer the end of the process. Each option could be evaluated against a user question, a research finding, and the data actually available.

Challenges

• Retrieving enough context without overwhelming the developer

  A connected knowledge base can return too much information. I limited retrieval to guidance that could materially change the solution: component purpose, critical states, relevant evidence, open questions, and current blockers.

• Separating evidence from assumptions

  The agent needed to communicate whether a recommendation came from a durable design rule, a research insight, an unresolved question, or its own inference. Without that distinction, live context could create false confidence.

• Keeping component documentation current

  Moving knowledge to Notion reduced duplication, but it did not eliminate ownership. Component contracts still required a clear owner and a lightweight review process so code, Figma, and documentation did not drift apart.

• Avoiding a new approval bottleneck

  The goal was not to route every UI decision back to UX. The workflow had to identify only the decisions with meaningful user, compliance, or data consequences and let developers proceed independently on the rest.

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 how component purpose, data requirements, edge cases, and research evidence should be documented.
• Connected interface decisions to the needs of analysts, compliance teams, and non-expert readers.

UX researcher

• Structured the research space around validation experiments, current questions, and reusable insights.
• Converted findings into practical design implications rather than leaving them as interview summaries.
• Made unresolved questions visible during implementation so development could inform the research roadmap.

Tooling architect

• Connected the IDE, Figma, the codebase, and Notion through an MCP-based workflow.
• Separated stable reasoning instructions from frequently changing product knowledge.
• Defined when the agent could proceed, when it should offer options, and when it should surface a blocker for human judgment.

Learnings

• AI is most useful when it improves decisions

  Generating an interface quickly is useful, but the greater value comes from asking what the interface must help someone understand, which evidence supports the decision, and what remains unknown.

• A design system needs semantics, not only assets

  Components and tokens provide consistency. They become a decision system only when they also describe purpose, required data, uncertainty, content rules, and consequences.

• Research has more impact when it can be retrieved in context

  A finding is easier to act on when it appears beside the component and feature it affects. Connecting research to implementation made the work continuous rather than a sequence of handoffs.

• The strongest workflow connects four sources of truth

  • The skill defines how the agent reasons.
  • Figma defines the visual and interaction patterns.
  • Notion defines product meaning, evidence, and open questions.
  • The codebase defines what already exists and what can be shipped.
  No single source was enough on its own.