Han Design Drops the Configuration Quiz and Adds an Autopilot for AI-Generated Pages
I've been tinkering with Han Design lately.
It was originally a Chinese-style web design Skill for AI Agents, containing themes, colors, fonts, components, patterns, layout rules, and CSS assets like han.css and han-scoped.css.
There's actually quite a lot of stuff in it.
But the more I used it, the more something felt off.
The more capabilities there are, the harder it is for users to actually use them.
This is very awkward.
Users just want it to "look a little better"
The scenario is extremely simple.
A user says to the Agent:
Help me make this page look a little better.
Then the Agent starts asking questions:
- Do you want Song Dynasty style?
- Do you want Tang Dynasty style?
- Do you want ink wash painting?
- What visual intensity level, 0, 1, 2, or 3?
- Do you want scroll cards?
- Are you using React or Vue?
- Do you need local theme isolation?
One question after another.
Come on, they just want to make the page look nicer. Do they really need to get a certificate in Eastern Aesthetics Product Management first?
I later realized the problem isn't that Han Design lacks capabilities, but rather:
I kept adding capabilities, but dumped all the decision-making costs of using them onto the user.
Lots of themes? The user chooses.
Lots of components? The user assembles them.
Lots of cultural rules? The user decides.
Lots of integration methods? The user has to explain their tech stack first.
It's like building a high-performance car, and the moment the user gets in, you hand them a manual:
Please adjust the suspension, ignition timing, and transmission logic first.
But the user just wants to go home.
So this time, I stopped adding more components and started adding "autopilot" to Han Design.
What exactly was changed this time
Six areas were modified this time.
| Modification | Problem Solved |
|---|---|
| Removed the question bombardment, generates a design brief internally | Users don't need to answer a long list of configuration questions |
| Added 0-3 visual intensity levels | Replaces component names with "lighter, heavier" |
| Added 6 complete page Starters | No longer starts building pages from scattered parts |
| Auto-fills content drafts | Pages are no longer just a few empty titles |
| Browser self-review and self-correction | Actually opens the page to look, fixes problems when found |
| Changed the default prompt to a workflow | Turned a slogan into an executable process |
It looks like modifying a Skill document, but it's actually changing the product experience.
First cut: Stop making users fill out configuration forms
The previous process was like this:
User makes a request
↓
Agent finds information gaps
↓
Agent generates a long list of questions
↓
User answers
↓
Agent starts building the page
Now it's changed to:
User makes a request
↓
Agent scans the project context
↓
Internally generates a design brief
↓
Starts building the page directly
The Agent will look at these things on its own:
- What type is the current project
- What pages and routes already exist
- Can existing components be reused
- Are there any images in the project
- What is the current brand language
- What is the most important action on this page
Then it forms a very short judgment internally, for example:
A product landing page for a small design team,
core action is to apply for a trial,
use the Ocean Orchid theme,
visual intensity 1,
keep the existing React form,
avoid the cliché neon AI aesthetic.
This brief is for the Agent's own use, not to bother the user.
There's only one situation where it needs to ask: when the missing information would genuinely change the business objective.
Theme, font, what the cards look like, how much decoration to add—these shouldn't become the user's burden.
Second cut: Turning visual intensity into a "decoration budget"
Users might not know what .han-frame-window is.
But users can definitely articulate:
I want it lighter. I want it more pronounced. I want it a bit dramatic.
So I defined four decoration budget levels, 0-3, for Han Design.
| Level | Name | How to use |
|---|---|---|
| 0 | Token | Only adjusts colors, text, spacing, borders, and states; suitable for Dashboards, back offices |
| 1 | Restrained | Places one quiet editorial decoration; suitable for official sites and SaaS |
| 2 | Distinct | Adds a set of cultural structures; suitable for tea, apparel, lifestyle, and brand sites |
| 3 | Dramatic | All decorations on; suitable for festivals, games, exhibitions, and marketing pages |
The most important part of this system isn't the four numbers.
It's that the Agent finally has the concept of a "decoration budget."
Just because the library has lanterns, scrolls, seals, and screens doesn't mean they should all appear on the same page.
Design failures often happen not because of a lack of capability, but because every capability wants to prove it was there.
Third cut: From a pile of parts to 6 reliable floor plans
Previously, the Agent had to assemble a complete page directly from scattered components.
This is much harder than it looks.
Whether a page looks good isn't about whether a single button is pretty, but about the overall structure:
- Is the hero section proportion correct
- Is the content density too crowded
- Does the section rhythm work
- Where are the images placed
- Do all the cards look the same
- Is there a clear call-to-action at the end
So this time, 6 complete Starters were added directly.
| Starter | Suitable for |
|---|---|
| S1 Brand Landing Page | Nav, Hero, brand proposition, product matrix, CTA |
| S2 Product Launch Page | Version nav, highlights, comparison table, Changelog, integration guide |
| S3 Dashboard | Sidebar, KPI cards, tables, statuses, empty states |
| S4 Exhibition Page | Exhibit info, time/location, exhibit grid, booking entry |
| S5 Festival Campaign Page | Countdown, benefit cards, marketing area, rules and action entry |
| S6 Long-form Editorial Page | Title, table of contents, body components, related recommendations |
Each Starter includes real copy structure, image placeholders, responsive breakpoints, and mobile layouts.
Before, it was like handing the Agent a pile of wood, screws, and doorknobs and telling it to build a house.
Now, it's giving it a reliable floor plan first, then swapping materials based on the project.
The difficulty level is completely different.
Fourth cut: When content is insufficient, fill in the structure first
There's a very practical problem:
Empty content can't produce good design.
If a user says "help me build a tea brand official site," and the page only contains:
Brand Title
Product One
Product Two
Learn More
Then no matter how good the CSS is, it can only create a refined empty shell.
So now, content drafts are filled in based on the page type.
For a tea brand, it will first fill in:
- Brand proposition
- Product lines
- Origin
- Craftsmanship
- Purchase entry
For an exhibition page, it will first fill in:
- Exhibition dates
- Location
- Exhibit metadata
- Visitor information
For a Dashboard, it will first fill in:
- Data labels
- Table values
- Statuses
- Empty state copy
But there's a red line that cannot be crossed:
- Cannot fabricate awards, certifications, or rankings
- Cannot fabricate sales figures, user counts, or revenue
- Cannot fabricate expert endorsements or celebrity recommendations
- Cannot fabricate historical stories or brand origins
Missing information? You can fill in the structure.
Missing facts? You can't make things up.
I think this boundary is quite important. The design can be scaffolded first, but AI imagination cannot be used to impersonate brand materials.
Fifth cut: Don't just run static checks, actually open the browser and look
The previous process was more like this:
Generate code
↓
Run static checks
↓
Report no problems
↓
Deliver
The problem is, many visual issues are completely invisible to static checks.
For example:
- Insufficient font color contrast
- Horizontal overflow of tables on mobile
- Hero button's attention stolen by decorations
- Content not lost, but invisible after scrolling
- Looks good on desktop, completely broken on a 375px phone
Now the process has changed to:
Generate code
↓
Static checks
↓
Open in browser, desktop view
↓
Open in browser, 375px mobile view
↓
Review item by item against rules
↓
Fix problems when found
↓
Re-render, check again
When writing the Starters myself this time, I actually caught a few problems:
- The 12px auxiliary text in the Pine-Wheat theme had a contrast ratio of only 3.22:1, later deepened to 4.8:1
- The Dashboard had a horizontal overflow of 359 pixels at 375px
- Although the table could scroll, the person in charge, status, and deadline were all hidden on the right, completely invisible to mobile users
- Finally, the mobile table was changed to row-by-row field cards, making the information directly visible
I quite like this process.
It's not me patting my chest saying "the new version is better," but rather, after the page is actually opened, the problems surface one by one on their own.
Sixth cut: Changing the prompt into a truly executable workflow
The old default prompt was roughly:
Please create a restrained, accessible, culturally contextual Chinese-style page.
Sounds correct.
But after reading it, the Agent still didn't know what to do first.
So now it's changed to 6 steps:
Step 1, scan the project context, determine the page type, target user, and core CTA
Step 2, select the theme, visual intensity, and Starter
Step 3, fill in the content draft based on page type, respecting the factual red lines
Step 4, generate desktop, tablet, and mobile pages
Step 5, use the browser to check the desktop and 375px mobile views
Step 6, after finding problems, modify the code, re-render, and re-check
The delivery standard is also stated more bluntly:
"I've looked at it" does not count as done.
Must fix, re-render, and re-run checks,
until all pass, or clearly state the real blocking reasons.
I also ran a dedicated independent test
To avoid self-congratulation, I launched a brand new Agent instance.
It had no context of Han Design, only a single requirement:
Build a mobile-first landing page for a young tea brand, style should be quiet,
include product cards, an origin story, and a main CTA, you decide the rest of the design.
It ended up making these judgments on its own:
- Selected Brand Landing Page S1
- Selected the Pine-Wheat theme
- Selected visual intensity level 2
- Filled in 3 product cards, origin story, brewing method, price, and CTA
The entry point was basically working.
But it also exposed a problem.
During the browser check, it found a contrast issue and a 20px overflow, but stopped after reporting the problem, without completing the fix action.
This pitfall is very typical.
The documentation says "modify at least one round," which a human understands, but an Agent might interpret "found a problem" as "completed the review."
So I changed the rule to a harder statement:
Finding a problem does not equal completion. You must modify the code, re-render, and re-check until all pass, or clearly list real blockers like permissions, assets, or information.
Now, checksPassed has also been added to the evaluation metrics.
You can't just say you've looked; you have to actually finish fixing.
The judging criteria have already changed
Before, I would focus on:
| What I focused on before | What I care more about now |
|---|---|
| How many theme sets | Can someone who doesn't know themes say "make it look better" and be understood |
| How many component types | Can the Agent make reasonable judgments on its own |
| Can it make a Chinese style | Can it deliver a complete page |
| Is there a static check | Can it see its own problems and finish fixing them |
Many products go through this inflection point.
At the beginning, everyone crazily adds capabilities because they are easy to showcase and promote.
Only later do they realize that users don't care how many capabilities you have; they only care whether the thing they want to do can be done with less mental effort.
The same goes for Han Design.
A truly useful Skill isn't just about stuffing more design knowledge into the Agent's head; more importantly, it's about helping users digest choices:
- When to ask
- When self-judgment is enough
- When restraint is necessary
- When to go heavy
- When finding a problem means you must go back and redo it
These invisible decision-making logics are the real product value within a Skill.
It's not perfect yet.
There's still a long way to go before it's a mature design Agent.
But at least now, after the user gets in the car, they don't need to learn how to adjust the suspension first.
They say where to go.
Han is responsible for driving.
The project code, 6 Starters, visual review rules, and example sites have all been released with the version.
Project address:
https://github.com/you-want/han-design
If you are also working on AI Agents, design systems, or front-end engineering, feel free to chat in the comments: what type of decision do you most want an Agent to digest for you right now?
If you like this kind of sharing, feel free to like, bookmark, and comment, and you can also give the project a Star.