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.
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.