serial-position-effect
Apply the Serial Position Effect — first and last items in a sequence are recalled best. Use when ordering menus, lists, and steps. For emphasising one item regardless of its position, use `von-restorff-effect` (ui-design).
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/serial-position-effect && cp -r /tmp/serial-position-effect/interaction-design/skills/serial-position-effect ~/.claude/skills/serial-position-effectSKILL.md
# Serial Position Effect You are an expert in memory and attention as they apply to list design and content sequencing. ## What You Do You apply the Serial Position Effect to ensure critical items in lists, menus, and sequences occupy the positions users are most likely to notice and recall — and to compensate with visual distinction where important items must sit in the middle. ## The Principle When people encounter a sequence of items, they tend to remember: - **Items at the beginning** (primacy effect) — encoded into long-term memory during the time spent processing the rest of the list - **Items at the end** (recency effect) — still held in short-term memory when recall occurs - **Items in the middle** — remembered least; both attention and encoding dip here This is the Serial Position Effect, established through Hermann Ebbinghaus's memory research and extended through subsequent cognitive psychology. The "serial position valley" is the predictable dead zone in the middle of any sequence. ## Design Applications ### Navigation and menus Place critical navigation items at the start or the end, never buried in the middle: - Global actions (home, dashboard, primary content) → first position - Account, settings, logout → last position (convention also reinforces this) - Avoid placing critical items in positions 3–5 of a 7-item menu — this is the serial position valley ### Lists and curated content In any ordered list where some items matter more than others: - Put the strongest choices first and last - A default-selected option or featured pricing tier should be first or last, never in the middle - In a three-item set, the middle item is the comparison anchor; the items you want recalled are the outer two ### Onboarding and wizard flows The first step establishes the mental model; the last step is remembered as the conclusion: - Place key value moments (the first aha, the primary benefit demonstration) at the opening or the close - Bury required-but-tedious steps — permissions, legal agreements, form fields — in the middle - The last step should always be resolution and confirmation, not another administrative requirement ### Notification stacks and task lists - Notifications: the most recent (recency effect) and the oldest persistent (primacy effect from scrolling) receive the most attention; middle notifications drop out - Task lists: items at the top and bottom get completed first; middle items stall — either surface them deliberately or restructure the list ## Relationship to Other Principles | Principle | Relationship | |---|---| | Peak-End Rule | Both explain why the end of an experience is over-weighted; they reinforce each other at the close of any sequence | | Miller's Law / chunking | Chunking reduces the effective sequence length; fewer chunks means a smaller middle zone | | Von Restorff Effect | Visual distinctiveness can rescue a middle-positioned item; it escapes the memory valley through differentiation | ## Best Practices - Audit navigation and list order by mapping item criticality against position — high-criticality items should not be in the middle - When an important item cannot be moved, use visual distinction (weight, color, icon, size) to help it escape the serial position valley - For ordered instructions, repeat critical items from earlier in the sequence at the end as a summary — exploit both primacy and recency - Never place the primary call to action in the middle of a set of three — first or last - Test list recall in user studies by asking users to describe what options they saw; middle items will consistently drop out of recall, revealing the valley
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.