Purl AI
Project overview
Co-founded and designed an AI-powered ideation platform from nothing. Chat interfaces make you work one idea at a time and lose the rest to scroll. Purl replaced that with a board, so marketing teams could hold several ideas open at once, develop them in parallel, and carry the good ones through to a critiqued, actionable strategy
The context
Generative AI tools hand professional users a blank canvas, and a blank canvas is intimidating. The deeper problem was shape rather than volume: a conversation runs in one direction, so every idea competes for the same thread and earlier work disappears above the fold. Marketing teams could generate plenty, but had nowhere to hold it, compare it, or decide with it.
My role
Co-founder and founding product designer. I owned the product vision alongside the execution: research, information architecture, the design system, high-fidelity prototyping and the investor-facing material.
team and timeline
Three co-founders, all working part time: me on product and design, an engineer building the MVP, and a third handling logistics, client relationships and the funding pitch. Six months from concept to MVP.
Constraints
No funding. The MVP existed to be pitched, so it had to look and behave like a finished product on a budget of nobody’s time but our own. I built it in evenings and weekends while working full time at LiveScore, which meant every design decision had to be cheap to build and hard to argue with, because there was no capacity for a second attempt.
Key Metics
22%
Higher task completion than working through the same problem with a conversational AI tool, measured by unmoderated testing across 22 users
6
Months, from first concept to an investor-ready MVP, built part time alongside full-time roles.
2x
Increase in build velocity for the engineering co-founder once the Figma design system and its matching component repository were in place, against his earlier attempts to build from loose designs.
The solution
Problems identified
Research insights
Thinking spaces
People do not ideate in a linear stream. They need distinct modes for generating and for refining.
Ownership builds trust
Users rejected black-box AI. They needed to see clearly what was theirs and what the model had produced in order to feel the final idea was their own.
The overlay was the moment
Testing showed the deep-dive analysis panel was the highest-value feature, which validated moving away from a chat interface altogether.
Experimentation
Decisions & trade-offs
The central call was rejecting the chat interface every competitor had settled on. Chat is cheap to build and familiar to users, but testing showed it was the cause of the problem rather than the way to deliver the solution, so I replaced it with a structured board despite the steeper first-use curve.
With no funding and three part-time founders, I cut roughly 40% of proposed features to protect a single path through the MVP. The hardest to lose was multi-user collaboration, which was the most requested idea in the group and also the least practical to build at that stage. Cutting it was the decision that made the six-month timeline possible.
I also used the high-fidelity Figma prototype as the investor asset rather than building a separate deck, so design decisions had to carry a commercial argument as well as a usability one.
Lessons learnt
Systems save startups
Building a design system for an MVP felt like a luxury at the time. It doubled the engineer’s build velocity once development started, because nothing had to be interpreted or re-specified.
Learning to reject good ideas
Multi-user collaboration was a genuinely good feature and cutting it was the right call. Turning down bad ideas is easy. Protecting a core proposition from good ones is the part that decides whether anything ships.
Part time has a ceiling
We built a working MVP and a real product argument, but three founders working evenings and weekends could not generate the traction the funding conversation needed, and eventually the others chose not to continue. The design work stands up. The operating model did not, and I would now test whether a team can actually resource something before designing as though it can.
