TL;DR

The handoff didn’t need to be faster. It needed to disappear.

Cense · UX Engineer, Researcher & Tooling Architect · 2025–present · Zug, Switzerland · highly specialised compliance and analyst users

The problem

Component purpose, data requirements, research findings and open questions lived in tickets, Figma, Slack and scattered docs, nowhere a developer could reach while building. So the UI shipped looking right and meaning the wrong thing.

What we did

Turned component contracts, design-system rules, research insights and open questions into a live knowledge layer the coding agent consults while a developer builds, so UX guidance arrives at the point of implementation, not after the PR.

Under NDA; wireframes are mockups. Figures are indicative of scale and are not reproduced in search results.

Research

• Weekly user interviews
• Usability testing on prototypes
• AI tool usage analytics
• Research ops (questions, sessions, insights)

Tools

• Notion over MCP
• Figma over MCP
• IDE coding agent

Team

Three people (Ricardo, a Product Manager and 1 frontender) inside a product team of about twelve spanning product, engineering, compliance, customer success and sales.

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 looking simple: "show token quantities over time," "add the risk score," "surface a wallet warning." A faster design handoff looked like the fix. But the UI could still ship looking right and meaning the wrong thing. That created four distinct failures:

1. Hidden intent.

   The ask never explained what the user needed to understand or decide: exact value or trend; proven risk, screening signal, or incomplete data; table or chart; genuine reuse or only visual similarity.

2. Context reconstruction.

   Developers pieced together product rationale from tickets, Figma, Slack, and the codebase. That meant high cognitive load, and a bias toward locking in a UI before the real need was clear.

3. Silent product decisions.

   A visually consistent card could ship in minutes and still be wrong: a risk score without evidence, or a reused shell that served a different purpose, because it looked exactly like every other card.

4. Research out of reach.

   Notion already held a UX Research space and a UX Design space. None of it arrived at the moment a front-end decision was being made. So open questions were resolved in code by whoever was typing.

‘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?

Approach

Eight stages, from a static skill file to a live knowledge layer wired into research. Each one fixed what the last one could not reach.

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.

IDE · Agentwallet-overview.tsxskill: ux-process

Add a summary card to the wallet overview.

Before writing code

• Goal: help the analyst decide if this wallet needs review
• Inspected src/components · 14 patterns
• Reuse SummaryCard + StatusBadge, no new component
• Directions: Simple Advanced Visual
• Your call: show an overall risk score here, or only the flags behind it?

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 was a changing product encoded in a static document. The skill could teach the agent how to think, not supply the latest facts.

SKILL.md.agent/skills/ux-processedited 94 days ago

3 statements no longer match the product

## Terminology - Call the score "Risk level"Renamed "Risk signal" two releases ago## Color - Red = high risk, block the walletRule changed: red signals attention, not loss## Evidence - Research: Q1 interview synthesis11 newer findings are not in this file

Loaded in4 of 19 PRs

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.

IDE · Agenttool callFigma MCP

figma.get_component("RiskBadge")

Figma answers

• Exists in Cense DS
• 4 variants · low, medium, high, unknown
• States · default, hover, loading
• Used in 23 frames

Figma can't say

• Why it exists
• Which decision it supports
• What data must be present
• Which research challenges it

4. Choosing organizational fit over Claude Design

Evaluated Claude Design, and passed. The company had already standardized on a different LLM environment. Adopting it would have 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 features on its own. It's the one the whole team can access, manage, and use consistently.

Decision logAI tooling for UI workDecided

Claude Design

• Strongest design features
• Personal account per person
• Outside company-managed tools
• Access varies by individual

Company LLM environment Chosen

• Already standardized
• Company sign-in for the whole team
• Managed and supported centrally
• Same workflow for every developer

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.

Component auditRiskBadge

The pixels

Medium risk

• 1 dot, 1 color, 1 label
• Built in an afternoon

What it depends on

Score source

Which model, which date

Signals

The flags that produced it

Confidence

How much evidence stands behind it

Wording

"Needs attention", not "Rejected"

Next action

View evidence

Color is informative, not advisoryRed = attention, not lossUncertainty lives in the copy

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.

NotionUX KnowledgeMCP

Design rulesedited 2d ago

Component contractsedited 5h ago

Research insightsedited today

Open questionsedited today

SKILL.mdnow 7 lines

process: clarify → inspect → reuse → compare → defer rules: notion://Design rules contracts: notion://Contracts evidence: notion://Insights, Questions visuals: figma://Cense DS patterns: ./src/components

7. Treating component usage as a product contract

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

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). Reusing the shell did not mean reusing the hierarchy.

Pull requestCase review tableagent review

Wallet overviewQuick scan

Case reviewAudit trail

Same DataTable shell, different contract. An investigation has to hold up in an audit:

• Reuse the layout, spacing, and row states
• Don't reuse the column order or the default sort
• Add a source column, sort by timestamp, and link each row to its evidence

8. Connecting implementation to active UX research

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

That system was fed by a steady research ritual, not by a one-off readout deck:

• User interviews: at least one a week, with existing users or prospective users in the same domain (people already in the sales process, or part of the community).
• AI tools usage analytics: which questions people asked, how often they used the tools, and an overview of the conversations they ran.
• Usability testing: for major features, we aimed to prototype first and walk people through the prototype so we could refine the usability before build locked in.

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 tell apart a settled rule to follow, a research-backed recommendation, an open question to surface, and a genuine blocker needing a human call.

IDE · Agent"medium risk" summaryNotion · Figma · code

What I found before building

Rule · follow

Risk can't be shown by color alone.Design rules · color

Research · recommend

Ship the score with its contributing flags.Insight · scores without flags aren't trusted

Open · surface

What evidence makes a risk indicator actionable?Question · owned by UX, unresolved

Blocker · ask

Audit traceability is undefined. I won't pick a behavior for "View evidence".Needs Product before merge

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 that risk can't be communicated by color alone, and that 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. 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

1. UX guidance arrived at the point of implementation.

   Developers no longer left their environment to reconstruct rationale across five different artifacts.

2. Research became operational, not archival.

   Insights shaped component selection, copy, hierarchy, and data requirements, not just slide decks.

3. Open questions became visible dependencies.

   Unresolved assumptions couldn't quietly disappear into the UI.

4. Component reuse got more meaningful.

   Teams reused based on purpose and data contracts, not just appearance.

5. Prototypes became decision tools,

   evaluated against a user question, a research finding, and actual data availability. Not the finish line.

Challenges

1. Retrieving enough context without overload.

   Limited retrieval to what could materially change the solution: purpose, critical states, evidence, open questions, blockers.

2. Separating evidence from assumption.

   The agent had to flag whether a recommendation came from a durable rule, a research insight, an open question, or its own inference. Otherwise live context would create false confidence.

3. Keeping documentation current.

   Notion cut duplication, not ownership. Component contracts still needed a clear owner and a lightweight review process.

4. Avoiding a new approval bottleneck.

   The goal wasn't routing every UI decision back to UX. Only the ones with real user, compliance, or data consequences.

Role

Learnings

1. AI is most useful when it improves decisions,

   not just when it generates interfaces fast.

2. A design system needs semantics, not just assets.

   Components and tokens become a decision system only once they describe purpose, data, uncertainty, and consequences.

3. Research has more impact retrieved in context,

   beside the component it affects, than presented in a readout meeting.

4. The strongest workflow connects four sources of truth:

   The skill (how the agent reasons), Figma (visual and interaction patterns), Notion (product meaning, evidence, open questions), and the codebase (what exists and what can ship). No single source was enough on its own.