You skipped the first question. Now you’re adding AI

Introduction: why the first question still matters

When a team undertakes “digital transformation” or “smart automation,” the first temptation is to jump straight to tools and technologies. Artificial intelligence today looks so powerful and universal that it feels like you can immediately start solving business problems—automating, analyzing, forecasting—and only later “stick on” some interfaces.

But disappointment often follows just as quickly: users don’t understand what the system is doing; the solutions don’t deliver the expected value; data piles up while the interface remains cumbersome and inconvenient.

This is a familiar trap: we skip the very first question and immediately add AI.

What the first question actually is about

In UX design and product development, the first question usually—somehow or other—sounds like this:

What are users actually trying to do and why?

It isn’t a question about technologies or even about product features. It’s a question about the goals and constraints of real people:

• What work are they doing manually right now?
• Where do they spend the most time and make mistakes?
• What do they consider a successful outcome of their work?
• What prevents them from achieving that right now?

At first glance, this might seem trivial or even obvious. But it is precisely at this level that the most important decisions about a future AI-powered product or feature are made.

---

How skipping the first question leads to AI problems

A typical project scenario: “Let’s quickly add AI”

The team gathers for a standup and starts thinking along these lines:

1. We have lots of data—users, clicks, logs, transactions.
2. We have an AI platform and a model.
3. Let’s build recommendations, automate a task, or create a chatbot.

And soon enough, stacks of screenshots of a new design are being prepared: a chatbot in the bottom-right corner, a recommendations block on the product page, an automated report in the dashboard. Users’ actual questions are left out of the picture:

• What should they do if the recommendation is wrong?
• How can they understand why the system made that particular decision?
• Should they trust the automated result or better double-check it?

This is exactly what happens when you skip the first question. When you start with technology and “data,” not with users’ real tasks, you can easily build a complex system that looks smart but doesn’t actually solve the real problem.

Why this is especially painful with AI

AI systems bring several additional complications:

• Unpredictability. AI models probabilities. The result is rarely guaranteed to be correct.
• Nonlinearity. A model may perform well on one scenario and poorly on another, without an obvious reason.
• Context ambiguity. The model doesn’t always know what is critical and what isn’t in real life.

This makes UX design—especially design around decision making, errors, and trust—no less important than the algorithms themselves.

---

First the user’s context, then the model’s context

Step 1: understand the user’s work before adding AI to it

Before you plug in a model, you need to get as close as possible to the real user’s work and their context:

• Tasks cards in real usage scenarios.
• Grey areas and ambiguous decisions.
• What people call work routine: repetitive operations and manual fixes.

For example, if you’re automating customer support, don’t just stop at lists of tickets. Ask yourself:

• What types of requests are most frequent?
• Which requests take the most time?
• Where do agents currently make mistakes and have to contact customers again?

At this level, you’re not talking about models yet, but you’re already understanding where exactly automation might really help.

Step 2: clearly define what AI should do

After you understand the user’s context, you can formulate a concrete task for the AI:

• Not “improve support,” but rather “distribute incoming tickets into categories with accuracy no lower than X.”
• Not “smarter data analysis,” but “predict the probability that an order will be canceled within the next three days.”

The more precisely you define the model’s problem space, the clearer it becomes what the user should see and how they should interact with the result.

---

How to integrate AI into the interface without breaking the user experience

Not just “smart chatbot” or “recommendations”

Many projects start from the idea of “adding a chatbot” or “building recommendations.” These are popular templates, but they’re not a panacea. AI in the interface can play different roles:

• Assistant. Helps the user complete a task faster and more accurately.
• Consultant. Suggests options or explains possible consequences of decisions.
• Author. Partially or fully generates content (such as texts or drafts of documents).
• Analyst. Reveals patterns and shows them to the user in understandable form.

Each role imposes its own requirements on the interface design and on the model.

Designing transparency and trust

Users should understand not only what the system does, but why. Otherwise they start behaving as if there is no AI: they either ignore its results or, conversely, blindly rely on them without critical scrutiny.

To build trust, you have to design transparency and control:

• Clear limitations. The AI is not always right. This needs to be stated explicitly in the interface, or hinted indirectly (for example, by color or iconography indicating error probability).
• Explanation. Otherwise users don’t understand why the system made that particular decision.
• The ability to correct or adjust the result. Otherwise users feel trapped by the automation.

In the simplest case, this might look like basic information about errors or inaccuracy of the model’s prediction.

Designing for errors: how AI can be wrong and what it means for UX

When a model works with probabilities, errors are inevitable. AI errors aren’t like software bugs:

• They can be systematic.
• They can be related to characteristics of the data or the usage context.
• They can appear not immediately but after some time.

Therefore AI errors aren’t just a technical problem; they are a design problem: how to explain to the user that the model was wrong and what to do next.

---

Example: what an AI interface looks like without the first question and what it should look like

Incorrect approach: adding AI without understanding user context

Consider a hypothetical example. Suppose you’re building a CRM system for sales reps and decide to add AI to automate features:

// Example of a poorly fitting AI-powered interface
function SalesPipeline({ deals }) {
  return (
    <>
      <AISuggestionsList />
      <DealsTable deals={deals} />
      <ChatbotWidget position="bottom-right" />
    </>
  );
}

Here AI is added almost as decoration:

• There’s a list of suggestions, but it’s unclear where they come from.
• The chatbot is sitting “next to” everything but not integrated into the user’s workflow.
• It ignores the fact that sales reps make decisions based on personal context and communication history.

Correct approach: from the user’s task to the model

Now imagine that we first ask ourselves: what are sales reps actually trying to do and which of their tasks can truly be automated or supported?

Based on that, you can design an interface in which AI is integrated into the user’s workflow and acts as an assistant or consultant on specific tasks.

---

Practical tips: how not to skip the first question when working with AI

1. Articulate the user’s task before you articulate the model’s task

Write short but specific statements of real people’s tasks. For example:

• “How does a sales rep quickly understand which deals are at risk of falling apart this month?”
• “How does a call center agent shorten talk time without worsening service quality?”

Only after that should you move to framing the model’s task, for example:

• “The model predicts the probability that a deal will fail within a month.”
• “The model suggests real-time answer scripts to the operator.”

2. Define what will count as “success” for the user and for the model

For the user, success might be:

• Reduced time to complete a task.
• Fewer errors.
• Better ability to make high-quality decisions.

For the model, success can be measured with metrics like accuracy:

• Prediction accuracy.
• False positive rate.
• Response speed.

But it’s important to remember: the model’s success doesn’t automatically equal the user’s success. If the model predicts well but the interface doesn’t let users do anything useful with that prediction or actively frustrates them, the product still doesn’t work.

3. Don’t be afraid to revise the solution architecture

If after analyzing the user context you realize that the model’s task doesn’t match the real problem, or that you can’t solve it well given the data and resources you currently have, it’s better to revisit the solution or simply drop AI in that part of the product.

Sometimes the right UX design choice is not to add a model at all, but to simplify the interface or workflow enough that users can easily solve their task without sophisticated AI.

4. Add AI gradually and iteratively

Don’t try to build immediately a complex system that does everything “for the user.” Most of the time it’s better to:

• Start with a small task that can be automated or supported by a model.
• Give users a simple interface for that task.
• Iterate on both the model and the interface based on real usage.

This helps reduce risk and get valuable feedback from users faster.

---

Conclusion: go back to the first question before adding AI

When you start a project or feature with artificial intelligence, the temptation to dive straight into technologies and data is strong. But the first question—“What are users actually trying to do and why?”—remains key to success.

As practice shows in many teams and companies, it’s the AI projects that begin with a deep understanding of the user’s context rather than with the model that achieve the best results and create truly useful products. Artificial intelligence can amplify design and help people—but only if it isn’t used as a replacement for truly understanding their tasks and problems.

---

English translation: