What 100 Interviews Did to a Client’s Assumptions
In 2011, a newly funded VC firm brought me on as UX Strategist and Principal Creative Director to launch a local comedy club and build its proprietary ticketing system.
Solo designer.
No product development budget.
Their benchmark for everything was Facebook. They wanted that level of simplicity with marketing-grade reliability and API hooks for third parties.
Their opening requirement: the full system, live, in three months. With one designer and no real budget, that wasn't going to happen. So I mapped their requirements on a wall until they could see the real scope for the first time.
Then I negotiated it into two phases:
Phase 1 (2 months): a launch site, static HTML, manually updated but shippable and on-brand for opening night
Phase 2 (months 3–6): the ticketing system, designed to a Classic ASP / MS Access stack their in-house devs would build against
None of them had worked with a dev team before, so "make it like Facebook" was the only requirement language they had. I ran discovery to translate it, and stood up a Kanban board so a first-time client could watch the pipeline instead of guessing at it.
Here's what made this unusual: the club hadn't opened yet, so every belief they held about their customer was unvalidated. I asked the question that exposed it: "Who is your customer?" and got five different answers. So we built an empathy map and a journey map of their assumptions, deliberately, as a baseline to test against.
Then I went and got real data. The Improv down the street seated 600 and ran five shows that weekend, roughly 3,000 patrons. I stood in the plaza outside, four-hour shifts, offering gift cards to people on their way out. Over 100 intercepts, about a 3% capture rate.
The personas and journey map that came out of it looked nothing like the stakeholders' version: different spend triggers, different gifting behavior, different decision timing. Their model had been built on their own nights out. I pressure-tested it against a teardown of Ticketmaster, Fandango, and sports ticketing; the pattern was that everyone punished buying across multiple dates. That teardown earned a budget increase.
We sketched ideas together rather than designing for them. Two pain points came up, both rooted in personal experience: buying tickets for multiple dates meant making separate transactions, and there was no way to gift a ticket. Both were common gaps in the industry, so we decided to build around them.
I collapsed the typical six-to-seven-step checkout into a shorter flow, prioritizing guest checkout and a single cart spanning dates.
The calendar carried the real weight, since multi-date selection is where competitors lost people. Iterated desktop and mobile against stakeholder feedback.
[ CLICK TO VIEW HIGH-RES SPECIMEN ↗ ]
Shipped: the Phase 1 launch site.
Delivered: full ticketing system designs for Phase 2.
Not built: the ticketing system itself. The club's liquor license slipped, opening moved, and they ended up selling tickets through Facebook and a third-party system called Symphonee instead. Their dev team took over Phase 2 and the window closed.
So the artifact trail is real and the shipped surface is thin.
Two things I'd change:
I gave them too many revision rounds. Phase 2 design stretched across six months because I allowed open-ended change requests. I traded my own time to land a portfolio piece, and it didn't pay off. Next time: cap revisions in the SOW.
I proved the research mattered, then let the deliverable outrun the build. The personas were validated and the client believed them; the dev capacity was never going to match. I should have scoped Phase 2 to the smallest shippable slice instead of a full system.
What held: the research artifacts helped settle scope disagreements, and the Kanban board made it easier to handle changing requirements without losing momentum. Over time, the client stopped relying on nostalgia to guide design decisions and started focusing on what the research actually showed. For a first-time founder, that’s a big part of the battle.
