141 lines
4.7 KiB
Markdown
141 lines
4.7 KiB
Markdown
|
# Core Framework: Warp-Speed Decisioning
|
||
|
|
|
||
|
|
## The 3 Pillars
|
||
|
|
|
||
|
|
### 1. Scaffolding
|
||
|
|
Rules that automate recurring decisions. Pre-made defaults so you don't re-decide the same things.
|
||
|
|
|
||
|
|
**Components:**
|
||
|
|
- Design psychology reference (laws, principles)
|
||
|
|
- Economics fundamentals (market forces)
|
||
|
|
- Accessibility reference (WCAG/POUR)
|
||
|
|
- Default typefaces and type scale
|
||
|
|
- Icon library choice
|
||
|
|
- Design system reference
|
||
|
|
- Default design rules
|
||
|
|
|
||
|
|
### 2. Decisioning
|
||
|
|
Process for making new decisions when scaffolds don't apply.
|
||
|
|
|
||
|
|
**Workflow:**
|
||
|
|
1. Inform simplicity — gather minimum viable context
|
||
|
|
2. Narrow options — eliminate conflicts, prioritize alignment
|
||
|
|
3. Weigh information — institutional knowledge → familiarity → research
|
||
|
|
4. Arrive at decision — commit and document reasoning
|
||
|
|
|
||
|
|
### 3. Crafting
|
||
|
|
Checklists for executing decisions consistently.
|
||
|
|
|
||
|
|
**Types:**
|
||
|
|
- Checklists for new interfaces
|
||
|
|
- Checklists for improving fidelity
|
||
|
|
- Checklists for visual style
|
||
|
|
- Checklists for innovation
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## The Decisioning Workflow (Detail)
|
||
|
|
|
||
|
|
### Step 1: What Does Institutional Knowledge Say?
|
||
|
|
|
||
|
|
Institutional knowledge = existing patterns, brand guidelines, tech stack, team capabilities, business constraints.
|
||
|
|
|
||
|
|
**Questions:**
|
||
|
|
- Does an existing component/pattern solve this?
|
||
|
|
- What does our design system prescribe?
|
||
|
|
- What are our technical constraints?
|
||
|
|
- What has leadership/stakeholders indicated?
|
||
|
|
|
||
|
|
**Rule:** Always check internal resources before external inspiration.
|
||
|
|
|
||
|
|
### Step 2: What Are Users Familiar With?
|
||
|
|
|
||
|
|
User familiarity = conventions from similar products, learned behaviors, competitor patterns.
|
||
|
|
|
||
|
|
**Questions:**
|
||
|
|
- What do competitors do for this pattern?
|
||
|
|
- What's the platform convention (iOS/Android/Web)?
|
||
|
|
- What prior experience do users bring?
|
||
|
|
- Jakob's Law: Users spend most time on *other* sites
|
||
|
|
|
||
|
|
**Rule:** Familiarity reduces cognitive load. Novelty requires justification.
|
||
|
|
|
||
|
|
### Step 3: What Does Research Say?
|
||
|
|
|
||
|
|
Research = user testing, analytics, academic studies, heuristic evaluation.
|
||
|
|
|
||
|
|
**Questions:**
|
||
|
|
- Do we have usability data on this pattern?
|
||
|
|
- What does instrumentation tell us?
|
||
|
|
- Are there published studies on this interaction?
|
||
|
|
- Have we tested this with users?
|
||
|
|
|
||
|
|
**Rule:** Research trumps opinion, but absence of research ≠ decision paralysis.
|
||
|
|
|
||
|
|
### Arriving at a Decision
|
||
|
|
|
||
|
|
After weighing all three sources:
|
||
|
|
1. If clear winner exists → choose it
|
||
|
|
2. If conflict exists → prioritize by macro bet alignment
|
||
|
|
3. If uncertainty remains → choose fastest to validate, plan to learn
|
||
|
|
|
||
|
|
**Document your reasoning.** Future you (and teammates) will thank you.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Staging Your Bets
|
||
|
|
|
||
|
|
### Why Bets Matter
|
||
|
|
|
||
|
|
Every design decision is a bet. You're wagering time and resources on an outcome. The question is whether you're betting intentionally or accidentally.
|
||
|
|
|
||
|
|
### Macro vs. Micro Bets
|
||
|
|
|
||
|
|
**Macro bets** = Company-level strategic bets on how to win the market
|
||
|
|
**Micro bets** = Individual design decisions within an interface
|
||
|
|
|
||
|
|
**Critical Rule:** Micro bets are only valid when intentionally supporting macro bets.
|
||
|
|
|
||
|
|
### The 4 Categories of Macro Bets
|
||
|
|
|
||
|
|
| Category | We win by... | Design implications |
|
||
|
|
|----------|--------------|---------------------|
|
||
|
|
| **Velocity** | Getting features to market faster | Reduce time-to-delivery, reuse components, find metaphors in other markets |
|
||
|
|
| **Efficiency** | Managing waste better | Design systems, reuse patterns, reduce WIP |
|
||
|
|
| **Accuracy** | Being right more frequently | Stronger research, measure with instrumentation, discovery sprints |
|
||
|
|
| **Innovation** | Discovering untapped market potential | Uncover "fog of war" with better discovery, find parallels in other markets |
|
||
|
|
|
||
|
|
### How to Stage Your Bets
|
||
|
|
|
||
|
|
1. **Analyze your industry** — Level of competition, market maturity, disruption threats
|
||
|
|
2. **Analyze competitors** — Leading vs. lagging, their bets, their gaps
|
||
|
|
3. **Define customer goals** — Jobs-to-be-done statements
|
||
|
|
4. **Name your bets** — Explicit statements of what you're betting on and why
|
||
|
|
|
||
|
|
### Jobs-to-be-Done (JTBD) Format
|
||
|
|
|
||
|
|
```
|
||
|
|
When [situation],
|
||
|
|
I want to [motivation],
|
||
|
|
So I can [desired outcome].
|
||
|
|
```
|
||
|
|
|
||
|
|
**Good JTBD:** "When I get emails, I want to organize them so I don't lose important information."
|
||
|
|
|
||
|
|
**Bad JTBD:** "Let me add tags, labels, and folders to my email so I can sort things according to my system."
|
||
|
|
|
||
|
|
The difference: Good JTBD focuses on outcome, bad focuses on feature.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Informing Simplicity
|
||
|
|
|
||
|
|
Before diving into design:
|
||
|
|
|
||
|
|
1. **Define 2-3 primary JTBD** — What are users trying to accomplish?
|
||
|
|
2. **Identify your macro bets** — Which category is the company prioritizing?
|
||
|
|
3. **Understand your constraints** — Time, team, tech, budget
|
||
|
|
4. **Know your competition** — Where are they winning/losing?
|
||
|
|
|
||
|
|
**Author's Note:** Do this fast or don't do it at all. Don't get stuck whiteboarding JTBD. Trust your intuition. The goal is informed speed, not perfect analysis.
|