onto-mcp 0.3.0

package/.onto/domains/ui-design/extension_cases.md

@@ -0,0 +1,563 @@
+---
+version: 2
+last_updated: "2026-03-31"
+source: manual
+status: established
+---
+
+# UI Design Domain — Extension Cases
+
+Classification axis: **change trigger** — cases classified by the type of change that triggers structural evolution of the UI. Cases cover both growth triggers (Cases 1–10) and shrinkage triggers (Cases 11–14).
+
+The evolution agent simulates each scenario to verify whether the existing UI design structure breaks.
+
+---
+
+## Case 1: Large-Scale Feature Addition
+
+### Situation
+
+Adding a new major feature requiring IA changes, navigation updates, and new screen states.
+
+### Case Study: Slack — Clips (2021)
+
+Slack added async audio/video messaging (Clips) to its text workspace. By scoping Clips as a message type — entry point in the composer, playback inline in the timeline — the existing IA and global navigation were unchanged. New empty/error states (permission denied, transcription failure) were required.
+
+### Impact Analysis
+
+| Principle | Impact |
+|---|---|
+| Information architecture | Must fit within existing IA or justify a new top-level section (5–7 item limit) |
+| Screen state completeness | All states (ideal/empty/loading/error) must be defined for new screens |
+| Pattern reuse | Must reuse design system patterns; new patterns must be consistent |
+| CTA hierarchy | Must not conflict with existing CTA hierarchy |
+
+### Verification Checklist
+
+- [ ] Does the IA accommodate the feature within navigation thresholds? → structure_spec.md §Navigation Structure Patterns
+- [ ] Are all states (ideal/first-use/loading/error/no-results) defined? → structure_spec.md §Screen State Matrix
+- [ ] Does the feature reuse design system patterns? → dependency_rules.md §Referential Integrity (Component–Design System References)
+- [ ] Does the CTA not conflict with existing hierarchy? → logic_rules.md §Action Guidance Logic (Primary Action Singularity)
+- [ ] Are async operations covered with loading/success/failure? → structure_spec.md §Required Relationships (Async State Completeness)
+
+### Affected Files
+
+| File | Impact | Section |
+|---|---|---|
+| structure_spec.md | Verify | §Navigation Structure Patterns, §Screen State Matrix |
+| logic_rules.md | Verify | §Navigation Logic, §Action Guidance Logic |
+| dependency_rules.md | Verify | §Information Architecture–Navigation Dependency, §Referential Integrity |
+
+---
+
+## Case 2: New Mobile App Launch
+
+### Situation
+
+Extending the existing web interface to a mobile app (iOS/Android) with responsive adaptations and touch optimization.
+
+### Case Study: Airbnb — Mobile-First Redesign (2014–2016)
+
+Airbnb shifted from desktop adaptation to mobile-first: search became full-screen vertical, tables became cards, hover map became tap-to-select, sidebar became 5-item bottom bar. Touch targets standardized to 48×48dp. Platform-specific: iOS used swipe-back; Android used Material bottom sheets.
+
+### Impact Analysis
+
+| Principle | Impact |
+|---|---|
+| Component transitions | Transition rules required (table → card, sidebar → bottom nav) |
+| Touch targets | All elements must meet 44×44px minimum (WCAG 2.5.5) |
+| Hover alternatives | Touch alternatives required for hover-dependent interactions |
+| Platform conventions | Convention conflicts must have resolution criteria |
+
+### Verification Checklist
+
+- [ ] Are desktop-to-mobile transition rules defined? → structure_spec.md §Responsive Component Transition Rules
+- [ ] Do all touch targets meet 44×44px minimum? → logic_rules.md §Action Guidance Logic (Fitts's Law Application)
+- [ ] Are touch alternatives defined for hover interactions? → dependency_rules.md §Responsive–Component Dependency (Touch Environment → Hover Alternative)
+- [ ] Are platform convention conflicts resolved? → domain_scope.md §Normative System Classification (Tier-1b)
+- [ ] Is content priority preserved in responsive transitions? → dependency_rules.md §Responsive–Component Dependency (Screen Reduction → Content Priority)
+
+### Affected Files
+
+| File | Impact | Section |
+|---|---|---|
+| structure_spec.md | Modify | §Responsive Component Transition Rules, §Navigation Structure Patterns |
+| dependency_rules.md | Verify | §Responsive–Component Dependency |
+| logic_rules.md | Verify | §Navigation Logic (Mobile Navigation Discoverability) |
+
+---
+
+## Case 3: User Type Diversification
+
+### Situation
+
+Expanding from a single user type to multiple types (general, admin, power user) with role-based UI variations.
+
+### Case Study: Notion — Team Plans and Permission Tiers (2020–2022)
+
+Notion expanded from personal tool to team workspace with Members, Admins, and Guests. Each role saw different sidebar content; inaccessible features were disabled with tooltips; out-of-scope features were hidden. Admins had dense settings; Members saw simplified views. A sidebar role indicator communicated permission context.
+
+### Impact Analysis
+
+| Principle | Impact |
+|---|---|
+| Information density | Dense for admins, concise for general users |
+| Permission-based display | Hide vs disable vs upgrade prompt must be consistent |
+| Navigation adjustment | Must adjust per user type without breaking wayfinding |
+| Role context | Users must know which role they operate under |
+
+### Verification Checklist
+
+- [ ] Are density variations designed per user type? → logic_rules.md §Constraint Conflict Checks (Information Density vs Cognitive Load)
+- [ ] Is unpermitted feature handling consistent? → structure_spec.md §Screen State Matrix (No Permission state)
+- [ ] Are admin-only features not exposed to general users? → dependency_rules.md §Referential Integrity (Cross-Screen References)
+- [ ] Is navigation adjusted per user type? → dependency_rules.md §Information Architecture–Navigation Dependency
+- [ ] Is the current role visible? → logic_rules.md §Navigation Logic (Wayfinding Completeness)
+
+### Affected Files
+
+| File | Impact | Section |
+|---|---|---|
+| structure_spec.md | Modify | §Screen State Matrix, §Classification Criteria Design |
+| logic_rules.md | Verify | §Constraint Conflict Checks, §Navigation Logic |
+| dependency_rules.md | Verify | §Referential Integrity, §Information Architecture–Navigation Dependency |
+
+---
+
+## Case 4: Complex Form Addition
+
+### Situation
+
+Expanding from simple inputs to complex forms (20+ fields) with multi-step division, conditional logic, and cross-step validation.
+
+### Case Study: TurboTax — Tax Filing Form Redesign (2019)
+
+Intuit restructured TurboTax (100+ fields) from linear flow to a topic-based hub: sections completable in any order with status indicators. Conditional branching was pervasive ("Self-employment?" → Yes revealed 15+ fields). Auto-save persisted every change. Cross-step validation surfaced errors with links to the conflicting field in another section.
+
+### Impact Analysis
+
+| Principle | Impact |
+|---|---|
+| Multi-step division | Divide into logical, conceptually complete steps |
+| Progress indication | Current step, total steps, inter-step navigation visible |
+| Conditional fields | Show/hide logic based on previous answers defined |
+| Draft saving | Automatic preservation to prevent data loss |
+| Cross-step errors | Errors in another step require navigation to source |
+
+### Verification Checklist
+
+- [ ] Is the form divided into logical multi-step units? → logic_rules.md §Form Design Logic (Multi-Step Form Coherence)
+- [ ] Are progress indicators present? → structure_spec.md §Form Structure Principles (Multi-Step Forms)
+- [ ] Is conditional field logic defined? → dependency_rules.md §Form–Validation Dependency (Multi-Step Form Dependencies)
+- [ ] Is cross-step error navigation defined? → dependency_rules.md §Form–Validation Dependency (Validation → Error Display)
+- [ ] Are all field validation rules defined? → dependency_rules.md §Form–Validation Dependency (Input Field → Validation Rules)
+
+### Affected Files
+
+| File | Impact | Section |
+|---|---|---|
+| logic_rules.md | Modify | §Form Design Logic |
+| dependency_rules.md | Modify | §Form–Validation Dependency |
+| structure_spec.md | Verify | §Form Structure Principles |
+
+---
+
+## Case 5: Real-Time Collaboration Feature Addition
+
+### Situation
+
+Expanding from single-user to multi-user real-time collaboration with presence, conflict resolution, and notification management.
+
+### Case Study: Figma — Multiplayer Design (2016–2019)
+
+Figma pioneered real-time multiplayer design: colored cursors with avatars, concurrent edits resolved via operational transform (no conflict dialogs), connection status indicator (green/yellow/red). Notifications used a sidebar panel rather than popups to prevent fatigue.
+
+### Impact Analysis
+
+| Principle | Impact |
+|---|---|
+| Presence indicators | Visible without disrupting the current user |
+| Conflict resolution | Display/resolution for simultaneous edits defined |
+| Disconnection handling | Offline display and reconnection guidance |
+| Notification management | Change notifications must not cause fatigue |
+
+### Verification Checklist
+
+- [ ] Is a presence indicator designed? → structure_spec.md §UI Design Required Elements (Feedback System)
+- [ ] Are concurrent edit conflict methods defined? → structure_spec.md §Screen State Matrix
+- [ ] Are disconnection/reconnection states defined? → structure_spec.md §Screen State Matrix (Offline state)
+- [ ] Are notifications managed to prevent fatigue? → logic_rules.md §Feedback Logic (Notification Fatigue Management)
+- [ ] Are live regions used for screen reader announcements? → dependency_rules.md §Accessibility–Interaction Dependency (Dynamic Content → Live Region)
+
+### Affected Files
+
+| File | Impact | Section |
+|---|---|---|
+| structure_spec.md | Modify | §Screen State Matrix, §UI Design Required Elements (Feedback System) |
+| logic_rules.md | Verify | §Feedback Logic |
+| dependency_rules.md | Verify | §Action–Feedback Dependency, §Accessibility–Interaction Dependency |
+
+---
+
+## Case 6: Comprehensive Accessibility Improvement
+
+### Situation
+
+Full application of WCAG 2.2 AA to a previously accessibility-deficient interface.
+
+### Case Study: Gov.uk — GDS Accessibility Overhaul (2018–2020)
+
+UK GDS mandated WCAG 2.1 AA for all services. Custom components replaced with native HTML where possible; unavoidable ones received full ARIA specification. The error summary pattern (linked list at form top) became widely adopted. Skip links added to every page; time limits included 20-second warnings with extension buttons.
+
+### Impact Analysis
+
+| Principle | Impact |
+|---|---|
+| Keyboard access | All interactive elements keyboard accessible with logical tab order |
+| Focus management | Traps for modals, restoration on close, management for dynamic content |
+| ARIA specification | Custom components must have roles/states/properties |
+| Time limits | Extension mechanisms required (WCAG 2.2.1) |
+
+### Verification Checklist
+
+- [ ] Is keyboard access available for all interactive elements? → logic_rules.md §Accessible Interaction Logic (Tab Order Integrity)
+- [ ] Are focus traps and restoration applied to modals? → dependency_rules.md §Modal–Focus Dependency
+- [ ] Are ARIA live regions applied to dynamic content? → dependency_rules.md §Accessibility–Interaction Dependency (Dynamic Content → Live Region)
+- [ ] Are ARIA roles/states assigned to custom components? → dependency_rules.md §Accessibility–Interaction Dependency (Custom Component → ARIA Specification)
+- [ ] Are keyboard alternatives provided for drag-and-drop? → dependency_rules.md §Accessibility–Interaction Dependency (Drag-and-Drop → Keyboard Alternative)
+- [ ] Are extension mechanisms provided for time limits? → dependency_rules.md §Accessibility–Interaction Dependency (Time Limit → Extension Mechanism)
+
+### Affected Files
+
+| File | Impact | Section |
+|---|---|---|
+| dependency_rules.md | Modify | §Accessibility–Interaction Dependency, §Modal–Focus Dependency |
+| logic_rules.md | Modify | §Accessible Interaction Logic |
+| structure_spec.md | Verify | §UI Design Required Elements (Accessible Interaction) |
+| domain_scope.md | Verify | §Normative System Classification (Tier-1a) |
+
+---
+
+## Case 7: Dashboard/Analytics Screen Addition
+
+### Situation
+
+Adding data dashboards to an existing CRUD interface with visualization patterns and per-widget state management.
+
+### Case Study: Shopify — Analytics Dashboard (2019–2021)
+
+Shopify added analytics dashboards to its CRUD-focused merchant admin. Each widget loaded independently with its own skeleton and error states. Responsive: desktop 2×3 grid → tablet 2×2 → mobile single-column by merchant priority. New stores saw sample data with a disclosure banner.
+
+### Impact Analysis
+
+| Principle | Impact |
+|---|---|
+| Information hierarchy | Metric priority defines dashboard layout |
+| Chart interactions | Hover, drill-down, filter integration designed |
+| Per-widget states | Loading/error/empty independent per widget |
+| Responsive behavior | Chart rearrangement defined per breakpoint |
+
+### Verification Checklist
+
+- [ ] Is metric priority defined? → structure_spec.md §UI Design Required Elements (Data Display System)
+- [ ] Are chart interactions designed? → logic_rules.md §Data Display Logic
+- [ ] Are per-widget loading/error/empty states defined? → structure_spec.md §Required Relationships (Async State Completeness)
+- [ ] Is responsive layout defined per breakpoint? → structure_spec.md §Responsive Component Transition Rules
+- [ ] Is data freshness indicated? → dependency_rules.md §Referential Integrity (State References)
+
+### Affected Files
+
+| File | Impact | Section |
+|---|---|---|
+| structure_spec.md | Modify | §UI Design Required Elements (Data Display System), §Responsive Component Transition Rules |
+| logic_rules.md | Verify | §Data Display Logic, §Feedback Logic (Loading State Representation) |
+| dependency_rules.md | Verify | §Data–Display Dependency, §Referential Integrity |
+
+---
+
+## Case 8: Internationalization (i18n) Extension
+
+### Situation
+
+Extending from single-language to multi-language support with text expansion, RTL, and locale-specific formatting.
+
+### Case Study: Spotify — Global Expansion to 60+ Markets (2018–2020)
+
+Spotify expanded from 65 to 178 markets: Arabic (RTL), Japanese, German (+30–40% expansion). Fixed-width containers became flexible. RTL: full mirroring (sidebar, progress bars, icons) except media elements. Date/time/number formatting localized per region.
+
+### Impact Analysis
+
+| Principle | Impact |
+|---|---|
+| Text expansion | Accommodate length changes (German +30–40%, Chinese -30%) |
+| RTL support | Layout, icons, progress indicators mirror for RTL |
+| Format localization | Date/time/number/currency accept regional formats |
+| Translation completeness | All user-facing text in translation scope |
+
+### Verification Checklist
+
+- [ ] Does layout accommodate text expansion? → structure_spec.md §Form Structure Principles (Field Width)
+- [ ] Are layout/icons/progress mirrored for RTL? → structure_spec.md §Responsive Component Transition Rules
+- [ ] Do fields accept regional formats? → logic_rules.md §Form Design Logic
+- [ ] Are navigation labels contained after translation? → structure_spec.md §Navigation Structure Patterns
+- [ ] Are all user-facing texts in translation scope? → structure_spec.md §UI Design Required Elements
+
+### Affected Files
+
+| File | Impact | Section |
+|---|---|---|
+| structure_spec.md | Modify | §Form Structure Principles, §Navigation Structure Patterns |
+| logic_rules.md | Verify | §Navigation Logic (Label Clarity) |
+| domain_scope.md | Verify | §Bias Detection Criteria (internationalization absence) |
+
+---
+
+## Case 9: Design System Adoption/Migration
+
+### Situation
+
+Migrating from ad-hoc components to a formalized design system, or between design systems.
+
+### Case Study: Salesforce — Lightning Design System (2015–2018)
+
+Salesforce migrated 200+ screens from Classic UI (23 button styles, 7 modal implementations) to SLDS with 80+ design tokens. Strategy: audit → compatibility layers → screen-by-screen migration with A/B testing → 12-month sunset. "Lightning Ready" badges marked migrated pages. Adoption enforced via automated linting.
+
+### Impact Analysis
+
+| Principle | Impact |
+|---|---|
+| Component audit | Inventory and map existing patterns to design system equivalents |
+| Token standardization | Replace ad-hoc values with design tokens |
+| Migration coexistence | Old and new patterns coexist without confusing users |
+| Governance | Contribution model, versioning, adoption enforcement defined |
+
+### Verification Checklist
+
+- [ ] Is a component audit mapping to design system equivalents complete? → dependency_rules.md §Referential Integrity (Component–Design System References)
+- [ ] Are design tokens the single source of truth? → domain_scope.md §Key Sub-Areas > Design System Architecture (Token System)
+- [ ] Is a migration strategy with coexistence defined? → structure_spec.md §UI Design Required Elements
+- [ ] Are deprecated patterns documented with timelines? → domain_scope.md §Key Sub-Areas > Design System Architecture (Governance)
+- [ ] Is adoption enforced via tooling? → domain_scope.md §Normative System Classification (Tier-2 enforcement)
+- [ ] Are accessibility requirements preserved during migration? → domain_scope.md §Normative System Classification (Tier-1a overrides Tier-2)
+
+### Affected Files
+
+| File | Impact | Section |
+|---|---|---|
+| domain_scope.md | Modify | §Key Sub-Areas > Design System Architecture, §Normative System Classification |
+| dependency_rules.md | Modify | §Referential Integrity, §Source of Truth Management |
+| structure_spec.md | Verify | §Isolated Node Prohibition |
+| logic_rules.md | Verify | §Constraint Conflict Checks (Consistency vs Contextual Appropriateness) |
+
+---
+
+## Case 10: Dark Mode / Theming Addition
+
+### Situation
+
+Adding dark mode or a theming system to a light-only interface.
+
+### Case Study: Apple — iOS 13 System-Wide Dark Mode (2019)
+
+Apple built dark mode on semantic colors (`systemBackground`, `label`) resolving per mode. Elevated surfaces used lighter backgrounds in dark (opposite of light-mode shadows). Contrast verified against WCAG AA in both modes. System respected `prefers-color-scheme`; transitions used cross-dissolve to avoid flashes.
+
+### Impact Analysis
+
+| Principle | Impact |
+|---|---|
+| Semantic tokens | Hardcoded colors become semantic tokens resolving per theme |
+| Contrast ratios | WCAG AA maintained in every theme variant |
+| Elevation model | Light uses shadows, dark uses surface brightness |
+| User preference | Persist and respect system-level settings |
+
+### Verification Checklist
+
+- [ ] Are all colors expressed as semantic tokens? → domain_scope.md §Key Sub-Areas > Design System Architecture (Token System)
+- [ ] Do all variants maintain WCAG AA contrast? → domain_scope.md §Normative System Classification (Tier-1a)
+- [ ] Does the system respect `prefers-color-scheme`? → dependency_rules.md §Source of Truth Management (External Source of Truth)
+- [ ] Is mode transition smooth without flash? → domain_scope.md §Key Sub-Areas > Micro-interaction & Animation (Transition Design)
+
+### Affected Files
+
+| File | Impact | Section |
+|---|---|---|
+| domain_scope.md | Modify | §Key Sub-Areas > Design System Architecture, §Key Sub-Areas > Micro-interaction & Animation |
+| dependency_rules.md | Verify | §Source of Truth Management |
+| logic_rules.md | Verify | §Constraint Conflict Checks (Accessibility vs Visual Simplicity) |
+
+---
+
+## Case 11: Navigation Simplification (Menu Consolidation/Removal)
+
+### Situation
+
+Reducing top-level navigation by consolidating or removing sections. A shrinkage trigger.
+
+### Case Study: Google — Gmail Navigation Consolidation (2022)
+
+Google consolidated Gmail's separate Mail/Chat/Spaces/Meet navigation into a unified sidebar. Chat and Spaces merged; Meet reduced to an icon; Labs features moved to a side panel. Mitigation: reorientation tooltip, redirects from old URLs, settings to restore layout choices.
+
+### Impact Analysis
+
+| Principle | Impact |
+|---|---|
+| Navigation reduction | Removed items must not leave users stranded |
+| URL integrity | Old URLs redirect, not 404 |
+| User reorientation | Established workflows need migration guidance |
+| Secondary navigation | Breadcrumbs, sitemaps, footer links update synchronously |
+
+### Verification Checklist
+
+- [ ] Are all functions still reachable through the new structure? → logic_rules.md §Navigation Logic (Wayfinding Completeness)
+- [ ] Are old URLs redirected? → dependency_rules.md §Referential Integrity (Navigation–URL References)
+- [ ] Are secondary navigation elements updated? → dependency_rules.md §Information Architecture–Navigation Dependency (Navigation Change → Secondary Navigation Update)
+- [ ] Is reorientation guidance provided? → logic_rules.md §Action Guidance Logic (Progressive Disclosure of Guidance)
+- [ ] Are search scope categories updated? → dependency_rules.md §Information Architecture–Navigation Dependency (IA → Search)
+
+### Affected Files
+
+| File | Impact | Section |
+|---|---|---|
+| structure_spec.md | Modify | §Navigation Structure Patterns |
+| dependency_rules.md | Modify | §Information Architecture–Navigation Dependency, §Referential Integrity |
+| logic_rules.md | Verify | §Navigation Logic |
+
+---
+
+## Case 12: Component Consolidation/Retirement
+
+### Situation
+
+Retiring legacy patterns and consolidating multiple implementations into a single approved component.
+
+### Case Study: Atlassian — Atlaskit Consolidation (2020–2022)
+
+Atlassian's products had 5 date pickers, 4 modals, 3 dropdowns with different behavior. Consolidation: cross-product audit → canonical version → 6–12 month deprecation → migration guides → lint rules. The canonical date picker unified Jira/Confluence/Bitbucket use cases via configuration API. Zero-usage components removed; others got "legacy" with console warnings.
+
+### Impact Analysis
+
+| Principle | Impact |
+|---|---|
+| Component audit | All legacy instances identified across the product |
+| Canonical selection | One implementation covers all use cases it replaces |
+| Migration path | Deprecated components need documentation |
+| Deprecation enforcement | Tooling (lint, warnings) enforces migration |
+
+### Verification Checklist
+
+- [ ] Are all legacy pattern instances identified? → dependency_rules.md §Referential Integrity (Component–Design System References)
+- [ ] Does the canonical component cover all use cases? → structure_spec.md §UI Design Required Elements
+- [ ] Is deprecation timeline defined with documentation? → domain_scope.md §Key Sub-Areas > Design System Architecture (Governance)
+- [ ] Is enforcement automated? → domain_scope.md §Normative System Classification (Tier-2 enforcement)
+- [ ] Is accessibility preserved or improved? → logic_rules.md §Accessible Interaction Logic (Native HTML Preference)
+- [ ] Are deprecated components eventually removed? → structure_spec.md §Isolated Node Prohibition
+
+### Affected Files
+
+| File | Impact | Section |
+|---|---|---|
+| dependency_rules.md | Modify | §Referential Integrity, §Source of Truth Management |
+| structure_spec.md | Verify | §Isolated Node Prohibition |
+| domain_scope.md | Verify | §Key Sub-Areas > Design System Architecture (Governance) |
+
+---
+
+## Case 13: Platform Support Discontinuation
+
+### Situation
+
+Dropping support for a platform, browser, or device category. Removes constraints and enables new patterns.
+
+### Case Study: Microsoft — Dropping IE 11 for Microsoft 365 (2021)
+
+IE 11 blocked CSS Grid, Custom Properties, and `IntersectionObserver`, adding 50KB+ polyfills. After dropping: Teams adopted CSS Grid, Outlook enabled theming via Custom Properties, polyfills removed. Migration: 6-month notice, IE-specific banner, degraded read-only in the final month.
+
+### Impact Analysis
+
+| Principle | Impact |
+|---|---|
+| Constraint removal | Enables previously blocked modern patterns |
+| User notification | Advance notice and migration path required |
+| Pattern enablement | Previously impossible patterns available |
+| Dead code removal | Platform-specific workarounds cleaned up |
+
+### Verification Checklist
+
+- [ ] Are users notified with timeline and migration path? → logic_rules.md §Feedback Logic (Feedback Duration by Urgency)
+- [ ] Are platform-specific workarounds removed? → structure_spec.md §Isolated Node Prohibition
+- [ ] Are newly enabled patterns evaluated? → domain_scope.md §Key Sub-Areas > Design System Architecture
+- [ ] Is support documentation updated? → domain_scope.md §Reference Standards/Frameworks
+
+### Affected Files
+
+| File | Impact | Section |
+|---|---|---|
+| structure_spec.md | Modify | §Responsive Component Transition Rules, §Isolated Node Prohibition |
+| domain_scope.md | Verify | §Reference Standards/Frameworks |
+| logic_rules.md | Verify | §Feedback Logic |
+
+---
+
+## Case 14: Feature Simplification (Power User → General User Pivot)
+
+### Situation
+
+Simplifying a feature-rich interface for a broader audience by reducing complexity and restructuring information density.
+
+### Case Study: Microsoft — Simplified Ribbon for Office 365 (2018–2020)
+
+Telemetry showed 80% of users used <20% of Ribbon commands (50+ buttons, 7+ tabs). Simplified Ribbon: 10–15 commands in one row, "..." overflow, toggle to restore classic. Context-sensitive: selecting text showed formatting; selecting an image showed image tools.
+
+### Impact Analysis
+
+| Principle | Impact |
+|---|---|
+| Feature prioritization | Classify by usage frequency for visibility decisions |
+| Progressive disclosure | Advanced features accessible but not prominent |
+| Default experience | Optimize for the majority user |
+| Reversibility | Power users can restore the full view |
+
+### Verification Checklist
+
+- [ ] Are features classified by usage frequency? → logic_rules.md §Constraint Conflict Checks (Simplicity vs Discoverability)
+- [ ] Is progressive disclosure used for non-core features? → logic_rules.md §Action Guidance Logic (Progressive Disclosure of Guidance)
+- [ ] Does the default optimize for the majority? → logic_rules.md §Constraint Conflict Checks (Information Density vs Cognitive Load)
+- [ ] Can power users restore the full view? → structure_spec.md §UI Design Required Elements (Action Guidance System)
+- [ ] Are hidden features still discoverable? → logic_rules.md §Constraint Conflict Checks (Simplicity vs Discoverability)
+- [ ] Is wayfinding completeness maintained? → logic_rules.md §Navigation Logic (Wayfinding Completeness)
+
+### Affected Files
+
+| File | Impact | Section |
+|---|---|---|
+| logic_rules.md | Modify | §Constraint Conflict Checks |
+| structure_spec.md | Verify | §UI Design Required Elements, §Navigation Structure Patterns |
+| dependency_rules.md | Verify | §Information Architecture–Navigation Dependency |
+
+---
+
+## Scenario Interconnections
+
+| Scenario | Triggers / Interacts With | Reason |
+|---|---|---|
+| Case 1 (Feature Addition) | → Case 9 (Design System) | New features may require new design system components |
+| Case 2 (Mobile Launch) | → Case 6 (Accessibility) | Mobile introduces touch accessibility requirements |
+| Case 2 (Mobile Launch) | → Case 8 (i18n) | Global mobile launches often coincide with i18n |
+| Case 3 (User Diversification) | → Case 14 (Simplification) | Adding general users often requires simplifying the power-user UI |
+| Case 4 (Complex Forms) | → Case 6 (Accessibility) | Complex forms have the highest accessibility failure rate |
+| Case 5 (Collaboration) | → Case 1 (Feature Addition) | Collaboration is itself a large feature addition |
+| Case 7 (Dashboard) | → Case 2 (Mobile) | Dashboards need responsive strategies different from forms |
+| Case 8 (i18n) | → Case 10 (Theming) | RTL and theming share token architecture concerns |
+| Case 9 (Design System) | → Case 12 (Consolidation) | Adoption necessitates retiring legacy components |
+| Case 10 (Theming) | → Case 9 (Design System) | Theming requires a token-based design system |
+| Case 11 (Nav Simplification) | → Case 14 (Simplification) | Nav simplification is often part of broader simplification |
+| Case 13 (Platform Drop) | → Case 10 (Theming) | Dropping old browsers enables CSS Custom Properties |
+| Case 14 (Simplification) | → Case 11 (Nav Simplification) | Feature simplification often includes navigation reduction |
+
+---
+
+## Related Documents
+- structure_spec.md — Navigation structure, screen state matrix, responsive transitions, required relationships, form structure, isolated node prohibition
+- dependency_rules.md — IA–navigation, action–feedback, form–validation, modal–focus, responsive–component, accessibility–interaction dependencies, referential integrity, source of truth
+- logic_rules.md — Navigation/form/feedback/modal/action/data display/accessibility logic, constraint conflict checks
+- domain_scope.md — Key sub-areas, normative system classification, reference standards, cross-cutting concerns, bias detection