I turned an idea into a product design and tested prototypes.

When I joined, the idea existed as a concept. Moving forward required defining how it would work for users, and showing it in a way that let the client, the brand designer and the developer make decisions.

I took responsibility for the product design, from each participant's tasks to interface behavior. The initial idea grew into a service spanning an app and a web experience. By the review, these parts had to form one product model people could click through, and a decision on the visual direction had to be ready.

The product was taking shape during the work. New decisions affected adjacent flows. Each addition had to be checked against everything else.

Multiple roles and platforms. One participant's action could continue with another person in a different interface. That called for consistent data, states and available actions.

A short time before the review. Within that time I had to deliver not only designs but something the client could click through alone after the meeting.

Confidentiality. The product name, mechanics and business logic stay private, so the case describes a process, not the product.

I started with roles, user tasks, comparable products and flow maps. I built the review around three end-to-end flows rather than a feature tour. I then developed wireframes and states for the app and web service in Figma and built clickable prototypes from them.

I used Claude at every step after the designs. One agent drew missing screens and states on a separate draft page, leaving the originals untouched. Others built the prototype section by section. Others walked through it as different users, with a screenshot at each step. An independent audit found empty states showing someone else's data, placeholders where transitions belonged, and overlaps on mobile. Fixes went back into the designs and the prototype was rebuilt. I chose and checked the decisions myself.

The process was a loop with one source of truth: Figma. The prototype was derived from the design, so any fix after testing went back into the design and from there into the prototype again. That way the prototype never drifted from what the developer would receive.

Nodes 01–03 build the product: roles and flows, wireframes and states, a clickable prototype. Node 04 tests it by walking through the flows; findings return to node 02. Node 05 presents the result to the client and leads to a decision.

Decision 1. A prototype made of frames, not code

My first approach was to build each prototype screen in markup from the design. In two days one section reached 95% fidelity, and the tail of small fixes never ended. I switched: export frames from Figma and place invisible click zones over them, driven by one state engine. Fidelity to the picture is complete, a screen takes minutes, and a fix means exporting again.

The principle: precision matters where something is built from it. Nobody reuses the prototype's code, because the developer builds the interface from Figma.

The trade-off: the prototype remains a picture with transitions, not a living interface. For a review and for testing flows, that is enough.

Figure caption (optional): Fig. 2. A prototype made of frames: design, export, click zones, state engine.

Decision 2. One end-to-end story and one engine for roles and devices

I made role and device states of a single prototype rather than separate mini-apps. I used one demo story throughout, with consistent names, dates and statuses, so that switching roles showed the same process from both sides.

The rejected alternative: separate, isolated prototypes for each role and platform. They are easier to build, but their data drifts apart and they do not show the handoff between participants.

An edge case: one user's demo data appeared for a new user. For every "filled" screen I designed an "empty" variant in advance and checked it automatically.

The trade-off: noticeably more state work at the design stage. In return, transitions have no gaps, and testing finds them before the meeting.