A marketplace startup validated its two-sided UX in wireframes before writing a line

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Two founders are building a skills marketplace connecting independent practitioners with clients — pre-launch, pre-product, and pre-code. They raised their pre-seed on a pitch deck and a mood board; neither side of the marketplace has ever been walked through the actual flows. The founders disagree about the core loop — one believes clients should post briefs, the other believes practitioners should sell availability — and the argument has stalled decisions for two months. A board review is four weeks away, and they need evidence rather than another debate.

What it was costing

The founding team had raised on a deck and a Figma mood board. Neither side of the marketplace — practitioners or clients — had been walked through the actual flows, and the founders disagreed about what the core loop even was.

What they could see

• The two founders described the product's core loop differently in every investor conversation, losing coherence as the pitch traveled.
• Decisions about onboarding, search, and pricing had stalled for months because each resolved to the same unresolved argument.
• Neither audience had seen the flows; every opinion in the company was a founder's opinion.
• The mood board made the product feel decided while none of its screens had survived contact with a user.

The constraints we worked inside

• No product existed — wireframes were the only testable artifact and the whole budget.
• Both audiences had to understand the loop unaided — no onboarding narrative to rescue confusion.
• The founders had four weeks before a board review.

What had been tried before

They built a landing-page smoke test with two hero variants, one per founder's thesis, counting email signups.

Signups measured interest in the promise, not comprehension of the loop — both variants converted similarly, which proved nothing except that copywriting was good.

A paid advisor produced a UX audit recommending industry-standard marketplace patterns from competitor screens.

Pattern recommendations assumed the core loop was already decided; the audit sharpened both founders' convictions instead of settling whose loop users could actually complete.

The founders drafted competing flow documents in a shared doc, hoping writing would expose a winner.

Documents argued rhetoric, not comprehension — without a user attempting the loop, neither document could lose, so neither side conceded.

What we proposed

We proposed turning the disagreement into a testable question: draw both founders' versions of the core loop as competing wireframe flows, then put them in front of both audiences — practitioners and clients — running the same task from each side's entry point. The loop that survives contact with users unaided becomes the product; the argument becomes evidence. Wireframes rather than coded prototypes because nothing existed and the whole budget was the test. Two structured iteration rounds fed both sides' results back into one shared flow, with the founders observing sessions rather than summarizing them to each other.

Just as important is what we ruled out, and why:

• Building an MVP coded from the founders' combined assumptions — Four weeks and no validation — building both theses in code would spend the runway answering a question wireframes could answer for a twentieth of the cost.
• Standard user testing of one founder's preferred flow only — Testing a single thesis would produce feedback on it, not a verdict between them — and the losing founder would never own a result they were excluded from.
• A Concierge MVP manually brokering the first transactions — It tests willingness to pay, not whether the self-serve loop is understandable — the board question was comprehension, and manual matchmaking would have hidden it.

How the work ran

Delivered by the experience pod — designer + researcher over 4 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Figma

One shared file held both competing flows side by side, which kept the comparison honest and let founders annotate objections directly on the competing screens.

Wireframes

Deliberately low fidelity kept participants reacting to structure instead of styling — the question was whether the loop made sense, not whether they liked the fonts.

Moderated testing (both audiences)

Running identical tasks from practitioner and client entry points exposed where the loop broke on each side — the marketplace's both-sides constraint demanded both-sides evidence.

What went wrong

How we worked together

Cadence

Twice-weekly founder sessions: Monday to review test plans and recordings, Thursday to decide changes; board-prep checkpoints at the end of each week.

Client side

Both founders attended every session as observers with a no-interruptions rule; one founder owned recruiting, the other owned the board deck the wireframes fed.

Decisions

Decisions were made on session evidence — a flow change needed a named failure it fixed, and unresolved calls went to whichever test could settle them.

They provided

Access to their investor-facing mood board and deck, their practitioner community channels for recruiting, and four uninterrupted weeks of founder attention.

What changed

The headline: test participants completing the core loop unaided by the final wireframe round (round 1: 3 of 10) — 9 of 12, read from Usability session records. A second check: major structural change adopted (brief-first flow) — before any code at 1.

The founders stopped having the argument, because it converted into something better: a documented loop both sides had watched users complete or fail. Board prep changed register — instead of defending a thesis, they walked the loop and showed nine of twelve participants completing it. The founders now greet new product ideas with which session would test that rather than whose instinct wins, and the wireframes gave their first engineering hire a blueprint with failure modes already known.

The result was read from Usability session records against the pre-engagement baseline over the stated window, with a guardrail check on major structural change adopted (brief-first flow) — before any code. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The tested wireframe flows with annotated findings from both audience rounds
• A research repository of session recordings and completion notes, organized by flow
• The recruiting screen and disqualifier list used to source real-practitioner participants
• A board-ready summary of the brief-first decision and the evidence behind it