Navigation and UX Best Practices for a Read-Only Knowledge Base Serving a Non-Technical Executive
Research brief for a 178-page static HTML business intelligence wiki across 5 categories, designed for a single non-technical CEO user on desktop and iPhone.
Executive Summary
The optimal design for this knowledge base combines a search-plus-category-cards landing page, a collapsible sidebar scoped per category, client-side fuzzy search via Pagefind, and a mobile-first responsive layout using an off-canvas navigation drawer. The architecture should prioritize recognition over recall at every level, since the user is non-technical and visits intermittently. Five categories is the ideal number for primary navigation — within the cognitive sweet spot of 5-7 items that research consistently identifies. Below is the full analysis across seven dimensions, with specific recommendations grounded in evidence from Nielsen Norman Group, Pirolli and Card’s information foraging theory, GOV.UK’s design system, Apple’s Human Interface Guidelines, and 10 exemplar knowledge base sites.
1. Landing Page Design
The Core Trade-Off: Recall vs Recognition
The most consequential finding across all landing page research is the distinction between recall-based and recognition-based navigation. Search requires recall — the user must already know the vocabulary of the wiki to formulate a query. Category browsing uses recognition — the user selects from visible options. For a non-technical CEO with intermittent usage patterns, recognition dominates (NNGroup, “Search Is Not Enough”).
Pattern Evaluation
| Pattern | First-visit orientation | Return-visit retrieval | Non-technical fit | Implementation |
|---|---|---|---|---|
| Search-only (Google-style) | Poor — no mental model | Good if search quality is high | Poor — requires vocabulary | Low |
| Category cards/tiles | Excellent — teaches scope | Good — recognition-based | Excellent — familiar paradigm | Low |
| Recent updates feed | Poor — no structure | Good for “what changed” | Moderate | Medium |
| Dashboard with metrics | None — meta-information | None — doesn’t help find content | Poor — conflates reference with analytics | High |
| Search + Category cards | Excellent | Excellent | Excellent | Low |
Recommendation: Search + Category Cards + Single Featured Update
The landing page should present three layers in this order:
- A prominent search bar below the wiki title and a one-line tagline explaining the wiki’s purpose
- A 5-card grid (one per category) with icon, plain-language description, and page count
- A single pinned “recently added” item at the bottom — not a full activity feed
This mirrors the pattern used by Notion’s help center (hero search + popular topic chips + icon card grid), Shopify’s help center (centered search + “browse by topic” columns), and Confluence knowledge bases (sidebar + space-scoped search + featured cards). All five categories should be visible above the fold on a standard laptop display without scrolling — research from knowledge-base.software shows that adding popular content links to the homepage reduces bounce rate by approximately 14%.
What Exemplar Sites Do
Stripe’s documentation takes a task-oriented approach: persistent search in the header bar, horizontal navigation tabs for major product areas, and a 3-column layout listing top tasks beneath each category heading. Stripe assumes users have context and know what they’re building, making it less suitable as a direct model for a non-technical reader, but the “top pages within each category visible on the landing page” pattern transfers well — it eliminates one click for common lookups.
GitBook documentation sites use a content-first landing where the persistent left sidebar carries the navigation weight, freeing the main area for a card grid of featured starting points. This sidebar-plus-cards dual approach works well when the information architecture is deep.
The Zendesk ecosystem recommends limiting top-level categories to 5-7 — a constraint the BI wiki already meets. At five categories, all options can be displayed simultaneously without overwhelming the user.
Category Card Design
Each card should include an icon (line-art or flat), a plain-language title, a 1-2 sentence description written for a non-technical reader, and a page count (e.g., “15 pages”). Descriptions should avoid taxonomy language: “Companies, people, and organisations we track” rather than “Entity taxonomy.” Cards should be equal-sized in a responsive grid, with a subtle hover state (elevation or border highlight) confirming interactivity. Clicking a card navigates to a category landing page showing all pages in that category as a scannable list with titles and one-line descriptions.
2. Navigation Architecture
No Single Pattern Dominates
Scoring six common navigation patterns across five dimensions reveals fundamental trade-offs:
| Pattern | Exploratory browsing | Targeted retrieval | Scale (180 pages, unequal categories) | Mobile | Learning curve |
|---|---|---|---|---|---|
| Collapsible sidebar tree | 4/5 | 5/5 | 3/5 | 3/5 | 3/5 |
| Flat sidebar, grouped | 3/5 | 4/5 | 2/5 | 3/5 | 4/5 |
| Top-nav + dropdowns | 2/5 | 3/5 | 2/5 | 2/5 | 4/5 |
| Tag-based browse | 4/5 | 3/5 | 5/5 | 4/5 | 2/5 |
| Card grid | 5/5 | 2/5 | 3/5 | 4/5 | 5/5 |
| Alphabetical A-Z index | 1/5 | 4/5 | 4/5 | 4/5 | 5/5 |
Card grids excel at exploration (when the user doesn’t know what they want), collapsible sidebars excel at targeted retrieval (when they do), and tags handle cross-category relationships that no single hierarchy can express. The architecture must layer multiple patterns rather than choose one.
The Unequal Category Problem
The 15/102/50/7/4 distribution across categories creates a specific challenge. At 102 pages (57% of total content), Concepts needs a second level of subdivision — the six sub-domains (operations, strategy, finance, governance, marketing, technology) should function as expandable groups within the sidebar. Source Summaries at 50 pages benefits from a filterable table view on its category landing page. Decisions (7 pages) and Analysis (4 pages), despite their small size, contain the highest-value content and should receive prominent placement — NNGroup’s information architecture research recommends keeping small high-value categories visible rather than folding them into larger ones.
Recommended Architecture: Four Layers
Layer 1 — Global persistent elements (present on every page): Search bar/icon in the header, breadcrumb trail below the header showing category hierarchy.
Layer 2 — Landing page (home): The search + category cards layout described above. This serves as the orientation layer, teaching the user what the wiki contains.
Layer 3 — Category landing pages: Each category gets its own landing page optimised for its content volume. Concepts: grouped by sub-domain with expandable sections. Source Summaries: filterable/sortable table. Entities: alphabetical card grid. Decisions and Analysis: all items visible on one screen with brief summaries.
Layer 4 — Content page sidebar: On each article page (desktop), a left sidebar scoped to the current category shows sibling pages with the current page highlighted. This provides the “you are here” orientation that research shows builds the psychological sense of the whole even when users don’t actively click it.
Making Exploratory and Targeted Modes Coexist
The exploratory user (preparing for a meeting, browsing for context) enters through the card grid on the landing page, drills into a category, and follows cross-references between pages. The targeted user (looking for a specific decision or entity) uses search or navigates directly via the sidebar. Both paths are available from every page: search in the header, category sidebar on the left, cross-reference links within the content. Pirolli and Card’s information foraging theory predicts that users will follow whichever path emits the strongest “information scent” — the goal is to ensure both paths emit strong scent simultaneously.
Hierarchy Depth
Maximum three levels: Home → Category → Page. NNGroup research consensus places the disorientation threshold at 2-3 hierarchy levels. With 5 top-level categories and only Concepts requiring a sub-level, the wiki stays within safe bounds. Miller’s Law (5-7 items per level) is met at the top level; the Concepts sub-domains at six items also fit.
3. Search UX
Client-Side Search for a Static Site
For a 178-page static HTML site, Pagefind is the primary recommendation. Unlike older libraries (Lunr.js, Fuse.js) that require downloading the entire search index upfront, Pagefind splits the index into fragments and downloads only relevant chunks via Web Workers. This keeps initial page loads fast while supporting sites with thousands of pages. It includes built-in UI components, handles auto-excerpts with highlighted matched terms, and supports prefix matching.
| Library | Recommendation | Strength | Weakness |
|---|---|---|---|
| Pagefind | Primary choice | Chunked index, built-in UI, auto-excerpts | Requires build step |
| MiniSearch | Alternative if fuzzy matching needed | BM25 scoring, configurable Levenshtein tolerance | Must build custom UI |
| Fuse.js | Only for short metadata | Good fuzzy matching for titles | Poor for full-text body search |
| FlexSearch | Not recommended | Fast raw speed | Weak typo tolerance, maintenance concerns |
| Lunr.js | Not recommended | Simple and stable | Legacy; use MiniSearch instead |
Search Result Presentation
The inline modal pattern (results appearing in a dropdown as the user types) outperforms full-page results for documentation sites — it reduces friction for quick lookups, which account for the majority of search interactions. Each result should show: title, breadcrumb path (category > subcategory), a text excerpt centered on the matched term with highlighting, and a content-type label (entity, concept, decision, etc.). Results should be grouped by category using non-clickable header separators.
Baymard Institute research recommends bolding the predicted autocomplete portion rather than what the user typed — this creates a stronger “scent” toward the result. Limit visible results to 5-8; no scrollbar within the dropdown.
The Cmd+K / Ctrl+K Pattern
The command-palette search modal (triggered by pressing Cmd+K) is now the gold standard for documentation search, used by Linear, Raycast, VS Code, Notion, Stripe, and Algolia DocSearch. For a non-technical user, this keyboard shortcut must be supplemented with a visible clickable search icon or input field — never rely solely on a keyboard shortcut that the user may not know exists. Chameleon’s pattern analysis recommends announcing the feature with an initial tooltip and providing a secondary visible gateway.
On first open (before any typing), the modal should show recently visited pages — Notion implements this effectively, and it handles the common “I read this recently” re-finding scenario without requiring any search input.
The “Vague Recall” Problem
When a CEO searches for “something about Saturday revenue,” the system needs to bridge conceptual vocabulary gaps. Full-text search with good snippets handles cases where the exact words appear in the content. For genuine concept paraphrasing (“retry logic” matching a page about “transient error handling”), semantic search or a synonym map is needed. At the scale of 178 pages, the practical solution is a manually maintained synonym/alias map in the search configuration rather than a full vector search implementation. Pagefind’s metadata feature allows attaching custom search terms to each page.
Search Behaviour Data
Research indicates that 43-59% of users go straight to search on content-dense sites, though this drops to as low as 14% on sites with strong category navigation. The implication: both search and browse must be first-class. A zero-result rate below 5% is the benchmark for healthy documentation search — any higher indicates missing content, poor indexing, or vocabulary mismatches.
4. Mobile-First Design
Navigation: Off-Canvas Drawer, Not Bottom Tab Bar
The fundamental architecture question on mobile is hamburger menu vs bottom tab bar. For a knowledge base, the answer is clear: an off-canvas left drawer triggered by a hamburger button.
A bottom tab bar caps at 4-5 destinations and is designed for apps with peer-level sections (home, search, profile, notifications). A 178-page hierarchical wiki does not have 4-5 equivalent-weight destinations — it has a deep document tree. NNGroup’s quantitative study of 179 participants confirmed that hidden navigation reduces content discoverability by over 20% and increases task time by 15-39% compared to visible navigation. However, this finding applies to sites where the navigation items are few enough to display — for a wiki with dozens of sidebar items, the drawer is the only viable pattern on mobile.
All three major documentation platforms (Stripe Docs, GitBook, Notion) collapse their sidebar to an off-canvas drawer on mobile. None use a bottom tab bar for document navigation. The pattern consensus is strong.
The drawer should slide in from the left as an overlay (not pushing content), animate at 200-300ms ease-out, dismiss on tap-outside or swipe-left, and show the full navigation tree collapsed by category with the current page highlighted. A search input should appear at the top of the drawer.
Touch Targets
Apple’s Human Interface Guidelines specify 44x44pt as the default control size, with 28x28pt as the minimum. WCAG 2.5.8 (AA) requires 24x24 CSS px minimum; WCAG 2.5.5 (AAA) requires 44x44px. All interactive elements in the navigation — drawer links, hamburger icon, back button, tag pills, search input — should meet the 44px minimum height. The visual element can be smaller if transparent padding expands the tap area.
One critical rule: search inputs must use font-size of at least 16px, or Safari will auto-zoom on focus, breaking the layout.
Swipe Gestures
Safari’s built-in left-edge swipe-to-go-back works automatically for standard multi-page navigation. No implementation is needed for a static wiki — standard <a href> links and the browser’s own back gesture handle this naturally. Do not implement custom swipe-to-open-drawer from the left edge, as this conflicts with Safari’s own back gesture and causes user frustration. Use a tap-only hamburger button instead.
Instead of swipe-between-pages, implement prominent Previous/Next navigation buttons at the bottom of each article — more discoverable and avoids gesture conflicts.
PWA: Worth Implementing
A basic PWA (manifest + service worker) focused on offline reading provides meaningful benefit for a traveling executive. Key considerations for iOS:
- The 7-day cache eviction policy does not apply to PWAs added to the Home Screen — once installed, cached content persists
- 178 pages of HTML + CSS + JS is typically under 10MB compressed, well within Safari’s storage limits (up to 60% of disk space per origin on Safari 17+)
- A precaching service worker can cache all pages during install, enabling complete offline reading
- The user must manually add to home screen (Share → Add to Home Screen) — include an onboarding prompt explaining this on first visit
- Set
apple-touch-icon(180x180px),apple-mobile-web-app-capable, anddisplay: standalonein the manifest
Typography and Layout
| Element | Mobile | Desktop |
|---|---|---|
| Body text | 16-17px (-apple-system) | 18-19px |
| Line height | 1.5-1.6 | 1.5-1.6 |
| Line length | 45-55 characters (natural at 390px with 1rem padding) | 60-75 characters (max-width: 65ch) |
| H1 | 24-28px | 36-48px |
| H2 | 20-24px | 28-32px |
| Sidebar nav text | 14px, 2-line clamp | 14-15px |
Code blocks should use overflow-x: auto with a right-edge fade gradient to signal scrollability (iOS hides scrollbars by default). Tables should be wrapped in an overflow-x: auto container. Design the primary layout at 390px width (iPhone 15 standard); persistent sidebar appears at 1024px and above. Use env(safe-area-inset-*) CSS variables for Dynamic Island / standalone PWA mode.
Long Page Titles in Navigation
Use a 2-line CSS clamp in the sidebar rather than single-line truncation — this preserves enough context for descriptive wiki titles while keeping the list manageable. Pair this with authoring discipline: target 40-60 character titles, put the unique differentiator first (“Q3 Budget Variance” not “Analysis of Budget Variance in Q3”), and avoid filler prefixes (“Overview of…”, “Introduction to…“).
5. Page-Level UX
Essential Elements
These elements should appear on every content page:
Breadcrumbs showing the category hierarchy (Home > Concepts > Finance > [Page Title]) are the single most important orientation cue. GOV.UK’s design research found that users actively use breadcrumbs both to navigate back one level and to jump to the homepage when they feel too deep. On mobile, show only the parent category to conserve space.
Sticky scroll-aware table of contents in a right rail (desktop) or collapsed accordion (mobile). NNGroup’s definitive TOC guide specifies that rail TOCs must be sticky, highlight the active section on scroll, and use a clear heading like “On this page.” Right-rail TOCs are susceptible to “right-rail blindness” (users skip them as ads) — use a plain, non-graphical design.
Last updated timestamp visible near the page title. Its primary function is trust and currency signalling — the absence of a date creates credibility problems for business intelligence content. Pronovix research notes that dateless knowledge base pages trigger doubt about relevance.
Related pages section at the bottom of each page, showing 3-5 cross-referenced pages. This extends the information scent trail and prevents the “dead patch” phenomenon described in Pirolli and Card (1999) where users abandon a site when the perceived value of continuing drops below a threshold. Related links keep the scent alive.
Page type metadata displayed prominently — a coloured label or tag (Entity, Concept, Decision, Analysis, Source Summary) that orients the reader before they begin reading. This visual differentiation helps the user build a mental model of what kind of information they’re consuming.
Anchor links for each heading, enabling precise cross-page linking and section sharing.
High-Value Optional Elements
Reading time estimate: A Simpleview study found up to 40% engagement increase when reading time is displayed — it sets expectations and reduces bounce from long pages. Low implementation cost (word count / 200 words per minute).
Copy link to section: Transforms the knowledge base from a reference tool into a communication tool — the CEO can share a link to a specific section in an email or message.
Back-to-top button: NNGroup recommends placing this in the lower-right corner with the label “Back to top” (not just an arrow icon), but only on pages exceeding approximately 4 screen heights.
Previous/Next navigation at the bottom of each page should be scoped to the current category and only applied where sequential reading makes sense (e.g., within a set of decisions or a multi-part analysis). It should not be a global feature — a random “next page” within an unrelated category creates confusion rather than flow.
6. Information Scent and Wayfinding
Information Foraging Theory
Peter Pirolli and Stuart Card’s information foraging theory (developed at PARC in the late 1990s) is the foundational framework for understanding how people navigate on the web. Users behave like foraging animals: they follow “scent” — proximal cues (link text, images, headings, page titles) that signal the likelihood of finding relevant information. When scent is strong, navigation costs are linear in depth. When scent is weak, navigation costs become exponential — users backtrack, switch strategies, or abandon the site.
The practical implication: every navigational element must emit strong scent toward the content behind it. Link text must be descriptive (“Q3 Revenue Variance Analysis” not “Click here”). Category descriptions must use the user’s vocabulary. Card et al.’s protocol analysis confirmed statistically that users choose links ranked highest by scent (chi-squared p < 0.0001) and backtrack when scent declines.
Berry-Picking Model
Marcia Bates’ berry-picking model (1989) describes real information seeking as non-linear and evolving — users collect fragments from many sources and reformulate their query as they learn. A knowledge base should support this with generous outbound wiki-links within page content, progressive disclosure (summary paragraph at top, detail below), and multiple entry points to each page (search, category, cross-references, related pages).
Graph Views: Attractive but Overrated
Visual relationship maps (the Obsidian-style node graph) are genuinely useful only as local diagrams showing the current page plus its direct connections (5-15 nodes). A full 178-node graph creates what researchers call a “visual hairball” — Mayr et al. (2022) found that non-expert users struggle to extract actionable information from large network visualizations. The full graph is best kept as an authoring/maintenance tool rather than a user-facing navigation aid. A small “this page connects to” diagram on each page adds genuine value without the visual noise.
Colour Coding for Page Types
Colour-coding by category is effective at 3-5 categories and delivers diminishing returns beyond that. The wiki’s 5 categories are at the upper edge of useful colour differentiation. Apply colour to structural elements — tag labels, breadcrumb accent bars, sidebar indicators — rather than full-page backgrounds. Always pair colour with a text label for accessibility (colour alone is insufficient per WCAG 1.4.1 Use of Color). The Interaction Design Foundation notes that colour-coded categories enable users to “scan interfaces efficiently without reading every text label,” but only when the palette is small enough to be learned quickly.
Progressive Disclosure
Structure each page with a summary-first pattern: a 2-3 sentence overview at the top, followed by detailed sections. This supports both the executive who needs a quick answer (“what was the decision on Vendor A?”) and the deeper reader who wants full context. GOV.UK’s content design principles formalize this as the “inverted pyramid” — the most important information comes first, with detail expanding below.
7. Accessibility and Readability
Typography
For extended reading on a knowledge base, the evidence points to larger base sizes than the historical 16px default. A 2022 ACM study found that reading speed and comprehension improved continuously up to 18pt. The U.S. Web Design System (USWDS) defaults to 19px; GOV.UK’s design system uses 19px for body text on large screens.
Recommended type scale:
| Element | Desktop | Mobile |
|---|---|---|
| Body text | 18-19px | 16-17px |
| H1 (page title) | 36-48px | 24-28px |
| H2 (section) | 28-32px | 20-24px |
| H3 (subsection) | 22-26px | 18-20px |
| Captions/metadata | 14-15px | 13-14px |
Use the system font stack (-apple-system, BlinkMacSystemFont, system-ui, sans-serif) as the primary choice. It renders as San Francisco on iOS/macOS — zero loading time, correct optical sizing at all weights, and native platform feel.
Line Length and Spacing
The 45-75 character rule is a cornerstone of readable text, with 66 characters cited as the sweet spot (Robert Bringhurst, “Elements of Typographic Style”). On mobile, aim for 30-50 characters per line. Use max-width: 65ch on the content container to enforce this. Dyson and Haselgrove’s research found that a medium line length of 55 characters supports effective reading at both normal and fast speeds.
Line height should be approximately 1.5x the font size for body text, consistent with WCAG 1.4.12 Text Spacing requirements. Paragraph spacing should be at least 2x the font size. Letter spacing of at least 0.12em and word spacing of at least 0.16em improve readability for users with dyslexia.
Colour Contrast
WCAG AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18pt+ regular or 14pt+ bold). WCAG AAA raises this to 7:1 and 4.5:1 respectively. Use 1a1a1a on ffffff for maximum readability rather than pure black (#000000) on white, which creates excessive contrast that causes eye strain for extended reading.
Dark Mode
Evidence suggests dark mode offers small eye-strain benefits for brief interactions but may harm comprehension for extended reading. If implemented, use off-black (#121212 to 1a1a1a) on off-white (#e0e0e0 to ebebeb) rather than pure black on pure white. Increase font weight by one step in dark mode (regular becomes medium) because light text on dark backgrounds appears thinner. Follow the user’s system preference via prefers-color-scheme and provide a manual toggle.
Dyslexia-Friendly Typography
The OpenDyslexic font has been debunked by research — studies found no significant reading improvement. More effective approaches: use sans-serif fonts with distinct letterforms (Inter, Atkinson Hyperlegible, or Lexend), increase letter spacing to about 35% of average letter width, maintain 1.5x line spacing, left-align all text (never full justification), and keep line lengths under 45 characters.
Print Stylesheet
For the “save as PDF” use case, include a print stylesheet that hides navigation, sidebar, and interactive elements; expands URLs inline after links; sets 12pt body text with 1.2 line height; uses @page { margin: 2cm } for comfortable margins; and applies page-break-inside: avoid on headings, figures, and tables.
8. Exemplar Sites
Sites That Excel at Serving Non-Technical Users With Large Content
| Site | What it does well | Transferable to this wiki |
|---|---|---|
| GOV.UK | Plain language at reading age 9; breadcrumbs + accordion navigation for massive content; extensive user research behind every pattern; content design principles published openly | Writing style, breadcrumb design, accordion pattern for large categories |
| Stripe Docs | Persistent search with AI augmentation; task-oriented category organisation; top-task links surfaced on landing page; clean visual hierarchy | Category-plus-top-pages landing layout; search always visible |
| Shopify Help Center | ”Browse by topic” dense text columns with 3 popular sub-links per category; featured update banner between search and categories; AI-powered search | Dense category layout; single featured-update pattern |
| Notion Help | Dual-layer navigation (popular cards + full sidebar); popular topic chips below search; progressive disclosure | Chips for frequent lookups; sidebar + cards combination |
| NHS Service Manual | Designed for healthcare professionals who may not be tech-fluent; clear heading hierarchy; mobile-first responsive | Accessible design patterns for non-technical professionals |
| MDN Web Docs | Scroll-aware right-rail TOC; breadcrumbs; sidebar scoped to current section; search with category facets | TOC implementation; section-scoped sidebar |
| Apple Support | Card grid for product categories; prominent search; designed for consumers; excellent mobile experience | Category card grid optimised for non-technical users |
| GOV.UK Design System | Documentation about design patterns, written for non-designers; sidebar navigation with clear section grouping; accessible by default | Sidebar grouping; plain language for complex topics |
| Intercom Help Center | AI-powered search (“Ask a question or search”); clean category browsing; article-level “Related articles” | AI search fallback; related pages pattern |
| CFPB Ask CFPB | Financial information written for consumers; question-based navigation; topic browsing with facets; excellent plain language | Plain language model for business/financial content for non-experts |
What the Best Sites Share
Across all exemplars, five patterns recur:
- Search and browse are always co-present — never one without the other
- Category structure is visible on the landing page without scrolling
- Breadcrumbs appear on every content page
- Content is written in plain language regardless of domain complexity
- Mobile is a first-class experience, not an afterthought
9. Implementation Priority Matrix
For a single-user read-only static wiki, prioritise the elements with the highest impact-to-effort ratio:
| Priority | Element | Impact | Effort |
|---|---|---|---|
| P0 (must have) | Search + category card landing page | Orientation + retrieval | Low |
| P0 | Collapsible sidebar with category grouping | Navigation + “you are here” | Medium |
| P0 | Breadcrumbs on every page | Wayfinding | Low |
| P0 | Responsive layout (off-canvas drawer on mobile) | Mobile usability | Medium |
| P0 | 18px body text, system font, 65ch max-width | Readability | Low |
| P1 (high value) | Pagefind search with inline modal results | Targeted retrieval | Medium |
| P1 | Sticky scroll-aware TOC on desktop | Within-page navigation | Medium |
| P1 | Related pages footer on each page | Cross-referencing, scent | Low |
| P1 | Page type colour-coded labels | Mental model building | Low |
| P1 | Last updated timestamp | Trust signal | Low |
| P2 (nice to have) | PWA with offline precaching | Offline reading | Medium |
| P2 | Reading time estimate | Expectation setting | Low |
| P2 | Cmd+K search shortcut with visible trigger | Power user efficiency | Medium |
| P2 | Print stylesheet | PDF export | Low |
| P2 | Dark mode with system preference detection | Comfort | Medium |
| P3 (optional) | Local graph view (current page + connections) | Visual exploration | High |
| P3 | Previous/Next sequential navigation | Linear reading | Low |
Sources
Research and evidence cited throughout this report draws from: NNGroup (information foraging, hamburger menus, TOC design, search vs navigation), Pirolli & Card (1999) (information scent theory), GOV.UK Design System (navigation patterns, content design), Apple HIG (touch targets, mobile typography), WCAG 2.1/2.2 (accessibility requirements), UXPin (line length research), Baymard Institute (search UX), MagicBell (PWA iOS limitations), Chameleon (Cmd+K pattern), and direct analysis of Stripe Docs, Notion Help, GitBook, Shopify Help, Confluence, GOV.UK, and MDN Web Docs.