AI Prototyping: Testing Sooner with Real Cases at Ramp

Design teams are leveraging AI tools to generate interactive prototypes that closely resemble the final product and quickly test them with users. Projects conducted at Ramp and a case study at Purdue illustrate what these approaches make feasible and where safeguards remain, particularly regarding methodology and data.

Methodological Limits and Data Precautions Are Established

The documented case at Purdue University is a sequential study on a single project, rather than a controlled experiment. It is presented as an illustration of what is becoming possible to build and test, without constituting proof that AI-driven prototyping yields better research outcomes. Researchers report a deepening understanding of the problem when the team transitioned to an AI-generated interactive prototype.

Obtaining actionable results with these tools remains contingent on the context and design guidelines provided. When real data is used, it is explicitly recommended to adhere to data policies and exclude any personally identifiable information, also checking the policies of the tool used to understand the potential use of this data. A quick pilot test is advised before a study, to validate the prototype's functionality and prevent unforeseen misunderstandings.

What AI Changes: A Realistic Prototype in One Day, Tested Sooner

Thanks to AI tools, it is now possible to create a functional and credible prototype in just one day, significantly speeding up production. They allow for the early inclusion of plausible participant data, a wide variety of states, advanced filters, and responses from generative models. This combination enables earlier and more frequent testing, followed by iterations as research progresses.

These approaches make it feasible to produce high-fidelity interactive prototypes that closely resemble the actual product, particularly useful for complex interfaces like filters, dashboards, or conversational agents. Static prototypes retain their utility for less complex interfaces but are limited when exploring multiple states becomes central. Where many teams previously settled for a minimal optimal path and awaited software construction to observe real usage, it is now possible to anticipate these observations at the prototype stage.

At Ramp, a Policy Editor Redesigned via Cursor and Tested on Cleaned Data

AI prototyping has been adopted by Ramp's design team in their work methods. Pavan Garidipuri, senior product designer, used Cursor to design the new version of a spending policy editor, a tool historically considered difficult to use. He explains that he chose an AI solution due to the tediousness of a manual method in the face of interaction design complexity.

The redesign focused on editing via AI chat, with dynamic interface responses that are poorly suited to static screens. For testing, a link to a functional prototype was sent to participants, with their own data previously cleaned. Since the prototype behaved like the product, interactions were natural and feedback was precise. The team identified specific cases that might have been overlooked with another approach, including a key point: the way to track and display changes was confusing. Pavan Garidipuri reports that this issue would not have emerged without an interactive prototype close to the real interface. The project moved from concept to demo in three weeks, with continuous iterations driven by customer feedback, and influenced the roadmap for the rest of the year.

Conversational AI: Managing Non-Deterministic Responses Before Deployment

Still at Ramp, product designer Andrew Lucas used AI to visualize an expense reporting flow through a conversational interface. This interface was intended to produce a sensible response to nearly any input and could generate different outputs for the same request, a non-deterministic behavior that fixed-screen design tools poorly represent.

He employed Cursor to connect the interface to an agent generating non-deterministic outputs, allowing for the testing of an interactive prototype before deployment. Participants could freely enter their requests without following a prescribed scenario, enabling observation of how the agent handled unexpected queries. These types of issues emerge during testing of a near-final version and may remain invisible when only ideal trajectories are presented.

Purdue: A Filter for 27 Attributes, More Precise Feedback with the Interactive

At Purdue University, researchers created a filtering interface for traffic engineers to analyze complex traffic data. The dataset included 27 attributes per event, some with nested sub-attributes. The team compared hand-built static prototypes with AI-generated interactive variants.

The first phase, conducted in Figma without AI assistance, provided feedback on the visuals but did not allow for observation of interactions with the filters. However, designing filters requires evaluating how the system reacts to actions such as applying or removing a criterion, which necessitates allowing participants to use the system like a real product. In phase two, the team rebuilt the interface with v0 and Bolt, providing design requirements and a synthetic dataset, and shared a link to a functional prototype.

Researchers reported different behaviors based on the formats: static screens elicited less specific feedback and seemed perceived as too preliminary for in-depth critique, while the AI-generated interactive prototype led to the identification of concrete issues to address. The multiplicity of edge cases in filtering is difficult to cover with static mockups, and manually constructing an interactive prototype in the face of numerous attributes and sub-attributes is deemed unrealistic. The contribution of AI here is the reduction of the time needed to produce a prototype that behaves like a real product.

A Step-by-Step Method and Tools: Cursor, v0, Figma Make

A sequence of actions is proposed to frame these practices. It begins with defining what the prototype must accomplish to address research questions: interactions, states, data, and types of responses needed. Next come design decisions regarding layout, hierarchy, interactions, and edge cases, such as empty and error states.

Drafting a detailed prompt consolidates these choices: it describes the expected interface and includes a data file, with the option to add sketches, mockups, mood boards, or existing designs. A general-purpose AI tool can assist in formatting the prompt, with markdown generally being the easiest for language models to process. On the data side, a synthetic dataset can be generated via Claude, Gemini, or ChatGPT based on established criteria.

The information gathered can then be transmitted to AI prototyping tools like Cursor, v0, or Figma Make, which return a functional interactive prototype. The next step is to modify the output and iterate to bring the rendering closer to the initial intent. These practices can support various phases of design, with a focus here on rapid prototyping for usability testing. For less complex interfaces, static formats remain relevant, while for extensive state sets, the ability to approximate the behavior of a real product is central.