Designing UI/UX
Designs interfaces that are justified by product purpose and user tasks, not by default AI aesthetic habits. Treats "looks modern" as insufficient; requires "fits this product, for this reason" at every major decision.
Before proposing any layout, color, or component, answer four questions:
- What is this screen for? (primary user task, not generic description)
- What already exists? (codebase conventions, design tokens, installed libraries, brand assets)
- What does the user need to notice first, second, and last? (information hierarchy)
- What would make this look like every other AI-generated app? (then deliberately avoid it unless it's actually correct here)
Only after these are answered, select layout, typography, color, and components — and be able to state why each choice serves the task.
If the answer to "why this pattern?" is "it's common" or "it looks clean," stop and reconsider.
Adapt depth to task size. Trivial tweaks (spacing, one color) need just steps 1–2. New screens/redesigns need the full checklist.
Progress:
- [ ] Understand product, users, primary task, and role of this screen
- [ ] Inspect existing code, components, tokens, brand assets, reference designs
- [ ] Separate observed usability problems from personal taste
- [ ] Decide information hierarchy for this screen
- [ ] Choose layout/composition and justify it against the primary task
- [ ] Choose typography system (or reuse existing) and justify it
- [ ] Choose color/spacing/components (reuse tokens where possible)
- [ ] Decide UI library approach (reuse/extend existing vs. justified new choice)
- [ ] Define key states: empty, loading, error, success, disabled
- [ ] Define responsive behavior across relevant viewports
- [ ] Define accessibility requirements that matter here (focus, contrast, semantics)
- [ ] Check result against the generic-AI-pattern checklist
- [ ] Produce implementation-ready spec; flag assumptions and open questions
Step detail
1. Understand the product. Identify purpose, target users, primary tasks, content type, and what outcome a user is trying to achieve on this specific screen. A settings page, a checkout flow, and a data-dense admin table are not interchangeable problems.
2. Inspect before creating. Look at existing screens, component library, design tokens, CSS/theme files, package.json for UI dependencies. If this is an existing product, assume current conventions are intentional until proven otherwise — do not redesign working interfaces without a stated reason.
3. Separate problems from preference. "This button is hard to find during checkout" is an observed usability problem. "I'd prefer a different shade of blue" is a preference. Only override existing design for the former, or when explicitly requested.
4. Information hierarchy first, visuals second. List what matters most on this screen before deciding how anything looks. Primary action, primary content, secondary metadata, rare/destructive actions — rank them before styling them.
5. Layout. Choose structure based on content type and task, not a template. A dashboard full of live metrics needs different density and grouping than a long-form reading view or a single-task wizard. State explicitly what the layout is optimizing for.
6. Typography. Define/reuse a type scale with clear roles (display, heading, body, label, caption, code). Choose typefaces for character and readability, not to "look premium." Reuse existing typography unless there's a reason to change it.
7. Color, spacing, components. Reuse existing tokens first. Only define new ones if genuinely missing. Colors carry meaning (state, hierarchy, brand) — don't pick arbitrary hex values.
8. UI library decision. Check what's already installed and used. Only evaluate alternatives if there's a real decision (new project, genuine gap, explicit request). Never install a library just because it's popular or familiar. When using shadcn/ui, Radix, MUI, Mantine, Bootstrap, etc., treat defaults as a starting primitive, not a finished design — adjust density, variants, and composition to the product.
9. States and edge cases. Identify which states actually matter here (not every component needs every state). Consider realistic content: long names, zero items, overflowing tables, slow networks.
10. Responsive and accessibility. Define behavior at relevant breakpoints and the accessibility considerations that matter for this specific interface (contrast, focus order, keyboard access, screen-reader labels) — don't pad with boilerplate that isn't relevant.
11. Self-check against generic patterns. Run the checklist below before finalizing.
12. Deliverable. Produce only what's needed: rationale, hierarchy, layout spec, typography/spacing rules, component requirements, states, responsive rules, accessibility notes, open questions. Flag anything unverified (e.g., "I could not inspect the running app; this assumes the breakpoint behavior is standard").
Before finalizing a design, check whether any of these are present without justification:
- Every section is a card in a uniform grid, regardless of content relationship
- Gradients, glassmorphism, glow, or blur used decoratively rather than functionally
- A centered hero with oversized heading on a non-marketing screen
- Pill-shaped buttons/inputs everywhere by default rather than by system choice
- All elements have equal visual weight — no clear primary action
- Decorative icons/illustrations that don't aid comprehension or task completion
- A layout that would look identical if the product were swapped for an unrelated one
- Arbitrary spacing/colors not tied to any system or token
- shadcn/ui (or similar) demo page reproduced with no adaptation to the product
If a flagged pattern is present, state explicitly why it's the right choice here — or remove it.
Example 1: Input: "Add a dashboard to our B2B inventory app showing stock levels." Output: Rejects a generic card-grid dashboard. Instead: identifies primary task (spot items needing reorder fast), proposes a dense sortable table as the primary view with inline status indicators (color + icon for stock state), a slim summary strip above (total SKUs, low-stock count, out-of-stock count) instead of KPI cards, and a secondary filter panel. Justification: inventory managers scan many rows quickly; a card grid would force excessive scrolling and hide comparative data. Reuses existing table component and color tokens from the codebase instead of introducing new ones.
Example 2: Input: "Build a landing page for a new meditation app." Output: Rejects the default centered-hero-plus-feature-cards template. Proposes a calmer, asymmetric layout with generous whitespace, a single focal illustration or soft color field (justified: product is about calm, not feature density), restrained type scale with a warm serif for headlines and a neutral sans for body, muted low-saturation palette, and one clear primary CTA. States explicitly why feature-grid marketing patterns were avoided: they read as generic SaaS, which contradicts a calm/mindful brand.
Example 3: Input: "Our settings page looks fine, just add a new 'notifications' tab." Output: Does not redesign the page. Inspects existing tab component and spacing conventions, adds the new tab following the same pattern, reuses existing form/field components and spacing tokens, matches existing label/help-text typography roles. No new design system introduced for one tab.
- State the "why" for every non-trivial visual decision in terms of the product/task, not aesthetics alone.
- Reuse before creating: tokens, components, typography, libraries.
- Preserve existing conventions in established products unless there's a stated reason to change them.
- Let restraint be a valid outcome — a plain, highly usable screen can be the correct deliverable.
- Call out explicitly which generic patterns were considered and why they were kept or rejected.
- Be concrete in handoff specs: exact hierarchy, states, spacing/type rules, not vague adjectives like "clean" or "modern."
- Only claim documentation was reviewed, or an environment was rendered/inspected, if that actually happened.
- Defaulting to card grids, hero sections, or dashboards because they're familiar, not because they fit the content.
- Adding visual effects (gradients, glow, blur, animation) with no functional purpose.
- Introducing a new UI library or token set without checking what already exists.
- Redesigning a working screen because of personal taste rather than an identified problem.
- Treating a component library's demo/default styling as a finished, product-specific design.
- Giving every element equal emphasis, leaving no clear primary action.
- Writing vague design guidance ("make it feel premium") instead of concrete, implementable specs.
- Skipping states (empty/error/loading) and realistic content variation, then being surprised when real data breaks the layout.
- Claiming accessibility compliance or usability testing that wasn't actually performed.