How we “Humanized” AI in design: a team’s real-world experience
When our design team took the Udemy course “Revolutionize UX/UI: AI-Design Strategies with ChatGPT,” we were also working on a pretty complex analytics dashboard. That timing turned out to be perfect. Instead of treating the course as a theoretical exercise, we tested some of the ideas in real work and saw what actually made sense vs what was just the theory.
The course covers ideation and user research, personas, journey maps, user stories, flows, UX copy, prototyping, usability testing, building custom GPTs, privacy and AI ethics in design.
But what interested us wasn’t how AI could generate interfaces. What turned out to be far more valuable was how it could support the thinking around the interface: helping us structure a messy problem, question an early idea, compare several directions, or notice something we might otherwise discover later in the process.
In short, AI didn’t become the designer. It became another tool in our toolkit.
What we took from the course
One of the main ideas from the course: AI becomes truly useful when it’s involved throughout the process, not just when we need a piece of text.
We started using it in different situations: when defining the problem, exploring early directions, preparing research questions, checking flows, reviewing UX copy, and thinking through potential usability issues.
One of the most important things - context matters. Ask a broad question, get a broad answer. But when you explain who the user is, what the product does, what the business is trying to achieve and what constraints are already in place, the conversation is a lot more useful.
In practice, this felt less like “prompt engineering” and more like writing a decent brief.
The course also touched on personas, empathy maps, and journey maps. These weren’t new methods for us, but AI was useful in the prep work. For example, it could help organize notes, group similar observations, highlight repeated themes, or point out where information was missing.
But that’s also where it’s easy to overuse it. If there’s no real research behind a persona, asking AI to make it “more detailed” doesn’t make it more accurate. It just makes the assumption look more convincing.
So we treated AI as a way to organize evidence, not create evidence.
The same applied to research. AI can help when preparing interview questions or working through a large amount of qualitative feedback. It’s especially good at doing a quick first pass: grouping comments, identifying repeated topics, or suggesting categories worth looking into.
That saves time, but it doesn’t replace interpretation. Someone still has to decide whether two comments actually describe the same problem, whether a pattern matters, and what it means for the product.
How we applied this to a real project
The project we used during the course was a data-heavy analytics platform made up of several connected reports. Users needed to understand market demand, compare providers with the broader market, and work with both historical and forecast data. The product also needed to turn behavioral and streaming signals into practical recommendations.
So the challenge wasn’t just to “make a dashboard.” Each part of the product answered a different question. At the same time, all those parts had to feel consistent and understandable as one system.
We were working with rankings, forecast values, confidence indicators, filters, historical data, comparison tables, recommendations, and explanatory content. There was much going on.
That created a great environment for testing AI-assisted design methods, as there were plenty of decisions to make before visual polish even started to matter.
In the end, we used AI mostly for three things: structure, exploration, and critique. The actual design decisions still happened in Figma and within the team. AI was mainly useful before that point, when we were trying to understand which direction was worth developing.
Getting to a clear structure faster
One of the hardest things in analytics design is deciding what deserves attention first. When you have five important metrics, two charts, a table, filters, and a recommendation block, it’s very easy to end up with a screen where everything looks important. And when everything is important, nothing really is.
Instead of going straight into layout work, we first tried to describe the screen in terms of the user’s decision. What should they understand within the first few seconds? What information helps them decide what to do next? What is useful, but not immediately necessary?
That gave us a much better starting point. AI was useful here because it allowed us to test different ways of grouping the information without designing every option. Some structures could be rejected almost immediately. Others were worth taking into Figma and developing further.
A compact summary area designed to make the most important signals visible at a glance.
For the summary area, for example, we wanted someone to understand the overall situation quickly instead of reading every metric one by one. The goal wasn’t to show less data for the sake of simplicity. It was to make the order in which the data is understood more intentional.
Catching states before polishing the UI
Another habit we picked up was questioning the happy path earlier. It’s easy to design a dashboard when every chart contains data, every forecast exists, and every filter combination works perfectly. Real products are rarely that clean.
While working on filters and controls, we used AI to generate questions around different states:
- What happens if a user selects a period with no data?
- Should a filter have a default value?
- What happens if several filters together produce no result?
- What happens if historical data is available but forecast data is missing?
- What happens if historical data is missing but forecast data is available?
These aren’t the most exciting questions, but they matter a lot once the product is live.
AI didn’t tell us which state was correct. In many cases, it couldn’t know that. But it made it easier to create a checklist of situations worth discussing before the interface became too expensive to change.
Filter controls used to think through defaults, combinations, and empty states.
That was probably one of the most practical benefits.
AI as a second pair of eyes for charts
Charts were another area where AI worked better as a critic than as a generator. A visualization can look perfectly fine and still communicate the wrong thing. A forecast may look too much like actual historical data. A line may imply continuity where none exists. A confidence value may be technically visible but practically meaningless to the person reading the chart.
So instead of asking AI to create the chart, we described what the visualization was supposed to communicate and asked where it might be misunderstood:
- Could users confuse actual and predicted values?
- Does the chart make uncertainty visible?
- Is the visual hierarchy helping the right comparison?
- Does the chart require too much explanation to be useful?
A trend and forecast view used to test hierarchy, comparison, and clarity.
Not every answer was useful, of course. But this kind of review often surfaced questions that were worth considering before the visual treatment was finalized. And sometimes the most useful outcome was simply having to explain why the current solution was correct.
UX copy was an easy win
UX copy was one of the most straightforward areas to apply AI. Analytics products tend to contain a lot of supporting language: labels, helper text, explanations, recommendations, empty states, and metric descriptions.
Writing one version is easy. Writing five different versions and comparing them is where time starts to disappear. AI made that part faster. We could try a shorter label, a more explicit explanation, or a different tone without treating every small wording change as a separate task.
The key was not to accept the first answer. Some suggestions were too generic. Others sounded overly polished or didn’t match the terminology already used in the product.
So the final copy still needed editing. But the process of getting to a good version became faster.
Where it actually saved time
The biggest time saving happened before high-fidelity design. That was probably the clearest conclusion from the whole experiment.
AI helped us compare more ideas, question early assumptions, think through edge cases, and review information hierarchy without turning every thought into another finished screen.
This matters because polished design is expensive. Once a direction has been turned into detailed screens, components, interactions, and states, teams naturally become more reluctant to throw it away.
If a weak idea can be rejected while it’s still just a rough structure, that’s much more valuable than producing the final screen slightly faster.
Over time, the workflow became fairly simple:
- Understand the problem.
- Give AI enough context.
- Explore a few possible directions.
- Challenge the strongest one.
- Then design it properly.
It sounds obvious, but that extra critique step made the process more deliberate.
Final thoughts
The main lesson wasn’t about generating design with AI. It was about using AI at the right moments.
For us, it was most useful when the problem was still open and there were decisions to make. It helped broaden the exploration, organize information, generate questions, and challenge assumptions before they turned into finished UI.
At the same time, it became very clear where AI wasn’t enough. It doesn’t know the product as well as the team does. It doesn’t understand every technical limitation, every business priority, or every piece of user research unless that context is given to it. And even then, it can still be wrong.
That means the designer’s role doesn’t disappear. The designer still has to decide what’s important, what’s relevant, what can be ignored and how it all comes together into one coherent experience.
For us, that became the most useful way to think about AI in design. It didn’t replace design judgment. It helped us reach the point where that judgment could be applied sooner.
