There’s a take going around that AI makes everything look the same. Same hero sections, same illustrations, same rounded cards with the same gradients. You’ve seen the screenshots. The LinkedIn posts. The threads.
And they’re right. If you point AI at a blank canvas and say “design me a landing page,” you’ll get something that looks like the last fifty landing pages it was trained on. That’s a real problem. Fair enough.
But I do B2B UX. And the thing those posts keep missing is that UX is quite a lot more than aesthetics.
The hard part isn’t how it looks
I wrote about this a while back: AI tools are great for quick sparks but not so great for long runs when it comes to visual design. That hasn’t changed. What has changed is what I’m asking AI to do.
In B2B, the visual layer is the smaller challenge. You establish your design system, set your tokens, define your patterns. I have audit agents that keep the UI consistent with the design system. That runs in the background and it’s not the point of this post.
The point is the data.
Does this dashboard still make sense when there are 47 critical issues instead of 3? Does the onboarding flow work when the account has zero historical data? Does this table communicate anything useful with 3 rows? What about 3,000? What happens to the layout when every status badge is red?
Those are the questions that determine whether a B2B product actually works. And if you’ve tried answering them with placeholder text and static Figma frames, you know how slow that is.
What I actually do
I describe the business logic for a screen: what the data represents, what the entities are, what the relationships look like; and ask Claude to generate mocked data. Not “John Doe, 123 Main Street” filler. Domain data. Crawl rates, render statuses, cache hit ratios, error distributions. Data that has the right proportions and the right edge cases built in.
There is also a simpler approach that started to work like a charm (with some inconsistencies of course, but manageable). I ask Claude to figure out the business logic of the app and apply changes to data so the data makes sense.
Then I start moving things around.
I ask Claude to rebuild the same dashboard with a bar chart instead of an area chart. Or a table instead of a chart entirely. The data stays coherent because Claude understands what it represents, not just how it’s shaped. I rearrange the layout: summary cards above the table, filters inline instead of in a sidebar; and every variation gets meaningful data. The decisions aren’t about what looks best in a screenshot. They’re about what communicates best when the numbers are real.
Last month I had a chart showing individual data sets with their trend lines. With mocked data for a healthy account it looked fine: three or four lines, readable, clear. Then I generated data for a large account and the chart became a mess. Too many bars, too many trend lines overlapping, completely unreadable. I wouldn’t have seen that in a static mockup with three placeholder series.
But because the data was right there and I could iterate in minutes, I started thinking differently. What if the default view clustered individual data sets into higher-level groups: a summary you can actually read? And then when the user filters down to a specific segment, the chart expands to show the individual sets within that cluster.
The chart adapts to what the user is actually looking at instead of dumping everything on screen at once. That design decision came directly from seeing the wrong version first. AI didn’t make that call, it just made it possible to see the problem fast enough to do something about it.
And then the part that used to eat entire days: scenario variants.
- Healthy state – everything’s working, metrics look good, no alerts
- Heavy issues – 40+ critical problems, warnings everywhere, tables full of errors
- Newly onboarded user – empty states, first-run guidance, no historical data
- Stale account – data exists but nothing recent, ambiguous statuses
- Scale edge case – thousands of rows, long strings, truncation pressure everywhere
I generate all of these in minutes. In running code, with data that makes sense for each scenario. I can see immediately whether the design survives. The healthy state and the heavy-issues state usually look fine. The empty state and the scale case are where things actually break. And I find out now, not after development starts.
Generating vs. verifying
The slop conversation keeps missing a distinction.
If you use AI to generate a new visual identity from scratch, you will probably get something generic. The models converge because they trained on the same corpus. The critics are right about that and I agree with them.
But that’s one use of AI. There’s another one where you come with your own ideas, your own patterns, your own design system, and you use AI to stress-test those ideas against realistic data. To rapidly explore layout variations. To be a sparring partner while you make decisions. You’re not asking it to be creative. You’re asking it to be fast and honest about what breaks.
That’s prototyping at a speed I couldn’t reach before.
The AI slop conversation is about aesthetics. Fair, aesthetics matter. But B2B UX lives in the forms, the tables, the edge cases, the empty states. If you’re using AI to verify your own thinking against real data, you’re looking at a different tool entirely.
