Game Design Thinking Fast and Slow Audit#

Audit a design by asking what kind of thinking it demands from the player, when, and whether that demand is appropriate.

Use this skill when a proposal sounds good in the abstract but may be mismatched to the kind of cognition it actually requires. The goal is to identify where the design leans on fast, intuitive, low-deliberation processing versus slow, analytical, effortful reasoning, and where the transition between those modes becomes awkward, exhausting, misleading, or strategically dead.

Read references/family-conventions.md when you want the shared style, prioritization, and diagnosis rules for this game-design skill family. Read references/output-patterns.md when you want the preferred recommendation and minimal-fix structure.

Core principle#

Players do not think in one uniform way.

Some situations ask for:

• rapid pattern recognition
• instinctive response
• snap prioritization
• fluent repetition

Other situations ask for:

• deliberate comparison
• explicit planning
• rule-based reasoning
• careful tradeoff evaluation

Neither mode is automatically better. The important questions are:

• which mode the design is asking for
• whether that suits the fantasy and pacing
• whether the player is being supported properly
• whether the handoff between modes is clean

Fast and slow lenses#

Fast-mode thinking#

Typical qualities:

• intuitive
• automatic
• rapid
• pattern-based
• low-deliberation
• emotionally immediate

In game terms, this often appears in:

• action combat
• dodging, aiming, timing, rhythm
• snap tactical prioritization
• recognition of familiar board states
• habitual session actions
• high-tempo moment-to-moment play

Slow-mode thinking#

Typical qualities:

• reflective
• effortful
• explicit
• comparative
• planning-heavy
• cognitively expensive

In game terms, this often appears in:

• deckbuilding and loadout decisions
• long-horizon economy planning
• puzzle decomposition
• route planning
• team composition
• optimization and meta decisions

What to produce#

Generate:

1. Thinking-mode profile - whether the design primarily demands fast thinking, slow thinking, or a layered mix
2. Mode-fit diagnosis - whether the required thinking mode matches the fantasy, pacing, and audience
3. Transition diagnosis - where the design shifts between fast and slow modes, and whether those handoffs work
4. Cognitive risk map - where the design creates overload, confusion, autopilot deadness, or false depth
5. Design actions - what to simplify, deepen, pace differently, surface more clearly, or separate

Process#

1. Define the audit target#

Clarify:

• what exact game, feature, loop, or proposal is being audited
• whether the audit is for minute-to-minute play, meta systems, onboarding, or the full experience
• what player segment matters most

Write:

• Audit target
• Scope
• Primary player segment

2. Identify the dominant thinking demand#

Ask:

• what does the player have to notice, decide, remember, and prioritize?
• how much time do they have to do it?
• are they reacting from fluency or stopping to reason explicitly?
• what mistakes come from speed versus what mistakes come from misunderstanding?

Classify the dominant demand as:

• mostly fast-mode
• mostly slow-mode
• mixed, with one dominant
• deeply hybrid

3. Map where each mode appears#

Break the experience into phases or layers such as:

• onboarding
• moment-to-moment play
• build/loadout decisions
• economy or progression planning
• social/coordination layer
• end-of-run reflection

For each phase, identify:

• Thinking mode demanded
• Why that mode is required
• Whether the player has enough support

Use this format:

Phase or systemThinking modeDemand levelNotes...Fast / Slow / MixedLow / Med / High...

4. Check fit between mode and fantasy#

Ask:

• does the cognitive demand support the intended fantasy?
• is the game claiming flow, mastery, panic, elegance, command, coziness, or brilliance?
• does the required thinking mode reinforce that promise or betray it?

Examples:

• a fantasy of fluid sword mastery should not constantly hard-stop into spreadsheet reasoning
• a fantasy of careful grand strategy should not bury important choices inside twitch pressure
• a cozy planning game can tolerate slow thought, but not exhausting ambiguity

5. Diagnose fast-mode failure patterns#

Look for:

• reaction demands too fast for the available clarity
• hidden information inside high-speed play
• too many simultaneous priorities
• snap judgments punished by information the player could not reasonably process
• UI that slows recognition instead of supporting it
• panic without readable action value

6. Diagnose slow-mode failure patterns#

Look for:

• analysis burden too high for the payoff
• false complexity with obvious dominant answers
• too many variables to compare meaningfully
• long planning phases that are cognitively costly but emotionally flat
• systems that imply deep strategy but resolve shallowly
• excessive memory burden or bookkeeping

7. Diagnose transition failures between modes#

This is often where designs get ugly.

Look for:

• abrupt switches from high-speed execution to deep planning without recovery time
• long slow-mode interruptions that kill fast-mode momentum
• fast-mode punishment for choices made in poorly supported slow-mode spaces
• slow-mode systems whose consequences only appear in frantic real-time moments
• a requirement to do deep reasoning under time pressure when the interface does not support it

Ask:

• where does the player shift modes?
• is the shift clean, intentional, and well-signaled?
• does the game give enough time, framing, and UI support for the new mode?

8. Identify audience mismatch and expertise effects#

Ask:

• does this design feel intuitive to experts but exhausting to new players?
• does it ask casual players for tournament-level reasoning?
• does it flatten expert depth into autopilot?
• does the intended audience actually want this blend of cognition?

A system can be good for one audience and terrible for another because of thinking-mode mismatch alone.

9. Convert findings into design changes#

For each major issue, specify:

• Thinking-mode problem
• Why it hurts the experience
• Suggested change
• Expected effect

Examples:

• reduce simultaneous fast-mode demands -> improves readability and decision confidence
• move some choices out of real-time pressure -> supports better slow-mode reasoning
• compress false-complexity planning layers -> preserves depth while reducing fatigue
• add clearer state framing before mode shifts -> reduces cognitive whiplash

Response structure#

Use this structure unless the user asks for something else:

Audit Target#

• ...

Thinking-Mode Profile#

• ...

Fast-Mode Demands#

• ...

Slow-Mode Demands#

• ...

Transition and Handoff Issues#

• ...

Audience and Expertise Fit#

• ...

Recommendations#

1. ...
2. ...
3. ...

Minimal Fix#

• ...

Fast mode#

Use this quick pass when speed matters:

• Is this mainly asking for instinctive play or analytical play?
• Does that fit the fantasy and pacing?
• Where is the worst mismatch?
• Where does the player switch modes?
• What one change would most improve the cognitive fit?

Usage notes#

This audit is especially useful for:

• action/strategy hybrids
• real-time systems with heavy pre-planning
• economy layers attached to fast gameplay
• onboarding for cognitively demanding games
• puzzles embedded inside otherwise reactive experiences
• proposal reviews where the cognitive demand is still fuzzy
• UI-heavy systems that may be hiding slow thought inside supposed fast play

Common patterns to watch for:

• many proposals accidentally ask for more slow thinking than their fantasy can sustain
• some designs confuse time pressure with depth
• some planning layers create the appearance of strategy without meaningful choice
• many frustrating systems are really bad handoffs between fast and slow modes
• expert fluency can hide a beginner-facing cognitive disaster

Working principle#

A strong design does not just ask the player to think. It asks them to think in the right way, at the right time, with the right support.

Use this skill to identify whether the proposal's cognitive demands are elegant, mismatched, exhausting, or fake-deep.