SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsdesign-gui-guide

design-gui-guide

Design & creation

View repository

Updated 10-15 21:02

About this skill

design-gui-guide — 10 GUI elements usability guidelines SSOT

Purpose and rationale

Almost every screen is assembled from 10 standard GUI elements. Each element is a convention that has passed through a 40+ year Darwinian filter — Jakob's Law(users expect yours to work the way they've seen it work on other sites) makes the familiar version always better. Don't spend your innovation budget creating new checkbox seeds; spend it on content and services.

Source: UX Tigers, Jakob Nielsen, "10 GUI Design Elements Build Every User Interface" (2026-07-29) — 86 evidence-based guidelines + bonus 2. This skill distills them into practical Korean-language guidance and maps them to 63 shadcn components. It restates the original guidelines (usability principles and methods) rather than copying them.

Three overarching propositions (all 86 guidelines sit beneath these):

  1. Don't make them remember — maintain the recognition advantage
  2. Don't make them guess — don't undermine visual grammar and conventions
  3. Don't make them wait — strict budget for response and completion

Consumption points

Consumers How to use
design-prompt-builder Pattern 3 When generating a design system, design each component to match its corresponding element guidelines
design-prompt-builder Pattern 6 When auditing usability, evaluate with Nielsen's 10 heuristics + these 86 guidelines (at the component level)
design-system-prep DESIGN.md Component recipes quality criteria
design-slop-check Complement to copy-focused review — component behavior and layout quality are covered by this skill

1. Buttons — pressing does something

shadcn: Button · Button Group

Buttons are the only element that changes the world (links and tabs move you, menus and dialogs merely rearrange the conversation). That's why their labeling rules are the strictest — a wrong link costs one Back press, but a wrong button loses a customer.

  1. Make it look pressable. Closed shape + background contrast + state change on press. If flat design strips away borders/shadows, users are left guessing "which text is a command."
  2. Every button labeled with a verb that indicates the result. "Save Invoice," not "OK." If the effect doesn't fit in 2–4 words, it's not a labeling problem but a deeper problem.
  3. Exactly one visually dominant primary action per screen. If two primary actions compete, there is no primary action.
  4. Follow Fitts's law. Frequently used actions should be large and close. Touch targets at least 1×1 cm.
  5. Acknowledge every press within 0.1 seconds. The threshold for feeling like it responded.
  6. Disabled buttons are a faded version of the primary color + explain why they're disabled/how to enable them. Don't hide them.
  7. Buttons for actions, links for navigation. Don't mix the two visual languages.
  8. Put buttons where the task ends. After the fields/content, at the natural end of the reading flow.

Split button: Primary action (large area, 1 click) + variations (small area, arrow/three dots). Only when one command overwhelmingly dominates by frequency. A visible separator between the two areas is required. If no single default can be determined, use an ordinary menu button.

2. Input Fields & Forms — Where Money Changes Hands

shadcn: Input · Input Group · Input OTP · Textarea · Label · Field · Select · Native Select · Combobox · Date Picker · Checkbox · Radio Group · Switch · Toggle · Toggle Group · Slider

Forms involve checkout, sign-up, and lead generation — usability translates directly into revenue (UX = profits). The strongest guideline is subtraction: every unnecessary field lowers the completion rate. Optional fields are also assigned a field tax(consuming attention) — even if optional in the DB, they aren't optional to the user's attention.

  1. Delete any field that isn't strictly necessary. Every field you keep must be weighed against the completion rate/revenue you lose.
  2. A permanent label outside the field for every field. Placeholder is a hint, not a label — it disappears as soon as typing starts.
  3. Accept flexible input formats. Don't fuss over whether phone numbers have hyphens; normalize in code. Take back the work computers have dumped on people.
  4. Put errors next to the relevant field, and preserve what the user entered. A form that wipes input on error won't be used twice.
  5. Use dedicated controls suited to the task. A Date Picker for dates, a trash can icon for removing items from the cart ("remove" in the user's mind, not "set to 0").
  6. Single column + group related fields. Multiple columns make the reading order ambiguous and cause fields to be skipped.
  7. The submit button is labeled with the result. Not "Submit" but "Place Order".
  8. Don't validate while the user is typing. "Invalid email" while typing is a premature judgment — validate when the field loses focus.

burden-printing paradox: stating the burden up front, like "3 questions, 40 seconds," turns fear into a transaction. But no lying — if you say 1 minute and it takes 5, trust is gone.

3. Menus — Visualization of Information Architecture

shadcn: Dropdown Menu · Navigation Menu · Menubar · Context Menu · Breadcrumb

Menus save space + have the advantage of recognition (choosing from visible options). But there's a trap called completeness claim— users read the menu as "the entire list of what the kitchen can make." What's under a label that won't open doesn't exist to the user.

  1. Categories in the user's vocabulary — verified with card sorting and tree testing. An org chart is not an information architecture.
  2. Click-to-open rather than hover. If hover is required, add a short delay + a diagonal tolerance path.
  3. Limit cascades to 2 levels. If it's deeper, reorganize the categories rather than going deeper.
  4. On desktop, expose top-level navigation. The hamburger is for small screens only — navigation that isn't visible isn't being used.
  5. Show current location. A map without the "you are here" dot.
  6. Sort by importance and task frequency. Alphabetical order only when the exact name is known.
  7. Promote the 2–3 most frequently used commands out of the menu into visible buttons. The menu is for the long tail.

4. Links — the atom of the web

shadcn: (Typography·Breadcrumb context)

A link makes two promises — a visual promise that it's clickable (color + underline), and a promise about what's on the other side (information scent). "Click here"/"Learn more" have zero scent. Scanning users read mainly the link's first 11 characters.

  1. Links should look like links. Links in body text get color + underline — color alone fails for color blindness and low-end screens.
  2. Link styling is for links only. Underlining anything else trains the user that furniture is clickable.
  3. Put the informative words first. The first 11 characters do most of the work.
  4. Text that lets users predict the destination and makes sense without context. Screen readers pull out a list of links — 14 instances of "click here" are useless.
  5. Distinguish visited and unvisited links (link-heavy designs).
  6. Don't cross-dress links as buttons or buttons as links. Visual grammar carries meaning.
  7. Open in the same tab by default. Mark exceptions on the link (e.g., "(PDF)").

Core boundary: links go, buttons do. Blur the two languages and a small tax is added to every click.

5. Dialog Boxes — interruption must prove its worth

shadcn: Dialog · Alert Dialog · Sheet · Drawer

A modal blocks all work and taxes the user's working memory. So an interruption must earn its place — a blocking decision, an irreversible consequence, or input without which you can't proceed.

  1. Modal only for genuine blocking decisions. If work can reasonably continue, the interruption isn't justified.
  2. Buttons label the outcome. "Delete 3 Files" / "Keep Files" answers the question — "OK"/"Cancel" is ambiguous.
  3. Default to the safe choice, and Esc always cancels. One wrong Enter must not destroy something.
  4. One question per dialog, 1–2 sentences. Situation, consequence, choice — it's not a reading assignment.
  5. For reversible actions, use undo instead of confirmation. Undo protects users without training them to click through warnings.
  6. Modeless if work can continue. The problem find-and-replace solved in the 1980s.
  7. Don't greet first-time visitors with an overlay. Asking for an email before delivering value is asking for a date before saying hello.
  8. No dialog on top of a dialog. The interruption queue is upstream design that has already failed.

Dark pattern warning: The overlay measures the 3% conversion but not the 97% resentment — "resentment has no event handler." Measure the cost of forced conversion too.

6. Alerts · Notifications · Errors — the system's turn to speak

shadcn: Alert · Toast · Message · Message Scroller

Error message guidelines predate the GUI: in plain language, what went wrong, exactly where, and how to recover — never blame the user.

  1. Plain language, no raw error codes only. "Error 0x80004005" was written by the developer for the developer.
  2. Exactly what and where went wrong. "Something went wrong" helps no one.
  3. Offer a path forward. A good error message is a one-sentence recovery plan.
  4. Never blame the user. "illegal", "fatal", "invalid user" — never use expressions that pin the blame on the person who trusted you.
  5. Match severity ↔ format. Toast is FYI, an error stays inline until it is fixed, and a modal is for disasters only.
  6. Signal with icon + color + text (redundant coding). About 1 in 12 men is red-green colorblind — "marked in red" alone means nothing.
  7. Notification rationing. Default to fewer, let the user adjust the volume — every interruption is a withdrawal from a limited trust account.

Toast trap: Self-dismissing is good for confirmations ("message sent"), but if used for an error the user must act on, it vanishes after 4 seconds and gets rediscovered the hard way.

7. Icons — small pictures, big misunderstandings

shadcn: Lucide icons throughout

The chronic weakness of icons — users frequently guess unfamiliar pictures wrong. Only a handful approach universal recognition (magnifying glass, house, gear, trash can). The rest are hypotheses awaiting testing.

  1. Pair icons with text labels. If space truly won't allow it, provide a tooltip and admit you traded learnability for pixels.
  2. If a standard metaphor exists, use it. A new symbol for search or settings spends user attention and buys nothing.
  3. Test recognition before trusting a metaphor. Show the icon alone to 5 people and ask what it means — hesitation is the answer.
  4. Consistent style + distinguishable silhouettes. They should look like siblings yet be distinguishable at a glance.
  5. Don't redesign learned icons for fashion. Redesigning a familiar symbol taxes every existing user.
  6. A favicon that survives at 16×16. Simplify the logo into one strong shape + brand color — fine detail turns to mud.
  7. Icon-only buttons only for the universal few. A magnifying glass can stand alone, but your "insights" glyph cannot.

A text label is the cheapest usability insurance you can buy. A labeled icon is a lessonand an unlabeled icon is a test.

8. Checkboxes · Radio Buttons · Toggles — Squares mean "anything," circles mean "only one"

shadcn: Checkbox · Radio Group · Switch · Toggle · Toggle Group

Shape teaches the selection model — squares mean multiple, circles mean exactly one. A grammar users have learned through decades of exposure. When a designer swaps the two, the screen lies about its own rules.

  1. Checkboxes for independent options, radios for mutually exclusive ones. Shape is a contract — honor it.
  2. Lay options out vertically. Horizontal layouts make it ambiguous which label belongs to which control.
  3. Labels are clickable. A 14px circle is a cruel target — the label adds area for free.
  4. For radio groups, a sensible default plus (if abstention is valid) a "None" option. Once pressed, it cannot be undone.
  5. Phrase options positively. "Receive the newsletter" is better than "Don't exclude me from communications."
  6. Toggles only when changes apply immediately. If a submit step follows, it's a checkbox — a toggle above a Save button is a contradiction.
  7. Yes/no is one checkbox, not two radios. One control, one decision, half the reading.
  8. For 2–4 options, visible radios instead of a dropdown. Seeing them all at once beats a click-and-remember test.

9. Tabs — one row, same type, same level

shadcn: Tabs

The physical metaphor sets the rules — the selected tab should appear attached to its panel, unselected ones clickable but subordinate. Labels are short and one row is the limit.

  1. Tabs are always one row. If they don't fit, you have too many tabs or too-long labels — fix the tab count/labels.
  2. Labels are plain 1–2 words. Tabs are titles of parallel content, not sentences.
  3. Visually connect the selected tab to its panel + distinguish it from its neighbors. Three distinct appearances: current/hover/unselected.
  4. Use tabs only for content of the same type and level. For a sequential process, use a wizard with a step indicator.
  5. Default to the tab the majority needs first. The first impression of the tab area is the panel you left open.
  6. Don't put content that must be compared behind tabs. Flipping back and forth is a memory test — a comparison table is the answer.
  7. Where the platform allows, give each tab a URL. Users bookmark, share, and press Back — only linkable places fully exist.

10. Search — users state their goal in their own words

shadcn: Command

Search is the surviving command line — when the possibility space outgrows the menu, letters win. The AI prompt input field is the reincarnation of the same fossil. Search logs are the cheapest user research you can get다.

  1. On content-heavy sites, an open search box at the top of every page. If an icon hides the box, that's one more click + a visibility minus.
  2. Box at least 27 characters wide. The whole query must be visible to be editable — scrolling inside the field is miserable.
  3. Submit via magnifier icon + Enter works. Both are conventions users bring with them.
  4. Tolerate typos, plurals, synonyms. The engine's job is to find what the user means, not to 친 grade what they typed.
  5. Keep the query in the box on the results page. Reformulation is half of search behavior — make editing a keystroke, not a restart.
  6. Design the results page as a full UI. Scannable titles, snippets that reveal why it matched, filters once the collection grows.
  7. Index everything users consider part of the site. Silently skipping the support section mass-produces false "no results."
  8. Mine search logs once a month. High-volume, thin-result queries are usability bugs users filed themselves.

Bonus A. Windows & Scrolling — Inherit, Don't Pop

shadcn: Sidebar · Scroll Area · Resizable (context)

Today's designers inherit windows (browser tabs) rather than design them. The remaining design question is "when to pop a new window" — answer: rarely. Surprise windows break the web's reverse gear (Back).

  1. By default, open in the same window/tab. Users who want a new tab open it themselves — don't decide for them.
  2. Don't hijack scroll speed or direction. Scroll is muscle memory — overwrite it and the whole page feels possessed.
  3. Keep scrollbars visible in every scrollable area. Hiding the map doesn't shorten the territory.
  4. Infinite scroll only when there's nothing users need below. If the footer matters, use a "Load More" button.
  5. Arrange content by importance. Users scroll, but attention thins with every screen — the top is prime real estate.
  6. Protect the Back button. Breaking it (including unnecessary new windows) breaks navigation's main undo.

Bonus B. Pointers & Cursors — The Hand Above the Screen

shadcn: (cursor/focus indication — indirect)

Pointer shapes are a sign language announcing what a click will do — arrow, hand, grabbing hand, I-beam. Designers rarely draw cursors themselves, but they must respect the signals.

  1. Use the platform-standard cursor; do not restyle it. A custom cursor is novel to designers but a lie detector to users.
  2. Hand cursor only on genuinely clickable elements, I-beam only on editable text. Cursor changes are a promise — false ones erode the real ones.
  3. Show busy for waits of 1 second or more. The cursor's oldest job is being honest about whether the system heard you.
  4. Do not make important information or action paths hover-only. Touch devices have no hover — nor do keyboards.
  5. Show visible focus for keyboard users. The focus outline is the keyboard's cursor — removing it for aesthetics isolates everyone who navigates with Tab.

Frequently confused boundaries — summary table

What you're trying to do 쓸 것 Forbidden
Page navigation Link Dressed up as a button
Immediate execution (state toggle) Switch / Toggle Toggle over a Save button (contradiction)
Finalize by submitting Checkbox + Button Toggle on the same thing
Multiple selection Checkbox Radio
Exactly 1 Radio Checkbox
Blocking decision Modal Dialog Modal where inline would work
FYI confirmation Toast Error (must not disappear)
Information-rich navigation Search / Command Hamburger (desktop)

Source

  • Jakob Nielsen, UX Tigers, "10 GUI Design Elements Build Every User Interface" (2026-07-29) — 86 evidence-based guidelines + bonus (windows/pointers). https://www.uxtigers.com/post/gui-widgets
  • This skill distills and restates the original guidelines (usability principles and methods) as practical Korean-language guidance; it is not a copy of the original. The cited examples (Expedia $12M, Fitts's law, 1 in 12 men with color blindness, 27-character width, first 11 characters, 0.1-second response, etc.) are based in fact.
  • Theoretical roots: Jakob's Law · recognition over recall (Nielsen heuristic 6) · Fitts's law (1954) · perceived affordance (Don Norman) · information scent (Pirolli & Card).

Related skills

Skill When to use
moai-designer:design-prompt-builder Patterns 3 (generate) and 6 (audit) reference these guidelines as a per-component checklist
moai-designer:design-system-prep DESIGN.md Component recipes quality criteria
moai-designer:design-slop-check A complement to copy-focused review — component behavior and layout quality are covered by this skill
moai-designer:design-system-library Pairing of shadcn vanilla component reference markup with these guidelines