Don't have AI implement UI vaguely/without clear direction
This page has been translated by machine translation. View original
The cost of "drawing design" in UI has decreased. Default design systems like shadcn — libraries that comprehensively handle components and design tokens — have emerged and matured. On that foundation, AI agents freely bricolage, implementing UI without human intervention.
Just as programming in engineering moved from assembly language to higher-level languages, and programming languages themselves have been refined to become more modern, UI implementation is also shifting to a higher layer of abstraction. Just as parts of coding work are being replaced by AI, defining how UI should be built is becoming increasingly important.
In other words, the "thinking work" of articulating purposes, user flows, priorities, and decision criteria becomes more important in UI implementation going forward.
On the other hand, giving vague instructions to AI produces UI that merely avoids being broken.
- "Make it look like a trustworthy SaaS screen"
- "Modern and easy to use"
- "Make it a nice-looking dashboard"
Even with such instructions, something visually safe can be created. However, being safe is not synonymous with being fit for purpose.
Even if the appearance is polished, if the path to the goal is unclear, information lacks appropriate prioritization, or the amount of information is insufficient or excessive, it cannot be said to function adequately as UI. Even if it seems easy to use because the creator has the full picture of the product in their head, it can impose high cognitive load on users encountering it for the first time.
So how should we think about and create "functional UI" that goes one step further? This article organizes not the techniques for drawing UI, but the thinking framework that comes before it — for organizing purposes and user behavior and articulating them into a form that can be handed to AI.
What to Think About Before Implementing UI
What should you think about before having UI implemented? Rather than the appearance of the finished screen, you first need to understand the user's problems and think about how to solve them through UI.
Let's consider the particularly important aspects of user flows, feedback, states, and priorities.
User Flow Design
Think about what problems users have, what they see, and through which actions they achieve their goals.
Even if you pack all the necessary features into a screen, users still cannot determine what they should do next. Naturally guiding users through the actions needed to achieve their goals and reducing confusion is an important element of good UI.
User flow design is not simply about making actionable areas easy to find — it requires thinking about in what order to present information and what decisions to prompt, and then what actions to guide users toward based on that. You are designing the flow through which users reach their goals.
Now that PCs and smartphones are sufficiently widespread, we can assume users have internalized certain interaction conventions to some extent. For example, they distinguish information importance through visual hierarchy, expect buttons to be interactive, and expect scrolling or swiping to reveal more or additional content.
Leveraging these existing conventions, arrange information and actions so users can naturally predict the next operation. Rather than explaining everything from scratch, you need to design so that the right behavior is placed where users expect it, and what to do is naturally understood.
Priority Design
Even when all information is necessary, there is a gap between that and what information users need at a given moment. There are also limits to how much information can be understood at once.
Therefore, rather than presenting all information and actions on a single screen with equal weight, you need to think about what you want users to recognize first and what to treat as supplementary information.
For example, for users trying a service for the first time, an overview, pricing, and benefits may be important, but for existing users, their recent status and next actions are more important. Even with the same entry point, what matters differs depending on the user's situation.
Also, if "Create New" is the primary action in an admin screen, make that button the most recognizable, while secondary actions like "Export" or "Settings" should appear relatively less prominent.
What's important is not simply reducing information. It's presenting the information users need to make decisions at that point — neither too much nor too little — and creating a state where they can recognize what matters most.
Priority design includes deciding not only what to show, but also what not to show prominently right now.
Feedback and State Design
Returning appropriate feedback to user interactions is also important.
For example, when a submit button is clicked, the button should become inactive and indicate that submission is in progress. When submission succeeds, success should be communicated; when it fails, failure should be communicated, and the button state needs to be updated accordingly. When a link is clicked, users also need to be in a state where they can tell that a screen transition or loading is in progress.
If there is no response to an action, users cannot determine whether the process was executed, leading them to repeat the same action or feel anxious. UI must not only receive actions but continuously communicate "what is happening right now" and "what resulted from the action."
Therefore, it is important to design not just the normal screen state, but also states including loading, success, failure, and disabled. Enabling users to determine what they should do next for each state is also one of UI's roles.
Structuring Thoughts into Language
Words alone like "trustworthy," "modern," and "easy to use" may be enough to create a design that doesn't break down, but are insufficient for creating UI that pinpoints and solves user problems.
Of course, there is no need to reject such intuitive words themselves. Rather, they are a starting point for thinking about design and, in the sense of the impression users ultimately receive, also an endpoint. What's needed is not to handle such feelings as-is, but to break them down into who you want to give that impression to, why, and what behavior you want to connect it to as a result.
For example, looking only at the decision to "use red," red is merely an expression that constitutes the UI. However, thinking "I want users to recognize this as a dangerous operation and prevent misoperation" creates a reason between the expression and the purpose.
The same applies to typography, spacing, border radius, and component placement. If you have a feeling like "I want it to feel luxurious" or "I want to give a futuristic impression," think about who you want to give that impression to, why it's necessary, and what kind of judgment or behavior you expect as a result.
What's important is not specifying in detail what expression to use, but articulating why that expression is needed. Even if you let AI decide the specific typography, spacing, and components to use, the premises needed for those decisions must be provided by humans.
From user problems and business purposes, organize the expected judgments and actions, and connect the reasons to UI expression. Rather than handing intuitive words directly to AI, articulating the reasons between purpose and expression is what matters.
Finally
AI has lowered the cost of drawing UI. More people than ever can now easily create UI at a certain level of quality. In that context, what becomes more important is being able to explain "why this UI."
By understanding the drawing design and thinking design layers as separate, it becomes easier to see how much can be left to AI and, conversely, where humans should focus. I believe that what will matter in future UI implementation is not simply having AI create UI, but being able to think about the underlying purposes and decision criteria and evaluate what comes out.
In this article, I deliberately limited the scope to UI implementation rather than "design" as a whole. The word design refers to something far too broad, and clearly defining its boundaries is itself difficult.
I think it is a concept broad enough that, substituting "design" for "nature" in a passage from Pascal's Pensées, it still holds:
Nature is an infinite sphere whose center is everywhere and whose circumference is nowhere.
That is precisely why, rather than trying to address all of it, I organized "thinking design" from the limited scope of UI implementation in AI coding.
