Play
An iOS-native prototyping tool built for product designers, later adopted by more than ten thousand of them. Six people built it, in four months, from concept to MVP.
the problem
Designers prototyping for iOS were stuck choosing between Figma’s prototyping mode, which fakes native behaviour with simple animation curves over static screens, or building a throwaway Swift prototype that often took longer than the real feature.
Neither option let you test real device performance, real gestures, or real platform quirks before a single line of production code existed. That gap, between what a prototype shows and what the shipped feature actually feels like, was the whole opportunity.
the constraints
Six people, four months, building a tool that itself had to be a credible piece of design work, because our users were professional designers who’d reject anything that felt unconsidered the moment they opened it.
That ruled out a long research phase. The team had a bias toward shipping fast from previous startups, so the operating assumption from day one was: build the smallest version that could earn trust, then learn from real use.
my role
Senior product and UI/UX designer on a six-person team. I owned product direction end to end, what the tool needed to do, how it should feel to use, and how we’d know it was working.
Designing a prototyping tool is a strange brief. The product is itself a design tool, so every decision had to hold up to the exact kind of scrutiny our own users would apply to it.
the solution: native, not simulated
Most prototyping tools fake native behaviour with animation curves layered over static screens. Play ran prototypes natively on device, real gestures, real performance, real platform quirks, not an approximation of them.
That distinction matters more than it sounds. A swipe-to-dismiss that’s a millisecond off, or a keyboard that doesn’t push the right way, breaks the illusion immediately for anyone who’s spent real time on iOS.
the solution: designing for designers
Our users were people who’d reject a tool the moment its own interface felt unconsidered. We couldn’t ship anything that looked like a placeholder, because the audience would clock it instantly.
That raised the bar on every screen, including the ones competitors treat as plumbing, import flows, project settings, export options. We treated those with the same care as the core prototyping canvas.
the results
We shipped a deliberately cut scope first: import a design, define interactions, preview natively, share a link. Version history, team libraries, and more advanced gesture authoring came after, once the core loop held up under daily use rather than just in a demo.
Growth past ten thousand users came largely from designers recommending it to other designers, which only happens if the thing actually works. That’s the metric I trust most from this project, not engagement numbers, word of mouth inside a profession that’s famously hard to impress.
what i’d take from it
Building a tool for your own profession is humbling. You can’t hide behind ’most users won’t notice’, professional designers notice everything, including the things you hoped they wouldn’t look at too closely.
That discipline, treating every screen as if the harshest possible critic was about to open it, is something I still carry into how closely I review implementation today.