UX Development Workflow

How I created a Markdown framework that turns Cursor into a context-aware UX partner for front-end developers.

Problem

CENSE helps bank teams make sense of a client’s crypto wealth by bringing together complex wallet and portfolio data. But that information cannot always be presented in the same way.

Sometimes analysts need detailed tables to inspect and compare data. At other times, they need a concise summary, a few important figures brought to the foreground, a visual representation of changes over time, or an AI-supported explanation.

Choosing the right format is a recurring challenge for Product and Engineering. What does the user need to understand or decide? Which information matters most? How much detail should be visible at first glance? And when should the interface use a table, summary, chart, or AI?

These decisions shape almost every new feature in the CENSE product.

A request such as “show the quantity of each token held by a wallet over time” may sound simple, but it immediately raises more questions.

Is the user looking for an exact historical value or a broader trend? Are they investigating a particular transfer? Do they need to compare tokens? Should the information appear in a table, a chart, or both? Does a similar view already exist somewhere else in the product?

Without immediate UX support, the developer has to answer these questions while also understanding the data, the codebase, and the technical requirements. This creates a high cognitive load and makes it easy to commit to a UI direction before the user’s actual need is clear.

The quotes below are representative composites that capture recurring friction in the feature-shaping process rather than verbatim interview quotations.

“I can build the table or the chart, but I’m still guessing which one will help the analyst answer their question.”

DEVELOPER

Needs clearer UX guidance at the moment a feature is being shaped—before committing to a UI direction.

“The implementation itself might take two days, but the conversations around what to build can stretch the feature across an entire week.”

PRODUCT MANAGER

Needs faster alignment on the problem and format so delivery time is spent building the right thing.

The bottleneck was not the developer’s ability to write code. It was the lack of UX guidance at the moment the feature was being shaped.

Proposal & Process

I wanted to bring more of the UX process into the place where front-end decisions were already happening: the developer’s IDE.

To do that, I created a specialized Markdown file that guides how Cursor’s AI agent approaches interface work.

The file acts as a set of instructions, questions, and decision rules. It prevents the agent from immediately generating code and instead asks it to understand the user’s goal, inspect the existing product, and consider different ways of presenting the information.

The aim was not to turn AI into an automatic designer. It was to give developers a structured UX partner that could help them think through a problem before committing to a solution.

The work followed a five-part framework:

1. Start with the user’s question

   The first part of the framework teaches the agent to look beyond the feature request. Instead of accepting “show token quantities over time” as the full requirement, the agent asks what the user is trying to learn from that information—for example, whether they need a quick overview or a detailed investigation, whether exact values matter more than the overall pattern, whether they are investigating a particular transfer, which information needs to be visible immediately, and what decision the interface should help them make. These questions help distinguish between features that may use the same data but support very different workflows. They also encourage developers to think about the value of the feature before spending time building it.

2. Make the agent look before it builds

   The next step is a structured scan of the existing codebase. The agent looks for components, layouts, tables, charts, filters, and interaction patterns that already exist in CENSE. It also checks the project’s design tokens, CSS variables, and front-end architecture. This allows the agent to answer whether similar information is already shown elsewhere, whether an existing component could be extended, whether a new component would introduce an unnecessary variation, whether the proposed solution fits the current product, and how much additional complexity it would add for the user. If the agent finds a similar table or visualization, it does not automatically create another one. It points out the overlap and asks whether the new use case is different enough to justify a new pattern—making component reuse part of the product conversation instead of something developers have to discover manually.

3. Explore more than one answer

   UX problems rarely have only one reasonable solution. To reflect that, the framework asks the agent to create three versions of the feature. The baseline version is the simplest path focused on the core user need—for token history, a straightforward table showing tokens, quantities, values, and dates. The complex version explores a more detailed investigation workflow, which might include token filters, date ranges, comparisons, sorting, or additional wallet information. The graphical version focuses on patterns and changes over time, using charts, summary values, and markers for important transfers or portfolio events. The goal is not to generate three cosmetic variations. Each version should represent a different level of complexity and support a different way of understanding the data.

4. Build the prototypes inside the product

   The agent generates each version directly in the CENSE front end. It uses the project’s existing components, design tokens, and CSS variables, so the result already looks and behaves like part of the product. The developer can open each version in the browser, interact with it, and compare the trade-offs in context. This removes the need to first create a static design and then translate it into code. The prototype is already working front-end code. Once a direction is chosen, the team can refine it instead of rebuilding it from scratch.

5. Keep the developer involved in the decision

   The framework gives the agent a high level of autonomy, but it does not allow it to make important product decisions silently. The agent can investigate the codebase, identify patterns, ask questions, and recommend a direction. The developer still decides which trade-offs are appropriate. This balance was important. The purpose of the framework is to make developers more confident and self-sufficient—not to remove human judgment from the process.

Result

Developers can now describe a feature in Cursor and receive a structured UX response before implementation starts.

For example, when a developer asks to show token quantities for a wallet over time, the agent first checks how wallet and portfolio information is already presented in CENSE.

It looks for related tables, charts, summaries, and components. It then asks a small number of questions to clarify what the user needs to understand.

Once the intent is clear, the agent generates three working directions:

• A simple, evidence-focused table

  optimized for exact values and comparison.

• A more detailed investigation view

  supporting filters, ranges, and deeper exploration.

• A graphical view focused on changes over time

  highlighting patterns, summaries, and material events.

The developer can compare these versions directly in the browser and discuss something concrete with Product, UX, or Compliance.

Instead of waiting for a complete design handoff, the team can respond to a working interface. Feedback becomes faster because everyone can see how the feature behaves with the rest of the product.

The new workflow looks like this:

Feature request → user-intent questions → codebase scan → three working directions → browser review → refinement

Impact

• Prototypes in minutes instead of days:

  The framework removes much of the waiting between an initial request and the first useful prototype. Developers no longer need to wait for requirements to become a wireframe, for the wireframe to be reviewed, and for the approved design to be translated back into code. They can explore several realistic directions while the problem is still fresh.

• Fewer duplicate components:

  Because the agent checks the codebase before creating anything new, it is more likely to reuse or extend existing patterns. This reduces UI fragmentation and helps the product remain consistent as more wallet, portfolio, and compliance features are added.

• Less work between design and development:

  The prototype is built with the actual CENSE front-end system. Once a direction is approved, much of the layout, behavior, styling, and component structure is already in place. In many cases, the prototype contains around 90% of the foundational front-end work. The remaining work can focus on edge cases, data integration, testing, and production refinement.

• More confident UI decisions:

  Developers no longer need to start from a blank canvas or rely only on personal preference. The framework gives them a clear set of constraints: the user’s goal, the decision the interface needs to support, existing product patterns, the appropriate level of detail, and the risk of adding unnecessary complexity. These constraints make it easier to explain why a particular interface was chosen.

• More focus on customer value:

  The framework also challenges features that display more information without helping users make a better decision. For CENSE, the objective is not simply to show as much wallet data as possible. It is to help bank teams understand that data and use it confidently during a compliance review. By asking what the user is trying to understand before generating the interface, the agent helps prevent features that are technically complete but not genuinely useful.

Challenges

• Teaching the agent to understand purpose, not just similarity.

  One of the hardest parts was teaching the agent to understand the context of a complex codebase. Finding another table is easy. Understanding whether that table serves the same purpose is much harder. Two components may show similar wallet data while supporting completely different workflows—one a quick case summary, another a detailed investigation or final report. The framework therefore needed to guide the agent beyond visual similarity and toward the purpose of each component.

• Asking enough questions without creating a new bottleneck.

  If the agent asks too few questions, it makes assumptions that may lead to the wrong solution. If it asks too many, it creates a new bottleneck and makes the interaction feel like a long requirements workshop. I focused the framework on questions that could materially change the solution. Smaller decisions could be inferred from the existing product or refined once a working version was visible.

• Keeping instructions specific without making them rigid.

  The framework needed to provide useful constraints while leaving enough room for the agent and developer to explore different solutions.

Role

UX Engineer

• Translated parts of the design process into a structure the AI agent could follow.
• Defined the questions it should ask, the checks it should perform, and the criteria it should use when comparing different interface directions.
• Created the baseline, complex, and graphical prototyping structure to encourage meaningful exploration rather than settling on the first solution.

Tooling Architect

• Integrated this process into the developer’s existing environment.
• Defined how the agent should inspect the CENSE codebase, reuse the design system, generate working prototypes, and move from a loosely defined request to a front-end solution.
• Connected UX quality with the practical realities of building and shipping the product by wearing both hats.

Learnings

• AI is most useful when it improves decisions:

  The value of AI in design is not simply that it can generate interfaces quickly. Its greater value is helping teams ask better questions, notice missing context, and compare different directions before committing to one. The quality of the thinking matters more than the number of screens produced.

• Context is what makes automation useful:

  A generic AI tool can suggest a reasonable table or chart. A useful product assistant needs to understand the existing codebase, design system, users, terminology, and workflows. The more relevant context the agent has, the less generic its output becomes.

• Constraints can make developers more creative:

  Giving developers UX constraints does not limit their options. It gives them a clearer space in which to explore. When the user’s goal, the existing patterns, and the main trade-offs are already visible, developers can spend less time reconstructing basic UX logic and more time comparing meaningful solutions. The framework does not replace designers. It brings more design thinking into everyday development and gives the team a stronger starting point for each new feature.