figr ai • 0→1 PRODUCT STRATEGY & DESIGN
Taking Figr from an early hypothesis to a product direction validated in closed beta
My role
Product Designer
Years
February - September 2025
Platform
Web Application
Scope
Team
4 Engineers & CTO
TL;DR
Testing three product bets turned a broad AI ambition into an open canvas used by around 20 beta teams
Figr began with a belief: AI could help product teams build better. There was no established product or roadmap yet. I turned that ambition into three testable bets, designed the proof of concept and carried what survived into closed beta.
Worked with 5 partner teams and spoke with 50+ product managers and designers
Tested 3 hypothesis before investing in the complete product
Onboarded around 20 teams into the closed beta
problem discovery
We started with an ambition, not a roadmap; so the first job was deciding which problem deserved a product
At pre-seed, jumping into interface design would have been the easy part. The harder question was which product problem AI should own.
Working with 5 partner teams and speaking to around 50 PMs and designers, we studied how work moved from a vague problem to a shipped experience; and where context vanished between documents, meetings and design files.
two sides of the problem
PMs were deciding what to build. Designers were trying to make that direction work. Different problems within the same product journey.
Existing AI tools served both groups at the point of execution. They could expand a prompt or generate an interface, but they did not carry the reasoning and product context that connected the PM's intent to the designer's decisions.
The roles had different jobs, but the same underlying break: too much of the product thinking was lost before a useful prototype existed.
Open-ended problems
Loss of context
Product Managers
Started with goals, feedback and loose requirements, but no clear direction.
Inherited ambiguity
Scattered context
Product Designers
Received that direction through briefs, meetings and disconnected artifacts.
Pain Points
Needs
market opportunity
Research showed that AI could generate a new screen quickly, but struggled to understand the product around it
ChatGPT, Claude, v0 and Lovable moved quickly from a prompt to a fresh interface. They struggled inside an existing product, where decisions depended on current screens, past choices, user evidence, requirements and a design system.
Longer prompts and more attachments helped, but the output could still look plausible while missing what made the product specific.
1
Problem
definition
2
Research & Market Analysis
3
Concept development & vaidation
4
Strategy & business analysis
5
Prototyping & early design
The gap in AI-process
Current Tools
6
Testing & market feedback
Initial hypothesis
Before designing the product, we built the roughest thing that could disprove our three biggest assumptions
The proof of concept was deliberately small. It only had to tell us which parts of the idea deserved a product around them.
1
Structure context upfront through separate user, product and constraint fields
2
A gallery-like canvas for generated designs, Markdown and Mermaid flows
3
Proactive questions designed to challenge assumptions and uncover missing cases
We believed...
We learned…
Result
Structure context upfront through separate fields
People hesitated over the categories and had to organise their thinking before receiving value
Not Validated
Ask before creating through proactive AI questions
Questions exposed missing goals, constraints, assumptions and edge cases
Validated
Keep the work connected through a shared canvas
Teams understood documents, flows and designs as parts of one evolving direction
Validated
The opportunity was not simply faster screen generation:
Could Figr combine product context with UX reasoning to help teams decide what to build before generating the interface?
Open-ended problem led to many directions & quick ideations
validating & un-validating hypothesis
The first assumption failed: teams wanted to begin with messy problems, not organise context for the AI
The structured setup asked people to make sense of their problem before Figr had done anything useful. We replaced it with one open input.
Teams could begin with an incomplete thought, an existing artifact or a loose brief. Figr asked for missing context only when it became relevant, then kept the resulting documents, flows and designs visible together.
The shift was small in the interface, but fundamental to the product: users no longer had to prepare a perfect prompt. The product helped them develop a better problem.
Failed hypothesis: Structured context information in the POC
UI restructuring for self-serve
The closed-beta interface used conversation to start the work, then made the canvas; not the chat; the product
Most AI tools placed chat at the centre and treated the work as its output. We reversed that hierarchy: the centred query was temporary; the canvas was persistent.
UI coverage and structuring
Anatomy of the canvas
Canvas
Hold the problem, reasoning and outputs in one expansive workspace
AI Artifacts
Give documents, flows and designs spatial structure and visible relationships
Fixed UI
Keep navigation & global actions available without competing with the work
Contextual UI
Give users access to the specialized tools to manipulate the content of the canvas
Modal UI
all the windows, modals, and pop-ups on top of the other application layers.
The canvas layers coming together
The interface followed a simple rhythm:
Start openly with one centred input.
Clarify progressively through questions in the same focal area.
Work spatially as the query gave way to connected material on the canvas.
Figr now felt less like a prompt-to-output tool and more like a place to think with AI. But the structure exposed its next problem: keeping the query open obscured the canvas; closing it hid the conversation.
Attachments management on the canvas
Even in the MVP, a little delight is necessary
patterns & validations
Around 20 beta teams confirmed where Figr was different, and where the experience still depended on us
As teams used Figr on real work, three patterns kept appearing:
Existing products created the clearest value
Teams got the most value when they brought an existing screen, flow or artifact to improve or extend.
Deeper questions built trust
Meaningful clarification showed that Figr understood the complexity instead of jumping straight to a design.
Harder problems made the difference visible
Teams reached for Figr when simpler generation tools had produced shallow results or they were stuck.
UI restructuring for self-serve
The canvas was where teams created value; but organisation management was necessary to make that value self-serve
Designing Figr from scratch meant designing more than its primary workspace. The canvas would hold the work and command most of a user's time, but a self-serve product could not rely on us to place every person in the right organisation or resolve every access request.
Mapping different parts for organisation management
learnings & reflections
Early-stage design was less about protecting a perfect process; and more about turning chaos into the next useful decision
Products rarely begin inside neat business frameworks; designers can help absorb the chaos. My role was to turn changing assumptions, user evidence and technical constraints into the next decision the team could act on.
Good product judgment sometimes means letting design ego go. Our POC was not polished, but it exposed a flawed interaction before it became expensive to change. I learned to evaluate early design by what it helps us understand—not how impressive it looks—and to let go of a direction when user evidence no longer supports it.
The lesson was simple: in 0→1 work, making it easy to be wrong can be more valuable than trying to look certain.
This phase established Figr's interaction model. The next one was about giving it memory, continuity and enough product depth to work across a team.
Connect with me