Recently, I asked AI to help me redesign the interface of Intent. I use this product to manage my goals, projects, tasks and materials, and I am also adding the ability for AI to carry out tasks.
We spent several days revising it: adjusting layouts, adding a sidebar, unifying colors and incorporating new pages. Some versions were indeed better than the previous ones, but as I kept looking and using them, I still found many things that felt uncomfortable.
AI would tell me that the features had been implemented, the tests had passed, and both desktop and mobile had been checked. Yet when I opened the pages, I still found the colors inconsistent, the layouts awkward and the details rough. It had proved that part of the work was done, but it had not answered the question I cared about most: was this product actually well designed?
I cannot name every problem in professional terms either. Sometimes all I can say is “this is too big,” “there should be a calendar here,” or “this interaction is wrong.” Later, I realized that whenever I proposed a specific fix, AI might keep revising in that direction, even though the fix itself might not be right.
This made me reconsider two questions: what exactly are product design, UX and UI each responsible for? And when I do not understand design, how should I work with AI to get it right?
My initial understanding was straightforward: product design decides which features the software has, while UI and UX handle interaction and color. That distinction helps start a discussion, but it is not enough.
Product design first needs to answer who encounters what problem, under what circumstances, why it is worth solving, and what tradeoffs we are prepared to make. Features are simply the outcomes of those judgments. Even if tasks, projects and reports are all present, that does not mean they have been organized into a product that is useful to me.
Intent’s home page exposed this problem. Projects occupied a large part of the page, but when I opened it each day, my first concern was what I needed to do today. Projects mattered, of course, but in that situation they needed to provide context for the day’s actions. Without establishing that priority, changing colors or adjusting corner radii would do little to make the home page easier to use.
UX, or user experience, concerns the entire process from having a need to getting a result. It includes how I find an entry point, whether I have to enter information repeatedly, and whether I can tell what happened after an action. It also includes waiting, failure and recovery.
For me, that process also spans WeChat and the website. I want most everyday communication to happen in WeChat, while the website helps me browse, compare and manage information. For example, sending a sentence to get AI started feels natural; viewing the status of multiple conversations at once and comparing their outputs is better suited to a page. Deciding which channel should handle which activity is already part of experience design. It cannot wait until we start drawing buttons.
UI turns these decisions into a visible interface that people can operate. Where information sits, how large headings are, how dense lists are, which button stands out, and how colors communicate status all affect how I understand and use the product. It goes far beyond choosing a color palette at the end.
These three layers can be discussed separately, but they are hard to work on independently. If the hierarchy is unclear while designing a page, product priorities may need to be reconsidered. If a user cannot complete a path, the entry point or even the feature scope may need to change. When revisions are limited to patching the current page, structural problems can easily be left for styling to carry.
Still, thinking clearly about the product will not automatically produce an attractive interface. Visual design requires serious work of its own.
When I say “the colors feel uncomfortable,” it does not necessarily mean a particular color is unattractive. A color that works well on a small button may draw attention away from the content when spread across a large area. Coordinating backgrounds, surfaces, text, borders and status colors is much more complicated than choosing a green or purple I like. Making text very light might look gentle, but it can also make reading difficult.
The same applies to layout. More whitespace is not necessarily comfortable, and more information is not necessarily confusing. For content that needs to be compared, an appropriate density can reduce scrolling back and forth. For content that needs careful reading, line length and paragraph spacing matter particularly. Font sizes, alignment and control dimensions all eventually appear together on the same page.
Consistency, then, can solve only part of the problem. An entire interface can be consistent and consistently difficult to use. Checking whether the code shares color variables cannot replace opening the complete page and seeing where the eye goes first, whether reading flows naturally, and whether the main action is clear.
Different products also call for different forms of expression. A portfolio website can leave room for imagery and personality; a work tool used for long periods each day needs a stable, clear interface that is easy to scan. Even a product’s introduction page and its working pages need not serve the same expressive purpose. When borrowing from examples, we need to understand why a design suits its situation, rather than judging only whether its screenshots look good.
After this experience, I want a more orderly design process.
First, describe the most important usage scenarios concretely. For example, after opening the home page, I should be able to find the first thing I need to do today. After entering the conversations page, I should be able to distinguish those still running from those that need my response. Descriptions like these help determine which content should appear first.
Next, organize the information and paths through the interface, then complete a small number of representative pages using real content. Long titles, multiple records, no data, execution failures and mobile screens should all appear at this stage. If a design works only with a few tidy sample cards, the problems will return when real content arrives.
Once the layouts and visuals of the representative pages hold up, extend the rules to other pages. Only then does unifying fonts, colors and components make sense: what is being unified is a design that has already been checked, rather than simply the first set of styles we found.
Finally, acceptance checks need to be separate. Whether features work correctly requires checking data and execution results. Whether operations are convenient requires actually completing tasks. Whether the visuals are coherent requires viewing complete pages loaded with real content. These checks cannot replace one another, and the designer’s own judgment cannot replace actual use by users.
There is one more thing that calls for a new division of responsibilities between AI and me.
I can tell it what matters most to me, which step is frustrating, what I do not understand, and offer my own suggestions. But I should not have to come up with the right layout, colors and interaction design myself before I can get a good result.
If I say “make this bigger,” AI should determine whether I cannot read the text, cannot find the main point, or really need more space for content. It needs to judge whether making it bigger is the right solution and whether doing so would make other information harder to find. It can disagree with my proposed solution, but it should explain why, provide alternatives I can compare, and respect my final decision.
That is the kind of professional help I want. My feedback comes from actual experience and deserves serious attention; the solutions that occur to me on the spot need to be examined. When the two are mixed together, both sides can stay very busy without necessarily improving the design.
At this point, I still cannot say that the interface problems have been resolved. We have organized these insights and added them to the rules that guide AI’s work. What matters next is whether those rules change the next actual design iteration: will it diagnose the problem before proposing a solution? Can it produce a complete, coherent page? When I open the product, will I find it easier to see what needs doing and get it done?
To me, that says more about progress in design than hearing it tell me once again, “the style is unified and all tests have passed.”
Thanks for reading.