Show HN: Figr – AI that thinks through product problems before designing | Hacker News Reader

Show HN: Figr – AI that thinks through product problems before designing

figr.design

10 pointsMokshgarg0035 comments

Built Figr AI because I got tired of AI builder tools market themselves as design tools and end up skipping the hard part.

Every tool I tried would jump straight to screens. But that's not how product design actually works. You don't just design screens. You think through the problem first. The flows, the edge cases, the user journey, where people will get stuck. Then the design comes finally.

Figr does that thinking layer first. It parses your existing product via a chrome extension or takes in screen-records, then works through the problem with you before designing. Surfaces edge cases, maps flows, generates specs, reviews UX. The design comes after the thinking.

It is able to do so because we trained it on over 200k+ real UX patterns and UX principles. Our major focus is on helping in building the right UX by understanding the product.

The difference from Lovable/Bolt/V0: I think those are interface builders. They are good when you know exactly what you want to build but they don't truly help in finding the right solution to the problem. Our aim with Figr is to be more like an AI PM that happens to also design.

Some difficult UX problems we've worked through with it: https://figr.design/gallery

Would love feedback, especially from folks who've hit the same wall with other AI builder/design tools.

Open articleView on HN

In my experience, knowing you have glaring UX problems, or that product does not have an easy intuitive user flow is rarely the bottleneck for developing new & useful user facing AI applications.

There’s usually a very real and very hard to describe data related impracticality that voids the usefulness of a design that appears well thought out and complete.

Additionally enterprise AI products are built on custom integrations, and complexity of maintenance overwhelms the engineering team and leaves very little time to build out new things.

The simplest changes that come from knowing insider customer experience have significant impacts. If the default range for a duration filter is 5-30min, and it turns out the most interesting data is really on 1.5hr+ rows. Or adding search across legacy platforms that bury uniform information under deeply nested modals, which people spend 20+ a week clicking through to collect a usable sample set based on existence of a few keywords. But building a system that returns good search results is the hard part.

I do like the “build on top” pieces in your gallery. If it’s fast and reliable enough to collab during a discovery meeting, or a customer success meeting, that would be genius. Because then you’d have a way to pull customers into the right mindset to articulate frustrations with their current software, iterate on getting those frustrations get translated into concrete designs together, and at the end you walk away with something that proves you both understand and can solve their problem to any audience.

I like the way you've framed the problem, and it's actually an issue I bring up with designers that I work with, not that they go directly to screens, but that they go from problem to ideation too quickly.

We work in hardware, so we don't have UI to work with. UX isn't just UI, which I'm sure you know. I'd like to see something like your product to help guide people through the right questions, rather than finding the solution.

One of the challenges I have with many AI subscriptions is that when you price in credits, I have no idea how many questions, or what kind of workflow that gives me. 10 credits. That could be 3 questions.

This was actually the business model issue we had with our last business, where we had to pay for map tiles, and we loaded thousands of them. For our B2B customers, we came up with a pricing model which said "per 1000 scenes" and they knew what a scene was. We still had no idea how big their scene was going to be, but we priced so that they could understand what they'd get, and they could verify, yes we opened 40,000 scenes.

For our B2C customers, we had a simple monthly subscription because they would only likely use so much. We barely made any money on the consumers, but it helped offset the costs.

This isn't just a you problem. But it is what prevents me from using a lot of, what may be, very good tools.

Hey, "I'd like to see something like your product to help guide people through the right questions, rather than finding the solution"

This is exactly what we do, we ask you very deep question to collect context and make the results much better. We see by using Figr users become much clearer on what and why they want to build.

I understand on Credits bit, its hard to explain simply. Mainly defined it like one hour of design work or 1 screen.

I like that you’re positioning this as an “AI PM that happens to design” instead of yet another screen generator. Most tools are great at producing artifacts and terrible at preserving the reasoning behind them. If Figr could reliably spit out a tight decision log/constraints list from each session (what we considered, what we rejected, and why), that alone would replace a lot of hand-wavy product docs.

The 200k UX pattern corpus sounds powerful, but that’s also the scary part: pattern bias overpowering the specifics of a product. The more you can show “this suggestion came from your own data” (analytics, funnels, support tickets) and let teams tune how opinionated the pattern-matching is, the easier it is to trust it for things like onboarding and billing flows rather than just happy-path demos.

Figr do give out the decision logs and even saves it for your future sessions as memory. Your patterns, decisions, work preference, and more are stored.

On the 200k+ ux pattern, it is more to guide the ux building process to avoid hallucinations and make sure solved problems aren't hallucinated. For example there are only 8-10 different ways you can design a settings section.

Mainly we refer to your product context and use it to think through and build specs, flows and designs.

Reply on news.ycombinator.com