
Find That Studio

Product Designer — Mobile App Design
Find That Studio had to work for two people who wanted opposite things and would never meet. One was hunting for a creative studio to rent by the hour. The other was a studio owner with no technical skill, trying to get their space online and booked. The same product had to make both feel effortless, because a marketplace stalls the moment either side gives up.
I designed Find That Studio end to end over six months, working solo as product designer alongside the product manager, two frontend engineers, and an SEO specialist. Scope covered product strategy, information architecture, user flows, wireframes, high-fidelity UI, prototyping, responsive design, the design system, the host onboarding flow, and developer handoff, across roughly 35 page templates and two dashboards.
Service
Mobile App Design
UX & IA
UI Design
Design System
Interaction Design
Category
B2B
Internal Tool
Timeframe
January 2026 - July 2026
( 00-01 )
THE PROBLEM
Photographers, agencies, and creators increasingly need a studio for a few hours, not a lease. Studio owners, meanwhile, had no simple way to present their space and get booked. Find That Studio had to solve both problems on the same platform, for two people who'd never use it the same way.
The bet was that if discovery was fast and trustworthy enough, renters would book without needing a call first — and if publishing was simple enough, owners with no design or marketing background could put together a listing worth booking. Neither side could be an afterthought. A platform good at discovery but painful to list on wouldn't have any studios in it. A platform easy to list on but hard to search wouldn't have any renters.

( 00-02 )
DISCOVERY & COMPARISON
Every studio had different facilities, pricing, equipment, and rules — show all of it upfront and the page turns into a wall of specs nobody reads. Hide too much and renters don't trust what they're looking at. The answer wasn't removing information, it was sequencing it.
Renters filter by city, category, price, facilities, equipment, and capacity, and land on a list of studio cards built to answer the first question fast: is this even in the running? Cards surface only what matters for that first pass. Everything else — full equipment list, house rules, exact policies — lives on the studio page itself, ordered so the details that affect a booking decision come first and the reference material comes after. Same information, just not all competing for attention at once.

( 00-03 )
DESIGN SYSTEM
Fifty studios today doesn't mean fifty studios in a year. Every screen needed to work whether the platform had ten listings or a thousand, so nothing got designed as a one-off, it got built as a token-driven system from day one.
Typography, spacing, and color were all defined as variables, not hardcoded values, so a change in one place propagated everywhere instead of turning into a page-by-page fix. Components used variants and auto layout so they could resize and reflow across desktop, tablet, and mobile without a separate design per breakpoint. I didn't design the system and hand it off — I sat with the engineers as they built it, and we ended up consolidating several one-off input patterns from the onboarding flow into reusable components once we saw them repeating. That back-and-forth is what kept the system scalable as we kept adding pages, instead of drifting out of sync with what actually shipped.
( 00-04 )
HOST ONBOARDING
Ask a first-time host to fill in one long form covering pricing, facilities, equipment, rules, and photos, and most of them abandon it halfway through. Publishing a studio isn't a single task — it's three different ones, and the flow needed to admit that.
Step one is just the basics: name, location, description, contact, and pricing — enough to save something real early. Step two goes deeper: facilities, equipment, accessories, capacity, rules, and category. Step three is photos, a final review, and publishing. Splitting it this way meant hosts always knew what was left and could stop and pick back up without losing progress. End to end, a host can go from nothing to a published listing in under 40 minutes.
Publishing isn't the finish line, either. Every host gets a profile where they manage everything they've listed — one studio or several — with the ability to edit details, update availability, and message renters directly. Onboarding gets a host to their first listing fast. The profile is what makes it worth coming back to manage.

( 00-05 )
DESIGN SYSTEM
Fifty studios today doesn't mean fifty studios in a year. Every screen needed to work whether the platform had ten listings or a thousand, so nothing got designed as a one-off, it got built as a token-driven system from day one.
Typography, spacing, and color were all defined as variables, not hardcoded values, so a change in one place propagated everywhere instead of turning into a page-by-page fix. Components used variants and auto layout so they could resize and reflow across desktop, tablet, and mobile without a separate design per breakpoint. I didn't design the system and hand it off — I sat with the engineers as they built it, and we ended up consolidating several one-off input patterns from the onboarding flow into reusable components once we saw them repeating. That back-and-forth is what kept the system scalable as we kept adding pages, instead of drifting out of sync with what actually shipped.
( 00-06 )
SUMMARY
The numbers said the bet was right. Renters showed up, hosts followed, and both sides of the marketplace actually used what they were given.
140+ cities covered
60+ unique studio spaces
1,000+ bookings facilitated
Direct contact with hosts on 100% of bookings — no middleman
( 00-06 )
REFLECTION
The real lesson wasn't how to design a marketplace. It was how to design for two people who need opposite things from the same screen, without picking a side.
Every decision on this project came back to information architecture — how much to show, when, and to whom. Renters and hosts needed the platform to feel like it was built specifically for each of them, which meant nothing could be designed for "the user" in the abstract. That's what I walked away with: not just organizing information, but organizing the same information differently depending on who's looking at it and why.
( 00-07 )
DISCOVER MORE

