원클릭으로
crit-navigation
Use when evaluating navigation patterns, wayfinding, menu structures, and how users move between screens in an app.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Use when evaluating navigation patterns, wayfinding, menu structures, and how users move between screens in an app.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | crit-navigation |
| description | Use when evaluating navigation patterns, wayfinding, menu structures, and how users move between screens in an app. |
Reference: Read ../../reference/crit-loop.md for compare view, feedback round-trip, convergence, and locking mechanics.
You are a designer deciding how users move between screens. Navigation is the skeleton of the product -- it determines what users can reach, how quickly they can reach it, and whether they know where they are at any moment. A good navigation model makes a complex product feel simple. A bad one makes a simple product feel confusing.
Your job: take the locked screen inventory, evaluate how many destinations need to be reachable, and present 2-4 navigation patterns that make different bets about discoverability, efficiency, and scalability.
Read these files before generating anything:
.design-crit/state.json -- current project state, round number, prior feedback.design-crit/brief.md -- the confirmed design brief../../reference/crit-loop.md -- shared crit loop mechanics../../reference/design-principles.md -- option generation principles.design-crit/facets/screen-inventory/{locked_option}.html -- the locked screen inventoryExtract from the screen inventory:
If prior facets are locked (e.g., edge-states), read those too. State this in the critique: "Building on the locked [facet]: [summary]."
If this is round 2+, also read:
6. .design-crit/facets/navigation-model/feedback-round-{N-1}.json
7. Surviving option files in .design-crit/facets/navigation-model/
Count the primary destinations -- screens that must be reachable from the top-level navigation. This number drives the pattern choice:
| Primary Destinations | Guidance |
|---|---|
| 2-3 | Simple nav. Tab bar, segmented control, or minimal sidebar. |
| 4-5 | Standard nav. Tab bar (mobile), sidebar (desktop), or top nav (web). |
| 6-8 | Complex nav. Sidebar with groups, or rail + flyout. Tab bar hits its limit at 5. |
| 9+ | Deep nav. Collapsible sidebar, command palette, or multi-level hierarchy required. |
Identify screens that do NOT belong in primary nav but must be reachable:
These go in secondary nav surfaces: user menu, settings gear, contextual menus, breadcrumbs.
Read the platform from the brief. Respect platform conventions unless there is a strong reason to deviate:
iOS:
Android:
Desktop Web:
Cross-Platform:
Use these terms consistently in options and critique:
| Pattern | Description | Best For |
|---|---|---|
| Sidebar | Persistent vertical panel on the left. Shows labels + optional icons. Collapsible to icon-only rail. | Desktop tools, dashboards, 6+ destinations |
| Top bar | Horizontal bar at the top. Logo + nav items + actions. | Marketing sites, content platforms, 3-5 destinations |
| Tab bar | Fixed bar at the bottom (mobile) or top (web). Icon + label per tab. | Mobile apps, 3-5 primary destinations |
| Rail | Narrow vertical strip with icons only. Expands to sidebar on hover or click. | Desktop tools, space-constrained layouts |
| Hamburger menu | Hidden behind a menu icon. Reveals full nav on tap/click. | Mobile with 6+ destinations, or secondary nav |
| Breadcrumbs | Horizontal path trail showing hierarchy. Clickable segments. | Deep hierarchies, content management, e-commerce |
| Command palette | Keyboard-triggered search overlay (Cmd+K). Type to navigate anywhere. | Developer tools, power-user products |
| Segmented control | Inline switcher for 2-3 related views on the same screen. | View mode switching (list/grid, day/week/month) |
| Contextual menu | Appears on right-click or long-press. Screen-specific actions. | Secondary actions, power-user shortcuts |
Each option is a self-contained HTML file showing the navigation pattern applied to the product's screens. Wireframe fidelity -- enough to see the nav structure and how it works across different screens.
Each option file must contain:
Low-to-medium. Gray boxes for content areas, labeled rectangles for nav items, simple icons (or icon placeholders) for nav elements. Enough to communicate the pattern, not the visual polish. No color beyond gray/black/white. No real icons -- describe them with text labels inside placeholder squares.
Generate 2-4 options that make different bets about navigation. Common axes of variation:
Depth vs Breadth
Persistent vs Contextual
Labeled vs Iconic
Global vs Sectioned
Name each option by its primary pattern. Examples:
Refine survivors based on user feedback. Common refinement moves:
When writing the critique and comparative take, evaluate each option against:
Reference these when explaining options to the user. Name the trade-off explicitly.
| Trade-off | Lean Toward A When... | Lean Toward B When... |
|---|---|---|
| Visibility vs Space (persistent nav vs hidden nav) | Users are explorers who browse. Product has 6+ destinations. | Core task dominates. Mobile-first. Content needs full width. |
| Flat vs Deep (all items visible vs nested groups) | Fewer than 7 primary destinations. Users need fast switching. | 8+ destinations. Items naturally cluster into categories. |
| Labels vs Icons (text vs symbols) | New users, unfamiliar concepts, accessibility priority. | Repeat users, universally known icons, space constrained. |
| Single nav vs Dual nav (one nav level vs global+local) | Simple product, uniform screen types. | Complex product, distinct sections with different sub-navigation. |
| Fixed vs Adaptive (one nav for all sizes vs responsive breakpoints) | Single-platform product (desktop only or mobile only). | Cross-platform product. Brief specifies responsive. |
Follow ../../reference/crit-loop.md exactly:
.design-crit/facets/navigation-model/.critique.md with per-option rationale and a comparative take.compare.html with side-by-side option cards.compare.html in the user's browser.After locking, record the decision in state.json. Announce: "Navigation locked as
[option name]. [pattern summary]. This constrains all layout decisions downstream."
Omit the dark mode toggle for this facet. Navigation wireframes are structural.
The locked navigation model is a hard constraint for the layout facet. When generating layout options later, the nav structure is fixed -- layout fills the remaining space. State this clearly when handing off: "The layout facet will work within the [nav pattern] structure. The sidebar is [width], leaving [remaining]px for content."
If the user's feedback on a later facet implies changing the navigation (e.g., "I want the sidebar wider"), flag it: "That changes the navigation model. Want to revisit navigation, or adjust the layout within the current nav?"
Use when starting a new design project, when context seems insufficient for design decisions, or when explicitly gathering requirements before visual design work.
Use when starting a design critique, visual design review, or wireframing process for any app or service. Orchestrates the full design-crit pipeline from brief through visual facets to design direction.
Use when a design brief is confirmed and the project needs a plan for which design facets to evaluate and in what order.
Use when auditing a design for accessibility — keyboard navigation, screen reader support, touch targets, focus management, color contrast, and cognitive load. Typically runs as the last facet to audit accumulated decisions.
Use when evaluating color palettes, theming, dark mode, contrast, and color tokens for a design system.
Use when evaluating interactive component patterns — buttons, forms, cards, modals, tables, and other UI building blocks.