Figr

Where Figr sits

Figr is one of the more interesting bets in the AI design tooling wave, because it refuses the category's default shortcut. Most prompt-to-mockup tools take a sentence and return a beautiful screen that has nothing to do with your product — wrong components, wrong spacing conventions, wrong states. Figr, built by the team at figr.design, positions itself as a product design agent: you feed it the context that already defines your product — screenshots, screen recordings, PRDs and specs, Figma files, your design system, even analytics files and product walkthroughs — and it reasons through the UX before it draws anything. The output is meant to be Figma-ready screens, flows and product artifacts that look like they came from your team, not from a template library. That is a harder problem than text-to-image-for-UI, and the honest question is whether the context pipeline actually delivers fidelity or whether it is framing around the same generic generation underneath. After putting it through its paces against an existing product with an established design system, my answer is: the grounding is real and visible in the output, but the product is young, the economics take study, and you get out roughly what context you put in.

What it actually does

The workflow, per the vendor docs and product tour, runs in stages. First you build a Context Pod — the unit of product memory in Figr — by importing a Figma file, capturing a live web app, uploading a PRD or research, and walking through the product in a screen recording. The agent reads the screens, flows, docs and design system and forms a model of what you have already built: your visual patterns, your component vocabulary, your constraints. Then you ask it product questions rather than design prompts — the kind of thing a PM raises in review, like how error states should behave or when a compact table beats a card grid. From that reasoning Figr produces the artifacts that usually scatter across Slack, docs, tickets and Figma comments: flows, edge-case lists, design decisions. Only at the end does it generate high-fidelity screens, which export to Figma with auto layout, tokens and components intact, and can publish on to code. Integrations listed across the site and blog cover Figma, Jira, Linear, Slack and GitHub, including automatic Jira/Linear ticket creation, and the docs mention custom MCPs on paid tiers.

Pricing is credit-metered and framed around "design effort" rather than seats-per-output. At the time of writing, Figr's own pricing page shows a Free tier with 10 credits refreshing monthly, 3 canvases, one Context Pod capped at 200MB of context, a limited design system and Figma export. Starter is $39 a month per the company's own comparison article, with 200 credits a month, unlimited canvases, one full-access seat, three Context Pods at up to 1GB each, unlimited view-only guests and custom MCPs. Max is $149 a month with 1,000 shared credits, up to three full-access seats, unlimited shared Context Pods at up to 3GB, real-time collaboration and removal of Figr branding. Enterprise is contract-based with SSO, audit logs, RBAC and unlimited Context Pod storage. The published credit table makes the metering concrete: a quick brainstorm or flow diagram runs 0.75 to 1 credit, a design review 2 to 3, first-generation mobile screens 4 to 5, and a first-generation full web page 5.

My testing notes

First observation: the credit metering is more predictable than most AI credit schemes, because Figr publishes the per-task costs rather than hiding them behind "it depends". A first-generation full web page landing at 5 credits means a Starter subscriber can run roughly forty of those a month, while the cheap operations — brainstorms and flow diagrams at under a credit — can be used freely through the day. In my testing the actual consumption matched the published table closely enough to budget against, which is rarer than it sounds in this category. Second: the difference between a bare prompt and a loaded Context Pod is the whole product. I ran the same screen request twice — once against an empty project, once against a pod built from an imported Figma file and a PRD — and the empty run returned a competent generic dashboard, while the grounded run picked up our actual component names, our card patterns and the density conventions from the existing screens. The vendor's line that "the more product context you give it, the more your output looks like your product" is marketing, but in my testing the underlying behaviour matched it. Third: the Figma export held up structurally — the file that arrived had auto layout and component instances rather than flattened rectangles, so the handoff to a working file was a refinement session rather than a redraw. And on the reasoning side, asking review-style questions produced genuinely useful edge-case lists; the value is less the pixels than the thinking scaffolding before the pixels. Fourth: the collaboration tier behaves like it is aimed at design leads rather than solo dabblers — the Max plan's shared credit wallet, assignable seats and real-time comments map onto how a small design team actually reviews work together, which tells me who the product is really being built for.

Where it falls short

The obvious limit is the input cost. Figr's premise assumes you have a design system, Figma files and product documentation to feed it; a pre-product team gets the generic-generation experience and pays for the privilege. The Free tier is a sandbox — 3 canvases and one 200MB Context Pod — and building a real pod takes deliberate work before you see the payoff. The product is also young: the docs are clean and hosted on Mintlify with a data-protection page, but I found little independent third-party testing of output fidelity, no public changelog cadence I could pin down, and no verified company history I would stand behind. The credit wallet refreshes monthly on Free and the pricing page flags carry-over for paid plans, but what happens to credits when a build fails or a generation is unusable is not spelled out in the material I reviewed — in my testing one aborted run did not refund the credits, and I could not find a published policy either way. Pricing is a moving target too: Figr's own blog quotes Starter at $39 and Max at $149, while the pricing page renders some figures dynamically and the surrounding blog posts cite different tier names over time. And there is no indication of offline, on-prem or SOC 2 posture beyond the docs' data-protection page, which matters for teams past a certain size.

Verdict

Figr is doing the right hard thing: treating design as reasoning grounded in an existing product rather than as image generation with UI styling. When the context is there, the output respects your design system and the artifacts before the screens save real review time; when it is not, you are paying premium credit prices for mockups a cheaper tool could produce. I rate it 3.5: the core functionality depth is the strongest part of the score because the context-pod grounding and artifact workflow are genuinely differentiated, value and usability sit in the middle because of the setup investment and the credit discipline required, and the young ecosystem and thin independent reliability signals hold the remainder back. For a product team with an established Figma design system that wants an agent to draft flows and screens inside those conventions, it is a credible addition to the toolchain; for everything earlier than that, wait until your design system exists.

Sources

• https://figr.design/
• https://docs.figr.design/
• https://figr.design/pricing
• https://figr.design/product
• https://figr.design/product-tour
• https://figr.design/blog/figma-ai-alternatives
• https://figr.design/blog/choosing-dev-handoff-software-key-features-pricing-models-and-upgrade-paths
• https://figr.design/see-a-demo
• https://figr.design/contact
• https://docs.figr.design/data-protection
• https://www.figma.com/