# Reference: User-Centered Design Frameworks (Travis Lowdermilk)

Conceptual reference document. Consult when you need details on a specific framework.

---

## What is UCD — Definition and Scope

User-Centered Design (UCD) is the process by which designers focus on users and their needs in every phase of the design process. UCD requires that designers not only analyze and predict how users will likely use the product, but also test the validity of their assumptions regarding user behavior in real-world tests.

### The Discipline Continuum

```
Usability (Human Factors) → HCI → UCD → UX → Product
```

| Discipline | Focus |
|-----------|-------|
| **Usability** | Ease of use of specific interfaces |
| **Human-Computer Interaction (HCI)** | Design, evaluation, and implementation of interactive systems |
| **User-Centered Design (UCD)** | Design process focused on user needs |
| **User Experience (UX)** | All aspects of interaction with company, services, and products |

### What UCD is NOT

| Misconception | Reality |
|---------------|---------|
| UCD is usability | Usability is only one component of UCD |
| UCD is subjective | UCD is based on data, testing, and evidence |
| UCD is only visual design | UCD involves research, architecture, interaction, and validation |
| UCD is a waste of time/money | Investing in UCD reduces rework and increases satisfaction |
| UCD is a bug report | UCD prevents problems, not just documents them |
| UCD is a distraction | UCD is an integral part of the development process |

---

## Working with Users

### Access to Users

Even without direct access, use:
- Personas based on available data
- Competitor product analysis
- Testing with colleagues who represent the profile
- Analytics and support data

### When to Listen and When Not to Listen

| Listen | Don't Listen |
|--------|--------------|
| Problems they face | Solutions they propose |
| Workflows they follow | Specific features they request |
| Frustrations and confusions | Opinions about aesthetics |
| Context of use | Predictions of future behavior |

> "If I had asked people what they wanted, they would have said faster horses." — Ford

### Difficult User Types

| Type | Behavior | How to Handle |
|------|----------|---------------|
| **The Exaggerator** | Exaggerates problems or praise | Ask for specific examples, observe real behavior |
| **The Control Freak** | Wants to dictate the design | Redirect to their pains, not solutions |
| **The Devil's Advocate** | Questions everything negatively | Extract legitimate concerns, ignore the tone |

---

## UCD Planning

### Mission Definition

Every team needs a clear mission that:
- Defines the product's purpose
- Aligns the entire team
- Serves as a filter for decisions

### Planning Process

```
Mission → Project Definition → User Requirements → Functional Requirements → Models/Flows → Prototypes → Review
```

| Stage | Deliverable |
|-------|-------------|
| Project definition | Scope, constraints, timeline |
| User requirements | Validated needs list |
| Functional requirements | Derived technical specifications |
| Data/flow models | Diagrams of how data flows |
| Prototypes | Testable representations |
| Review | Validation with stakeholders |

---

## Personas and Scenarios

### Creating Personas

A persona is a fictional representation of a group of real users.

**Persona Structure:**

```markdown
## [Persona Name]

**Profile:** [Age, profession, technical skill]
**Context:** [Usage environment, devices, frequency]
**Primary goal:** [What they want to accomplish]
**Primary frustration:** [Biggest current pain]
**Quote:** "[A sentence that represents their mindset]"

### Behaviors
- [Relevant behavior 1]
- [Relevant behavior 2]

### Needs
- [Functional need]
- [Emotional need]
- [Social need]
```

### Creating Scenarios

Scenarios describe how the persona uses the product in real context.

**Scenario Structure:**

```markdown
## Scenario: [Descriptive name]

**Persona:** [Which persona]
**Trigger:** [What initiates the interaction]
**Context:** [Where, when, how]
**Flow:**
1. [Step 1]
2. [Step 2]
3. [Step 3]

**Desired outcome:** [What the persona expects to achieve]
**Potential friction:** [Where things could go wrong]
```

---

## Design Principles

### Proximity Principle (Gestalt)

Elements that are close together are perceived as related.

**Practical application:**
- Group related items visually
- Use white space to separate distinct groups
- Labels should be closer to the field they label than to other elements
- Related actions should be close together (save/cancel together)

### Visibility, Visual Feedback, and Prominence

| Attribute | Function | Example |
|-----------|----------|---------|
| **Typography** | Typographic hierarchy | Headings > subheadings > body |
| **Opacity** | Indicate availability | Disabled = 40% opacity |
| **Prominence** | Draw attention | Primary button > secondary |
| **Status** | Communicate state | Green = success, red = error |
| **Color/Contrast** | Differentiate and highlight | CTA in contrasting color |

**Visual Feedback — Required states:**
- Default (rest)
- Hover (cursor over)
- Active/Pressed (clicked)
- Focus (keyboard navigation)
- Disabled (unavailable)
- Loading (processing)
- Error (something went wrong)
- Success (action completed)

### Visual Hierarchy

Provide visual indicators that help users perceive how the application is organized.

**Hierarchy tools:**
- Size (larger = more important)
- Color and contrast (more saturated = more important)
- Position (top-left = seen first — F-pattern)
- White space (more space around = more emphasis)
- Typography (weight, size, style)

### Mental Models and Metaphors

Mental model = internal representation of how something works, based on prior experience.

**Rule:** Use metaphors the user already knows from other products or the real world.

| Metaphor | Origin | Digital Use |
|----------|--------|-------------|
| Trash/Recycle Bin | Office | Delete with recovery option |
| Folder | Physical archive | Organize files |
| Cart | Supermarket | E-commerce |
| Dashboard | Car panel | Metrics overview |

**Caution:** Metaphors can limit innovation. Know when to deliberately break the metaphor.

### Progressive Disclosure

Hide options that are not possible or necessary at the current moment to reduce cognitive load.

**Practical application:**
- Show only fields relevant to the current context
- Use wizards/steppers for complex processes
- Place advanced options in secondary menus
- Progressive onboarding: reveal features as the user advances

**When to use:**

| Situation | Apply Progressive Disclosure |
|-----------|------------------------------|
| Form with 20+ fields | Split into steps |
| Complex settings | Basic visible, advanced hidden |
| Onboarding | Feature by feature, not all at once |
| Dashboard | Summary first, drill-down on demand |

### Consistency

Be consistent with existing patterns so the user doesn't need to relearn.

**4 Levels of Consistency:**

| Level | Description | Example |
|-------|-------------|---------|
| **Internal** | Within the product itself | Same button = same style |
| **External** | With other ecosystem products | Google Suite uses same toolbar |
| **Platform** | With the platform (iOS, Android, Web) | Follow OS guidelines |
| **Domain** | With industry conventions | E-commerce: cart in top-right corner |

### Affordance and Constraints

**Affordance:** Make it easy to do what is right.
**Constraint:** Make it hard to do what is wrong.

| Principle | Example |
|-----------|---------|
| Affordance | Button with clickable appearance (elevation, color) |
| Constraint | Date field that only accepts valid format |
| Affordance | Underlined and colored link |
| Constraint | "Delete" button that requires confirmation |

### Confirmation

Prevent undesired actions by requesting verification from the user.

**When to use confirmation:**
- Irreversible actions (delete, send)
- High-impact actions (payment, publishing)
- Actions that affect other users

**When NOT to use:**
- Trivial and reversible actions (mark as read)
- Normal navigation
- Frequent actions (would be annoying)

---

## UX Laws

### Hick's Law

```
RT = a + b · Log₂(N)
```

Where:
- RT = Reaction Time
- N = Number of options
- a, b = constants

**Meaning:** The more options presented simultaneously, the longer the user takes to decide.

**Practical application:**
- Menus with maximum 7±2 items per group
- Categorize options into logical groups
- Offer search when there are many options
- Use smart defaults to reduce decisions
- Landing pages: 1 primary CTA, not 5

### Fitt's Law

```
T = a + b · Log₂(D/W + 1)
```

Where:
- T = Time to reach the target
- D = Distance to the target
- W = Width (size) of the target

**Meaning:** Larger and closer targets are easier to reach.

**Practical application:**
- Primary action buttons should be large
- Destructive actions should be small and distant
- Clickable areas larger than visible text (generous padding)
- Mobile: minimum targets of 44x44px (Apple) or 48x48dp (Android)
- Menus: most-used items most accessible (proximity)
- Screen corners and edges are "infinite targets" (mouse stops at edge)

---

## Feedback and Research Methods

### How Many Users Are Needed?

| Method | Minimum Recommended |
|--------|---------------------|
| Usability study | 5 users (finds ~85% of problems) |
| Exploratory interview | 8-12 users |
| Quantitative survey | 30+ responses |
| A/B test | Depends on traffic volume |

### Collection Methods

| Method | When to Use | Deliverable |
|--------|-------------|-------------|
| **Survey** | Validate hypotheses quantitatively | Statistical data |
| **Interview** | Explore motivations and context | Qualitative insights |
| **Task Analysis** | Map the user's real flow | Task diagram |
| **Heuristic Evaluation** | Find problems without users | Violations list |
| **Storyboard** | Communicate scenarios visually | Visual narrative |
| **Prototype** | Test interactions before building | Testable artifact |
| **A/B Test** | Compare alternatives with data | Winning variant |

### Conducting Interviews

**Rules:**
1. Open-ended questions (avoid yes/no)
2. Don't lead responses
3. Observe behavior, not just words
4. Record (with permission)
5. Ask "why?" at least 3 times

### Heuristic Evaluation — Nielsen's 10 Heuristics

| # | Heuristic | Verification |
|---|-----------|--------------|
| 1 | Visibility of system status | Does the user know what's happening? |
| 2 | Match between system and real world | Is the language familiar? |
| 3 | User control and freedom | Can they undo/go back? |
| 4 | Consistency and standards | Do similar things look similar? |
| 5 | Error prevention | Does the design prevent errors? |
| 6 | Recognition rather than recall | Is information visible when needed? |
| 7 | Flexibility and efficiency of use | Shortcuts for experts? |
| 8 | Aesthetic and minimalist design | Only what's necessary on screen? |
| 9 | Help users recognize, diagnose, and recover from errors | Do error messages help solve? |
| 10 | Help and documentation | Is accessible help available? |

**Severity classification:**
- 0: Not a usability problem
- 1: Cosmetic — fix when possible
- 2: Minor — low priority
- 3: Major — high priority
- 4: Catastrophic — fix before launch

---

## Usability Studies

### What They Are

Controlled observation of real users performing real tasks on the product (or prototype).

### Test Plan — Structure

```markdown
## 1. Introduction
- Study objective
- What will be tested
- Methodology

## 2. Participant Guarantees
- "We're not testing you, we're testing the product"
- "You can stop at any time"
- "There are no right or wrong answers"

## 3. Guidelines
- Think-aloud protocol
- Don't help the participant
- Observe, annotate, don't correct

## 4. Tasks
- Task 1: [Description + success criteria]
- Task 2: [Description + success criteria]

## 5. Conclusion
- Final open-ended questions
- Thank you
```

### What You'll Need

| Item | Function |
|------|----------|
| Stopwatch | Measure time per task |
| Notepad | Record observations |
| Controlled environment | Minimize distractions |
| Spreadsheet/database | Organize results |
| Camera/recorder | Record session (with permission) |

### Usability Metrics

| Metric | What It Measures |
|--------|-----------------|
| Success rate | % of tasks completed |
| Time on task | Efficiency |
| Error rate | Frequency of mistakes |
| Satisfaction (SUS) | Subjective perception (scale 1-100) |
| Abandonment | Where they give up |

---

## Creativity and UX

### Experience Goals

Define experience goals before designing:
- How should the user **feel** while using it?
- What **adjectives** describe the ideal experience?
- What **emotion** upon completing the task?

### Creative Process

```
Constraints → Exploration → Creative borrowing → Questioning → Solution
```

1. **Exercise constraints** — Limits breed creativity (time, technology, scope)
2. **Build a narrative** — Tell the story of the user using the product
3. **Grab a pencil** — Sketch before using digital tools
4. **Steal (I mean, borrow) from others** — Study patterns that work in other products
5. **Question** — Ask "what if...?" for every design decision

---

## Iterative Principle — You Never Finish

### Rules of the Iterative Cycle

1. **It's impossible to get it right the first time.** Every design is a hypothesis until tested.
2. **Be prepared to restart.** Attachment to a design prevents evolution.
3. **Test early, test often.** The sooner you find problems, the cheaper to fix them.

### Improvement Cycle

```
DESIGN → PROTOTYPE → TEST → LEARN → ITERATE
```

| Stage | Activity | Suggested duration |
|-------|----------|--------------------|
| Design | Apply principles and create solution | 1-2 days |
| Prototype | Materialize in testable format | 1-2 days |
| Test | Validate with 5 users | 1-3 days |
| Learn | Synthesize findings | 1 day |
| Iterate | Refine based on data | 1-2 days |

---

## Quick Glossary

| Term | Definition |
|------|-----------|
| UCD | Design process focused on user needs and behaviors |
| UX | Total user experience with product, company, and services |
| HCI | Human-Computer Interaction — design and evaluation of interactive systems |
| Usability | Ease of use and learnability of an interface |
| Affordance | Property that indicates how an object can be used |
| Mental Model | Internal representation of how something works |
| Persona | Fictional representation of a group of real users |
| Scenario | Description of how a persona uses the product in context |
| Progressive Disclosure | Showing information gradually as needed |
| Hick's Law | More options = more time to decide |
| Fitt's Law | Larger and closer targets are easier to reach |
| Think-aloud | Protocol where participant verbalizes thoughts during test |
| SUS | System Usability Scale — standardized usability questionnaire |
| Heuristic Evaluation | Interface inspection based on established principles |