Skip to pattern guide
Morten A. Giraffe

Pattern 03-01-simple-top-navigation / Navigation / public

Simple top navigation

A restrained header for a small set of primary destinations.

Use when
4–7 primary destinations cover most journeys.
Avoid when
Utility links would overcrowd the primary level.
03 / 01Structure, not styling
01Understand the pattern

What this pattern must solve

Help people move through the information architecture without hiding essential destinations. For this pattern, the practical fit is: 4–7 primary destinations cover most journeys.

Avoid forcing it into the product when utility links would overcrowd the primary level. A recognizable pattern is only useful when it reduces work or uncertainty for the person using it.

Information anatomy

Start with these relationships before choosing layout treatment. Their order may change with the task, but each one needs an explicit place.

  1. Current location
  2. Primary destinations
  3. Utility actions
  4. Compact mobile transformation

States the screenshot will not show

A polished default view is incomplete. Design and verify these states so the implementation stays useful when data, permissions, timing, or connectivity change.

  1. Current route
  2. Expanded group
  3. Keyboard focus
  4. Small-screen menu

Responsive and accessible behavior

Transform navigation deliberately for touch while preserving labels, order, and access to every essential destination.

  1. Use a labeled nav landmark
  2. Expose current location
  3. Support keyboard open, close, and escape

UI/UX and public-page checks

The pattern prompt carries these implementation checks into the task. Apply only the public-page checks that match the route and content.

  1. 02 Hierarchy
  2. 05 Proximity
  3. 06 Consistency
  4. 07 Familiarity
  5. 08 Reach
  6. 14 Accessibility
  7. 15 Responsive
  8. 02 Crawlability
  9. 08 Site architecture
  10. 09 Rendering
  11. 15 Mobile/accessibility

Full implementation prompt

This combines the shared inspection contract, the pattern-specific task, fit guidance, verification requirements, and a visible source link. Replace bracketed context with real product details before using it.

You are designing or repairing a real interface inside an existing product. Do not start by decorating it.

FIRST, establish the screen job in one sentence: “This screen helps [specific user] understand/do [specific thing] so they can [specific next action].” Inspect the current repository, `design.md`, existing components, tokens, routes, data flow, accessibility behavior, tests, and any supplied reference screenshot before editing. Preserve working product behavior and the project’s existing brand language unless the task explicitly replaces it.

Use the Morten A. Giraffe UI/UX field-guide principles as constraints: purpose before polish, visible hierarchy, relationship-driven spacing, meaningful contrast, clear proximity, behavioral consistency, familiar interaction patterns, reachable targets, structured choice, chunking, progressive disclosure, immediate feedback, recoverable errors, accessibility, responsive purpose, deliberate sequence, trust near doubt, and outcome-based measurement.

ANTI-AI-SLOPE RULES: do not default to generic SaaS composition, random gradients, glow effects, glassmorphism, oversized rounded cards, cards-inside-cards, decorative icon circles, fake stats, fake testimonials, meaningless bento grids, excessive pills, filler copy, giant empty spacing, or animation that does not explain state. Do not invent proof, customer names, metrics, security claims, reviews, or product capabilities.

SPECIFIC TASK — SIMPLE TOP NAVIGATION

Use logo/home link, a small set of concrete primary labels, current-page state and one prioritized action only if needed. Keep low-priority utilities elsewhere and define keyboard/focus/mobile-menu behavior without inventing a different IA for mobile.

Use when: 4–7 primary destinations cover most journeys.

Avoid when: Utility links would overcrowd the primary level.

IMPLEMENTATION CONTRACT
- Use semantic HTML and the project’s existing accessible primitives before creating new ones.
- Keep one clear primary action; visually subordinate secondary and tertiary actions.
- Design the complete state model where relevant: idle, hover/focus, loading, success, empty, partial data, disabled, validation error, server error, offline/retry, and permission/locked.
- Preserve user input after recoverable errors. Explain what happened and the next useful action.
- Make keyboard operation, visible focus, logical tab order, screen-reader naming, contrast, reduced motion, zoom/reflow, and touch targets part of the implementation—not a later patch.
- Treat mobile as the same purpose under different constraints, not a squeezed desktop. Verify narrow phones, tablet, desktop, long content, and 200% zoom.
- Avoid new dependencies unless the existing stack cannot reasonably support the requirement.
- Keep copy specific, human, and useful. Button labels should describe the outcome.
- For public/indexable pages, keep important meaning, links, headings, and metadata available without requiring client JavaScript; preserve truthful canonicals, titles, structured data, and internal links.
- Protect performance: avoid layout shift, oversized media, unnecessary client JavaScript, and effects that hurt responsiveness.
- Do not silently remove routes, integrations, analytics, auth behavior, deep links, metadata, or existing functionality.
- Run the project’s relevant build, typecheck, lint, tests, and targeted browser checks after implementation. Fix issues caused by your changes.

BEFORE CALLING IT COMPLETE, report: (1) page/screen job, (2) files changed, (3) what was preserved, (4) UX rules applied, (5) responsive/accessibility states verified, (6) tests/checks run with results, (7) remaining unknowns or production-only checks. Never claim “bug free,” “fully accessible,” or “regression free” without evidence.

Source: Morten A. Giraffe UI Prompt Field Guide — https://www.mortenagiraffe.com/journal/ui-prompt-library-for-vibe-coders/03-01-simple-top-navigation

Verify the result

Reach every primary destination with keyboard only and confirm focus returns after closing overlays. For “Simple top navigation,” success means the interface solves this fit: 4–7 primary destinations cover most journeys.

Also confirm keyboard completion, visible focus, zoom and text reflow, reduced motion, touch targets, loading and error recovery, console output, existing behavior, and any route metadata affected by the change.

02Continue the library

Compare the neighboring patterns.