Recently I attended a discussion about how designers' roles are changing in the AI era. A design lead brought up that familiar point again: execution can increasingly be handed over to AI, and understanding of the product, users, and business is what truly matters most for designers.

Honestly, having heard this from 2023 until now, it's almost given me PTSD—we all know that understanding the business is important. The problem is that this statement often stops right there. Some treat it as a summary of experience, some as proof of seniority, yet few go on to explain: what does "understanding" mean? To what degree must you understand? How exactly does it influence a design decision? When I press further, what I usually get is still that same line: "You need to understand the business more."

A concept that needs to be explained ends up becoming the answer that explains everything—that is rather absurd and hollow.

I want to take this statement apart. Since everyone says business understanding has become more valuable in the AI era, then at the very least it should be made clear: why exactly is understanding the business valuable, and where does that value lie?

One sentence can introduce a business, but it may not support a decision

The business of many products can be introduced clearly in one sentence: helping enterprises complete electronic signatures, helping users manage knowledge, or helping consumers make purchase decisions. Such summaries are very useful—they let someone unfamiliar with the product quickly know what you do.

But a summary omits details, and it also omits the relationships between details.

"Helping users make consumption decisions" is only nine characters. Yet when you actually start building the product, you must answer: is the user deciding whether to buy, or deciding which one to buy? What problem does he want to solve? What kind of help counts as valuable? To reach a conclusion, what information is needed? And on what grounds is that information sufficient to support a judgment? One sentence introduces the outline of the business. These questions are where the business actually begins to hold up.

That said, I don't want to conclude from this that "the business is actually very complex, so it must be deeply understood." That would just be going in a circle and repeating the same grand principle. Some businesses are indeed easy to understand—clear rules, clear boundaries—and people familiar with the domain can grasp them quickly. There's no need to make the business sound mystifying just to prove that design has value.

The depth of understanding also cannot be measured merely by how long someone has talked about it or how many terms they remember. A person can talk eloquently about industry background and still be unable to explain why the solution in front of them is worth doing.

For business knowledge to become the basis of design, analysis is still needed in between: clarifying the relationships among goals, rules, and conditions; knowing which differences would change a judgment; and knowing which pieces of information are insufficient to support a conclusion.

The foundation of understanding is knowing on what grounds a judgment holds

What I understand as the business is: for whom the product solves what problem, through what means it creates value, and the rules that must be followed in this process. Understanding the business then requires further clarifying: how these goals and rules interact, and what they mean for our choices in specific contexts.

Knowing who the user is, is only a starting point. We also need to know why he came here, what he wants to accomplish, and what will hinder him from completing the task. Knowing a rule is also only a starting point. We also need to know whom it applies to, what conditions it depends on, how to handle exceptions, and how to judge when it conflicts with another rule.

Without goals, you cannot judge what an optimization actually improves; without rules, you cannot distinguish whether a simplification reduces burden or omits a necessary step; without an understanding of value, you cannot decide which experiences can temporarily give way and which must be upheld.

So business understanding is the foundation. It may not be the most labor-intensive part of every project, but without it, the judgments that follow lose their footing. No matter how beautiful the solution is, it may just be building a castle in the air for a problem that was never clarified.

This is where restraint is especially needed: distinguish what we know, what we infer, and what has not yet been confirmed. A user searched for a high-concentration skincare product—this is behavior; he wants to buy it—this is an inference about intent; he belongs to the "oil-tolerant skin" type—this crosses into personal characteristics. The three may be related, but they cannot be directly equated. He might be searching on someone else's behalf, or he might want to learn more precisely because he's worried it won't suit him.

If the product directly treats an inference as fact, then stores it in memory and uses it for recommendations, the error will gradually take on a familiar appearance: the system repeats it again and again, as if it knows the user better and better, when in fact it is a million miles away from the user's real profile—going in exactly the opposite direction.

Therefore, understanding also includes awareness of one's own boundaries. If a key premise has not been confirmed, you should ask further, or limit the scope of the conclusion. You cannot fill in missing information on your own just because the solution needs to move forward.

Analysis turns familiarity into testable understanding

Many designers are not lacking in business experience. They have worked on projects, handled exceptions, and accumulated quite keen intuition. The problem is that this experience sometimes stays at the level of "it feels like it should be this way"—ask whether a solution is good, and they can answer quickly; ask why, and they can give a few reasons. But keep pressing: what conditions must hold for these reasons to be valid? Would they still hold in a different scenario? If two goals conflict, which should take priority? Those originally smooth judgments may begin to show gaps.

The point of analysis is to find those gaps.

When building a decision-support product, it's easy to start from the form of the report: how many dimensions should there be, should citations be added, how to make the conclusion look more professional. But before that, we should ask: what exactly does the user need to decide? What information would affect this decision? What kind of help the product provides counts as effective?

A user who has not yet decided whether to buy and a user who is comparing two products require different judgments. A reliable source does not mean the information is relevant to the choice at hand; a product being suitable for use does not mean it is worth buying right now. Without clarifying these relationships, adding more dimensions may just make the report longer.

I think an effective analytical process should be able to move from goals to judgments, trace the prerequisites required by judgments, and then derive from those prerequisites the capabilities the product must provide. Features, content, and interaction gradually gain their reasons along this path. Of course, the process of analysis is often mentally demanding—it requires us to state accurately things we have used for a long time but never clearly defined. And it is precisely in this process that experience has the chance to become a judgment method that can be discussed, corrected, and reused.

The premise of trade-offs is upholding boundary rules

With business understanding and analysis, you still may not arrive directly at the final solution. Products always exist in reality: users have their habits, systems have existing structures, and teams have limited timelines and resources. We need to bring these conditions into our judgment and choose a solution that can hold up. This is trade-off, that is, making trade-offs.

However, in real work, trade-offs require clear priorities. Some things can be deferred, some scope can be reduced, some costs are worth bearing, and some conditions simply must not be broken—what business understanding provides is precisely the basis for distinguishing these things.

A tight timeline may mean reducing the scenarios supported in this iteration; it does not automatically prove that omitting a necessary confirmation step is also reasonable. If the system temporarily cannot support the ideal expression, you can choose a plainer form, but you must judge whether the user can still understand the key relationships and complete the core task. A viable trade-off needs to state clearly: to achieve what goal, what we chose, what we gave up, and what cost we bore. "That's just how reality is" cannot replace this explanation.

At the same time, you should also distinguish which layer the difficulty occurs at. If the rules are not understood, you need to supplement your understanding; if the information relationships are already clear but you don't know how to express them, you need design exploration; if the solution is clear but the system doesn't support it, you need to discuss capability gaps; if there are no resources or scheduling, you need to coordinate priorities. All of these are built on the business context, yet they have different solutions. You cannot hand every problem over to "understand the business a bit more." Understanding can let us accurately identify constraints, but it will not create timelines out of thin air. Seniority also will not automatically turn one kind of constraint into a deficiency of another kind of capability.

In other words, what truly understanding the business means isunderstanding the business and being able to make well-grounded product and design judgments based on the business and real-world conditions.Business understanding determines the basis of judgment, real-world conditions affect the range of options, and analysis helps us identify the cost of each choice.

Judgment also needs to return to reality and accept verification

Making sense still doesn't mean doing it right. A solution gains the basis for trying only after analysis; it also needs to return to actual use to check whether those grounds hold.

We expect users to understand a certain relationship—do they really understand it? We believe reducing one step will not affect task completion—is that actually so? For a concession made for the timeline, is the cost still within an acceptable range? Verification should correspond to the judgments made earlier, not just confirm that the feature has gone live.

Of course, you also cannot evaluate a decision solely by the final result. When information is limited, a reasonable judgment may encounter an accident; a choice lacking grounds may also succeed by chance. One good result is not enough to prove the method is reliable, and one bad result also needs to be distinguished: was the premise wrong, the reasoning wrong, or did a change occur that was not foreseen?

This is not about finding excuses for failure, but about allowing experience to continue accumulating. If you only remember success and failure without knowing where they come from, next time you can still only place your bet on feeling.

Therefore, understanding and judgment do not end when the solution is delivered. Verification will correct our understanding of users, rules, and conditions, and then influence the next choice. Business understanding also gradually becomes solid in this back-and-forth.

In the AI era, what exactly does it mean to understand the business more?

Let's return to the opening line: "In the AI era, understanding the business is more important." Admittedly, AI can help us organize materials, expand scenarios, and discover contradictions, and it can also help analyze and propose solutions. Understanding the business will not automatically become a human-exclusive domain just because AI arrives. Human judgment can also be careless, and AI reasoning likewise needs to be checked.

But when copy, pages, and prototypes are easier to generate, where the solution comes from is even more worth questioning. In the past, we could see a great deal of execution labor, but not necessarily the judgment behind the labor; now, execution has accelerated, and problems where the premise has not been confirmed and the goal has not been defined will also enter the product faster.

A fluent explanation cannot confirm facts for us. A complete set of interfaces cannot decide for us what is worth doing. The stronger the generative capability, the more necessary it is to state goals, grounds, and trade-offs clearly, so that the completeness of the output does not mask the gaps in understanding.

If business understanding has become more valuable in this era, I believe its value lies here: enabling us to define problems, identify conditions, compare choices, and test our own judgments in reality. It serves as the foundation supporting analysis, trade-offs, and verification; and only by entering these concrete decisions can understanding truly translate into product value.