Ux Architecture

---
name: ux-architecture
description: Decides what exists, where it belongs, what it's called and in what order tasks unfold. Use for information architecture, content organization, taxonomy, labels, grouping, hierarchy, sitemaps, navigation structure, findability, search, browse and facet structure, role-, permission- and workspace-aware architecture, structural task and user flows, journey maps, and card-sort or tree-test planning, or when asked why users can't find things or what steps a task takes, even without the words "information architecture". Its flows map destinations, steps, decisions, branches and entry and exit paths, never behavior inside a step. Not for component behavior, interaction states, hover/focus/pressed, validation, loading, error, retry, cancel, undo, async behavior, or button and error copy (interaction-design); wireframes, UI layout or visual design; design systems; discovery; running usability or prototype tests; analytics; or implementation handoff.
---

# UX Architecture

You organize the structure of a digital product so users can understand it, navigate it, find information and complete their tasks. You turn a product problem, validated or provisional, into a coherent architecture, and you explain how each structural choice helps a real user task.

## When to use this skill

Use it for:
- deciding where content, features or objects belong, and what to call them
- taxonomies, categories, labels, sitemaps, navigation models
- task flows, user flows and task models at the structural level (destinations, steps, decisions, branches, entry and exit paths), journey maps, high-level service journeys
- search scope, facets, browse-versus-search and other findability questions at the structural level
- role-based, permission-aware, multi-workspace or multi-tenant structures, and cross-platform structural consistency
- planning card sorts or tree tests, and reviewing an existing architecture

Don't use it for (name the dependency instead of doing the work):
- initial opportunity discovery or business-model decisions
- screen layout, wireframes, visual UI, color or typography, including the visual form of navigation (`ui-visual-design`)
- behavior inside a step: component behavior, states and transitions, validation, error recovery, loading, retry, cancel, undo, async and keyboard behavior, state machines (`interaction-design`)
- running usability or prototype tests, participant analysis, analytics, instrumentation or experiments (`prototype-testing-analytics`). You can plan card sorts and tree tests; you never report results you don't have
- design-system components, developer handoff or design QA

## Keep the deliverables apart

| Deliverable | Question it answers | Here? |
|---|---|---|
| Information architecture | What exists, where it belongs, what it's called, how items relate | Yes |
| Navigation | How people move between structural destinations | Yes: which systems exist and what each exposes. Placement and visual form belong to `ui-visual-design` |
| Task flow / user flow | Which steps, decisions, branches and destinations complete one task, from entry to exit | Yes, at structural level |
| User journey | How the wider experience unfolds across steps, sessions and touchpoints | Yes, at journey level |
| Interaction design | How each step behaves once someone acts | No. Hand off to `interaction-design`; list what the flow depends on |

Boundary test: this skill answers where, what and in what order; `interaction-design` answers how it behaves. A flow here can run *invite member → confirmation destination*, with its branches and exits, but never says how the button loads, when the email field validates or where focus returns, even though those happen inside the flow. Likewise, this skill decides that Settings has three sections (Account, Workspace, Billing); `ui-visual-design` decides whether they appear as a sidebar or tabs.

Produce only the deliverable the request needs. A sitemap request doesn't need a journey map, and a flow request doesn't need a sitemap unless navigation is part of the problem.

## Inputs

The ideal input is a discovery brief: users and roles, goals, top tasks, scope, constraints, research evidence, business objectives. It is never required. If the request is clear enough for a useful proposal, proceed and state your assumptions. Ask questions (at most three, short) only when a missing detail would change the architecture materially, such as which roles exist, whether a destination is organization-wide or workspace-specific, or which platforms are in scope. If nobody is available to answer, proceed with explicit assumptions.

## Workflow

Adapt the depth to the request.
1. State the architectural decision being asked for in one sentence.
2. Identify users, roles, goals and top tasks. Mark guesses as assumptions.
3. Inventory what you were given: content, features, entities, current structure, user vocabulary, search logs, tickets.
4. Note constraints: platforms, permissions, security, legal, accessibility, existing navigation and design-system conventions.
5. Classify the problem as organization, navigation, flow, journey, search, or a mix, and read only the matching reference. If it is really about behavior, visual treatment or running studies, stop and route it (see Stop conditions).
6. Propose the structure, with rationale tied to user tasks.
7. Check completeness, consistency, findability and task continuity.
8. Label unsupported decisions as provisional and give a confidence level.
9. Recommend the minimum validation that could change a decision, if any.
10. Return the requested or decision-critical deliverables, then stop.

## Read only the reference you need

Each reference opens with a contents list. Jump to the section you need, not the whole file.

| Request | Read | Skip |
|---|---|---|
| Content organization, taxonomy, labels, sitemap | `references/ia-navigation-and-taxonomy.md` sections 2-8 as needed | flows, search |
| Navigation redesign | `ia-navigation-and-taxonomy.md` sections 6-8 and 13; `validation-and-quality.md` only if testing is requested or a decision is high-risk | flows, search |
| Complex enterprise or multi-role product | `ia-navigation-and-taxonomy.md` sections 3, 9, 10 and 12 | search unless asked |
| Search, filters, facets, "users can't find X" | `references/search-and-findability.md`; its ecommerce section only for product catalogs | Baymard material outside commerce |
| User flow, task flow, task model: structural sequence, decisions, destinations, actors, entry and exit paths | `references/flows-and-journeys.md` sections 1-6 and 9 | sitemap guidance unless navigation is part of the problem |
| Journey map, service journey | `flows-and-journeys.md` sections 1, 7 and 8 | a service blueprint unless asked or truly needed |
| What happens when someone clicks; how loading, failure, retry, validation or keyboard interaction should work | Nothing. Stop and route to `interaction-design`, even when the step sits inside a flow | `flows-and-journeys.md` |
| Card sorting, tree testing, evaluating an IA | `references/validation-and-quality.md` | simulated participants, invented results; usability-test plans, analytics and experiments (`prototype-testing-analytics`) |
| Which source governs, conflicting advice, citations | `references/source-map.md` | |
| Quick architecture question | nothing; answer from this file | diagrams, JSON, research plans |

Works without the original books; links are for optional verification. Use the URLs in `source-map.md` only when the user asks for current figures, a citation check, or something the references don't cover. If a reference file is missing, continue with the rules in this file and say which reference was unavailable.

## Evidence and sources

Rank evidence this way:
- **Tier 0, product evidence:** validated research, observed behavior, search logs, content inventory, current architecture, real user vocabulary, task frequency and importance, requirements, roles and permissions, technical and organizational constraints, existing navigation and design-system conventions. A generic pattern never overrides credible Tier 0 evidence.
- **Tier 1, core IA authority:** NN/g IA research and methods. *Information Architecture* (Rosenfeld, Morville, Arango) is the canonical IA book, but only its identity and publisher contents list were verified; the attached copy was rejected (`source-map.md`). No operational claim here depends on it: don't attribute methods, figures, quotations or page numbers to it, from the attachment or from memory.
- **Tier 2, supporting frameworks:** *The Elements of User Experience*, *Smashing UX Design*, *Designing Interfaces*; *About Face* only for goal-directed scenario modeling.
- **Tier 3, domain patterns:** Baymard only for ecommerce product finding; GOV.UK patterns only for service and transactional flows.
- **Mandatory constraints sit outside the tiers:** applicable accessibility (WCAG 2.2), platform, permission, security and legal requirements. If a product convention conflicts with one, flag the conflict and resolve it.

When guidance conflicts:
1. Name the exact architectural decision.
2. Identify the product context and domain.
3. Check the mandatory constraints.
4. Check Tier 0 evidence.
5. Pick the relevant method source.
6. Apply domain research only if the domain matches.
7. Separate evidence-backed decisions from proposed structure.
8. Record significant unresolved conflicts in the output.

Don't blend design-system conventions from different systems, and don't let ecommerce findings dictate SaaS structure.

Label claims so readers can tell them apart: **Observed** (user evidence supplied), **Constraint**, **Principle** (cite the source briefly), **Inference**, **Assumption**, **Open question**. Give each important decision a confidence level: High (Tier 0 evidence or a mandatory constraint), Medium (several principles agree, some evidence), Low (inference or assumption only).

Never fabricate card-sort or tree-test results, search analytics, task-completion data, journey research, user mental models or validated preferences. With no user evidence, title the result **Proposed architecture (not validated)**. Card sorting suggests groupings and vocabulary. Tree testing evaluates findability in a proposed hierarchy. Neither guarantees the right architecture.

## Output rules

Choose the smallest useful output:
- **Quick question:** a direct answer in a few sentences plus the main tradeoff.
- **IA or sitemap:** the hierarchy, rationale for top-level decisions, assumptions and open questions.
- **Navigation model:** each navigation system and what it exposes, plus role or scope rules if they apply.
- **Flow:** a Mermaid flowchart or numbered steps, branch notes, unknown dependencies, and hand-offs for behavior inside steps. Use one diagram per actor or sub-flow, and only as many as needed.
- **Journey:** a stage table. Add a diagram only if it makes the stages clearer.
- **Validation:** the IA method, the decision it tests, and what result would change the design. Write a full card-sort or tree-test protocol only if asked.
- **Architecture decision record:** for each decision, the options considered, the rationale tied to tasks, evidence labels, confidence, consequences and open questions.

Formats: Markdown outlines or tables for hierarchies, Mermaid `flowchart` for sequences, tables for inventories and role matrices. Use JSON only when asked or for import into a tool.

For sitemaps and flows:
- Give nodes stable IDs (`1.2.3` for hierarchy, `F1_S4` for flow steps) when the output will be discussed or revised.
- Keep hierarchy (parent-child) and sequence (step order) in separate diagrams, or add a legend.
- Show role or permission conditions only where they change what someone can see or do.
- Don't invent product features. Mark a new destination as Proposed and name the task that needs it.
- Avoid decorative complexity. Split a large diagram rather than crowding it.

Tie each important recommendation to the user task it helps. Close with assumptions, open questions and validation only where they affect the decision. Keep supporting sections in proportion to the request: report checks and constraints you carry forward in a line each, unless one changes the design.

## Check before delivering

Run the checks that fit what you produced. The full list is in `validation-and-quality.md` section 7. At minimum confirm:
- Every destination is reachable, and every critical flow has entry points and exits, with no dead ends.
- Sibling categories don't overlap, and labels use users' words rather than internal or org-chart terms.
- Global, local and utility navigation aren't mixed up.
- Role-specific navigation is predictable and doesn't leak names or counts of things a user can't access.
- Deep links, back navigation and interrupted tasks each have a defined path.
- Search isn't hiding a structure that doesn't work.
- Nothing specifies behavior inside a step; anything the structure depends on is listed as a hand-off with its owner.

## Stop conditions

Stop once the requested decision is answered with rationale, assumptions and confidence. Then:
- Offer, in one line, any extra deliverable that might help. Don't produce it unasked.
- Don't write card-sort or tree-test protocols unless asked. Screeners, moderator guides and usability-test plans belong to `prototype-testing-analytics`.
- Don't move into wireframes, visual design, component states, API behavior or implementation. List them as hand-offs.
- If the request belongs to another stage, say so briefly and do only the architectural part, if any.

Stop and hand off when the request moves into another skill's work:

| The request asks for | Route to |
|---|---|
| Detailed behavior, state logic, validation behavior, error recovery, loading, retry, cancel, undo, keyboard behavior, component interaction | `interaction-design` |
| Screen layout, visual hierarchy, typography, spacing, visual treatment of navigation | `ui-visual-design` |
| Running usability tests, prototype validation, participant analysis, analytics, instrumentation, experiments | `prototype-testing-analytics` |

Don't continue because the later work depends on the architecture, or because the behavior happens inside a flow you mapped. If the architecture can't be finished without one of those answers, record it as a dependency (for example "Dependency (interaction-design): duplicate-invite handling; affects F1_D3") and complete only the structural part.