super-ui-ux-design

# 📐 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.

```mermaid
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.

```mermaid
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.

```mermaid
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 feels "intuitive." When it violates the schema, the user must *accommodate* (rebuild their mental model), and accommodation costs effort. Users mostly refuse to pay that cost. They just leave.

> 💡 **Rule of thumb:** "Intuitive" is not a property of your design. It's a property of the *match between your design and the user's existing schemata.*

**See also:** [UX Laws](#-node-4--the-laws--heuristics-of-ux), [Why ugly sites convert](#-node-8--aesthetics-vs-conversion-the-paradox)

---

## 🔀 Node 2 — UI vs UX (They Are Not the Same Thing)

**UX (User Experience):** The *entire* journey: how someone discovers, learns, uses, struggles with, and feels about a product. UX includes things you never see on screen: loading speed, support emails, the pricing page, the cancellation flow.

**UI (User Interface