Vendor Rate Submission

Overview

A construction-materials marketplace raises RFQs to its vendor network - steel, cement, aggregates - and suppliers submit rates back. The existing flow worked: four screens, functional, unremarkable. This is the version I’d ship.

Role

Product Designer

Scope

Mobile · RFQ rate submission

Timebox

3 days · design exercise

Built with

Figma → Claude MCP → Framer

The exercise

Today that happens across four mobile screens - the offer request, rate entry per line item, a review with totals and GST, and a confirmation state. It works. It is also the single most valuable thing a vendor does on the platform, and it doesn’t feel like it: no real feedback, no momentum, no point of view.

The brief was to redesign it so it feels like a consumer-grade app - judged on micro-interactions, motion, personality, and the submit moment specifically. Restructure, merge, add screens, or keep the bones and layer motion on top; the call was mine, as long as the result was a working prototype rather than a set of stills.

Three days, no access to real vendors. Every assumption I made in place of that access is stated openly, alongside the reasoning behind each decision.

Three days, start to running build

The brief allowed any Gen-AI prototyping tool and asked for a straight answer on what was used and where. So rather than a “built with” credit, here is the actual timeline - including the day AI did nothing, which is the more useful half of the answer.

Day 1 · Take the existing flow apart

• Walked the four live screens and wrote down what each one actually asks a vendor to do, and what it gives back in return.
• Listed every assumption I was standing on in place of real vendor access - the brief asked for those stated, so they became a slide rather than a footnote.
• Made the structural call before opening a single frame: what merges, what survives, and where totals and GST belong.

AI here was an argument partner - I had it take the opposite side of each assumption to find the weak ones. Nothing it produced went into the work.

Day 2 · Build the system, then the screens

• Foundations first - colour, type and spacing tokens - then the icon set, atoms and molecules.
• Screens assembled only from published components, so nothing downstream is a one-off drawing and the whole file stays changeable in one place.
• The visual language landed here too: the yellow, the illustration, the personality the brief was asking for.

No AI on this day. Structure, hierarchy and visual language are the judgement being assessed - handing that over would have defeated the point.

Day 3 · Turn it into something that runs

• Claude read the Figma file directly through the MCP connector and generated the Framer build - components and tokens carried across as real code instead of being redrawn by hand.
• Motion authored on top in Framer: input states, the transitions between steps, and the submit moment the brief called out specifically.
• Shipped as a live site rather than a hotspot prototype, so the interactions behave the way they would in the real app.

This is the day the tooling earned its place. A three-day timebox does not otherwise end in a working build - it ends in a click-through.

Where the line sits

The structure, the assumptions, the visual language and every motion decision are mine. The connector saved me the build, not the thinking - which is exactly the trade I’d make again on a three-day clock.