information-architecture
Information Architecture
In small products, users find their way by exploring. In large applications — multi-module SaaS, ERPs, analytics platforms, marketplaces — exploration breaks down. The structure itself must do the navigational work. Information architecture is the design of that structure: what exists, what it is called, and how it relates to everything else.
Good IA is invisible. Users find what they need without thinking about the structure. Bad IA forces users to hold a map in their head.
Naming is Design
The names given to entities, sections, and actions are one of the most consequential design decisions in a large application. Bad names create cognitive friction on every visit.
Principles:
- Use the user's vocabulary, not the engineer's. If users call it a "job", do not call it a
task_assignment. If they call it a "client", do not surfacecontact_entity. - Be specific. "Settings" is vague. "Account settings", "Workspace settings", "Notification preferences" tell the user exactly where they are.
- Be consistent. If it is called "Project" in the sidebar, it must be called "Project" in the breadcrumb, the page title, the confirmation dialog, and the API error message.
- Distinguish similar things. If the product has both "Users" and "Members", the distinction must be meaningful and consistently communicated.
- Name actions by their effect. "Archive" not "Hide". "Publish" not "Save to live". "Transfer ownership" not "Change user".
More from dembrandt/dembrandt-skills
nielsen-usability-heuristics
UI design and review should apply Nielsen's 10 Usability Heuristics — the foundational principles for evaluating and improving usability. Use when auditing an interface, designing interaction flows, writing error messages, or reviewing any UI for usability issues.
52color-mode-and-theme
Choose light, dark, or combined color mode deliberately based on brand tone and user context. Offer a theme selector only when user control genuinely matters — enterprise tools, data-heavy UIs, or extended-use applications. Use when defining the base color palette, designing a design system, or deciding whether to build dark mode support.
52user-flows-and-guided-paths
Related features and tasks — such as purchase flows, onboarding, or multi-step configuration — should be designed as natural, guided paths that feel coherent and fit the product hierarchy. Use wizards for complex sequential tasks. Use when designing flows, onboarding, checkout, setup sequences, or any multi-step user journey.
51form-design
Forms have three layers of guidance: helper text below the input explains what to enter, placeholder shows the expected format, and validation confirms correctness. Real-time validation for complex inputs. Submit enables only when the form is valid. Use when designing or reviewing any form, input field, or data entry UI.
51button-states
Every interactive element needs a complete set of visual states — rest, hover, active/pressed, focus, disabled, and loading. States should be derived algorithmically from the base colour, not chosen arbitrarily. Use when designing buttons, links, inputs, or any clickable component.
50semantic-html-and-seo
Semantic HTML5, SEO fundamentals, alt texts, progressive enhancement, SPA considerations, device capability detection, and user context awareness. Good HTML is the foundation of accessibility, SEO, and resilient UI. Use when building any web UI, reviewing markup quality, or optimising for search and accessibility.
49