/super-ui-ux-design

name: super-ui-ux-design
description: Complete UI/UX design capability — a wiki-style knowledge map of design theory (UX laws, Nielsen heuristics, usability, visual hierarchy, typography, contrast/WCAG, design systems, aesthetics-vs-conversion) fused with a hands-on execution playbook for building distinctive, production-grade frontend interfaces. Use when designing or building any UI (websites, landing pages, dashboards, components, apps), reviewing or critiquing UI/UX, diagnosing why a design doesn't convert, or styling/beautifying web interfaces. Grounds every visual decision in UX principles and avoids generic AI aesthetics.
license: Complete terms in LICENSE.txt
original_source: Execution playbook modified from anthropics/claude-code-skills (frontend-design), licensed under Apache 2.0

📐 The Full Schemata of UI/UX Design

> A wiki-style knowledge map. Each section is a node. Follow the links, build the schema in your head, then go break it against real users. > > **Format notes:** Internal links like [Visual Hierarchy](#-visual-hierarchy) jump between nodes. Mermaid blocks render in Obsidian, GitHub, Notion, and most modern markdown viewers.

---

🗺️ The Master Map

Start here. Everything below hangs off this tree.

mindmap
  root((DESIGN))
    Problem Solving
      Define the problem
      Constraints
      Trade-offs
      Iteration
    UX["UX (Experience)"]
      Research
      Information Architecture
      Interaction Design
      Usability
      Mental Models
      UX Laws & Heuristics
    UI["UI (Interface)"]
      Visual Hierarchy
      Layout & Grids
      Typography
      Color & Contrast
      Components
    Design Systems
      Tokens
      Components
      Patterns
      Documentation
    Business Layer
      Conversion
      Retention
      Trust & Credibility
      Aesthetics vs Performance
    Learning Layer
      Constructivism
      Schemata
      Mental Models
      Jakob's Law

---

🧩 Node 0 — What Is Design?

**Definition:** Design is the intentional shaping of something (a product, a screen, a service, a process) to achieve a purpose under constraints.

The keyword is *intentional*. Decoration happens to look nice. Design exists to *do* something.

Herbert Simon, in *The Sciences of the Artificial*, framed it roughly as: anyone who devises a course of action to change an existing situation into a preferred one is designing. By that definition, a doctor writing a treatment plan is designing. So is an engineer, a teacher, and yes, the person arranging buttons on a checkout page.

**So... is design about problem solving?**

Yes, with one important nuance.

Design *is* problem solving, but it's a specific flavor of it. Most design problems are what theorists call **wicked problems** (Rittel & Webber, 1973):

• There is no single correct answer, only better and worse ones
• The problem definition itself shifts as you work on it
• Every solution creates new constraints
• You can't fully test a solution without shipping it

This is why design is iterative by nature. You don't "solve" a checkout flow the way you solve a math equation. You propose, test, learn, and revise.

flowchart LR
    A[Existing Situation] -->|"Understand the problem"| B[Problem Definition]
    B -->|"Generate options"| C[Proposed Solution]
    C -->|"Test with reality"| D{Did it work?}
    D -->|"No / Partially"| B
    D -->|"Yes"| E[Preferred Situation]
    E -.->|"World changes, new problems"| A

> ⚠️ **The nuance:** "Design = problem solving" is true but incomplete. Design also involves *problem finding* (framing what's actually wrong) and *meaning making* (why should anyone care?). A perfectly solved wrong problem is still a failure.

**See also:** [The Double Diamond](#-node-9--the-design-process), [Wicked problems vs puzzles](#-node-0--what-is-design)

---

🧠 Node 1 — Constructivism & Schemata (Why This Document Is Shaped Like This)

You asked about Constructivism and schemata. Both matter twice here: once for *how you learn design*, and once for *how your users experience your design*.

Constructivism (the learning theory)

**Definition:** Knowledge isn't transferred into your head like a file copy. You *construct* it by connecting new information to what you already know. Key figures: **Jean Piaget** (cognitive constructivism), **Lev Vygotsky** (social constructivism).

Piaget's two core mechanisms:

| Mechanism | What happens | Design-learning example | |---|---|---| | **Assimilation** | New info fits into an existing schema | "Oh, a design token is just a variable. I know variables." | | **Accommodation** | New info breaks the schema, forcing you to rebuild it | "Wait, beautiful design *lowered* conversion? My schema 'pretty = good' is wrong." |

Schemata (the mental structures)

**Definition:** A **schema** (plural: *schemata*) is an organized mental framework: a cluster of related concepts, expectations, and patterns. The term comes from Piaget and from **Frederic Bartlett's** memory research (1932).

A wiki is basically a schema made visible. Nodes, links, hierarchy. That's why this document is wiki-shaped: the format mirrors the cognitive structure you're trying to build.

The bridge to UX: users have schemata too

Here is the punchline. In UX, a user's schema is called a **mental model**, and it's one of the most powerful forces in interface design.

flowchart TD
    A["Schema Theory<br/>(Piaget, Bartlett)"] --> B["Mental Models<br/>(how users THINK a system works)"]
    B --> C["Jakob's Law<br/>'Users spend most of their time on OTHER sites'"]
    C --> D["Design implication:<br/>Match conventions unless you have<br/>a very good reason not to"]
    B --> E["Norman's Gulf of Execution<br/>(user can't figure out HOW to act)"]
    B --> F["Norman's Gulf of Evaluation<br/>(user can't tell WHAT happened)"]
    E --> G[Confusion, abandonment]
    F --> G

When your interface matches the user's schema, it fee