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.

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.

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.