The Information Architecture deliverables that save sprint time

Information Architecture (IA) isn’t ceremony; it’s the compression algorithm for product delivery. A small, sharp set of IA artefacts kills ambiguity early, reduces clarification pings mid-sprint, and prevents rework later.

On Quotemate (Elite Facilities’ RFQ→Invoice platform), seven deliverables did the heavy lifting: task flows & wireflows, content model, navigation model, labelling guidelines, filtering & status schema, state catalogue, and a decision log.

We shipped structure first, pixels second.

The problem we all recognise

Sprints don’t slip because people can’t design or code; they slip because we’re all building slightly different versions of the product in our heads. You can sense it: frequent “quick checks”, tickets that re-open, quiet dread around demos.

Quotemate started where many operations tools start: RFQs in notebooks, approvals in email, progress photos in WhatsApp. Everyone was working hard—and none of it added up cleanly. Our first move wasn’t to design “prettier screens”; it was to align the mental model. That alignment lives in IA.

The promise of good IA (what teams can feel)

• Predictability: Fewer choices per screen → faster decisions.
• Shared language: Labels behave like promises → less renaming mid-sprint.
• Traceability: Decisions written down → no déjà vu debates.
• Focus: Clear ownership of content → no “miscellaneous” dumping ground.

With that, here are the seven deliverables that paid for themselves on Quotemate (what they are, how to make them, why they save time, and the mistakes to avoid).

1) Task flows & wireflows: the spine of the product

What it is: A step-by-step map of user actions, including branches for “what if it goes wrong?”. Wireflows add lightweight frames so you can see the UI skeleton across the journey.

How to make it (fast)

1. Start at the verb (e.g., Create RFQ, Approve Quote).
2. Draft the happy path.
3. Add no more than two failure modes (e.g., offline upload; missing required photo).
4. Annotate inputs (what the user gives) and outputs (what the system saves/sends).
5. Convert into a wireflow: boxes for screens, arrows for transitions, sticky notes for rules.

Why it saves time

• Kills “what happens after this?” messages.
• Unblocks API sequencing and back-end contracts.
• Prevents UI from meandering because the verb is driving the design.

Quotemate example

Two primary flows:

• RFQ: Property → Photos (compressed) → Voice-to-text → Review → Submit.
• Emergency RFQ: A shorter, time-boxed variant for security staff.

Common pitfalls

• Designing from static screens with no journey context.
• Ignoring error/empty states (“we’ll fill it later”).
• Over-branching into a choose-your-own-adventure.

Pro tip: Cap flows at 7–9 steps. If you need more, chunk them into subflows.

2) Content model: the nouns and the rules

What it is: A canonical list of objects and how they relate: Property, RFQ, Quote, PO, Invoice, Photo, User/Role. Think of it as the product’s cast list, with relationships and ground rules.

How to make it (fast)

Create a card per object with:

• Fields: the minimal data required.
• Ownership: who can create/edit/see/delete it.
• Lifecycle: the statuses it passes through.
• Attachments: what can be linked (e.g., photos, POs).
• Relationships: 1:many, many:many.

Why it saves time

• Avoids duplicate fields and double-entry.
• Clarifies where assets “live” (no more files floating in chat).
• Aligns front-end, back-end, and Admin on a single source of truth.

Quotemate example

All photos and POs live on the Job Card associated with an RFQ/Quote chain, not in free-floating messages. That decision alone removed countless “Where should this go?” conversations.

Common pitfalls

• Letting the database schema dictate the interface.
• Skipping ownership rules and permissions (“we’ll decide later”).
• Cramming everything into one object (the “God card” problem).

Pro tip: If two objects share more than 80% of fields and behaviour, they’re probably one object. If they share less than 50%, they’re definitely separate.

3) Navigation model: browse vs do (and front doors)

What it is: A diagram that distinguishes hierarchical browsing from guided doing, plus the common entry points (“front doors”) users take into the product.

How to make it (fast)

• Map the global structure (e.g., Properties, Jobs, Admin).
• Overlay action sequences (Create RFQ, Approve Quote).
• Explicitly mark front doors (e.g., tapping a push notification should land on the right step in the approval flow, not the dashboard).
• Decide bottom navigation once, using the verbs and the most-visited areas.

Why it saves time

• Prevents endless bottom-nav reshuffles.
• Reduces “Where does this action live?” debates.
• Anchors push-notification deep links in a predictable way.

Quotemate example: Browsing jobs is hierarchical (Property → Job list → Job Card). RFQ and approvals are sequences with clear progress and “previous/next” continuity. Front doors: push notifications that land users directly on the approval step.

Common pitfalls

• Mixing browse and do on the same level.
• Burying critical actions two layers deep.
• Designing push notifications without deep-link destinations.

Pro tip: If a user must think “Which tab gets me to the next step?”, your navigation model is leaking.

4) Labelling guidelines: labels as promises

What it is: A two-page micro-styleguide for names and actions: verb forms, tense, title case rules, and forbidden fluff. The rule of thumb: labels should behave like promises—tap the thing, get exactly what it says on the tin.

How to make it (fast)

• Create a glossary of system terms (RFQ, Job Card, Quote, PO, Invoice).
• Set action verbs (“Create RFQ”, “Upload PO”, “Approve quote”, “Send to accounts”).
• Add microcopy patterns for confirmations, errors, and loading.
• Include a tiny do/don’t gallery for the team (e.g., Don’t: Magic Submit).

Why it saves time

• Prevents churny renames late in sprint.
• Keeps tickets, UI, and API endpoints using the same language.
• Reduces user hesitation (cognitive load) during key tasks.

Quotemate example

We leaned into WhatsApp-familiar cues for voice transcription: “Edit transcript”, plain verbs, and confirmation toasts that say what actually happened.

Common pitfalls

• Cute copy that promises more than the system can deliver.
• Noun/verb confusion (“Approval” vs “Approve”).
• Inconsistent punctuation and capitalisation across screens.

Pro tip: Run a five-minute “tap test”: read a label out loud; if the team disagrees on what happens next, the label isn’t a promise yet.

5) Filtering & status schema: findability under pressure

What it is: A contract for the states an item can be in, who can set them, allowed transitions, and the filters that sit on top. The schema gives meaning to colour chips, badges, and Kanban columns.

How to make it (fast)

Create a table:

• State → Definition → Who sets it → Enter/Exit conditions → Colour/token → Visible to. Then define filters by situation: What do ops need to find in 10 seconds?

Why it saves time

• Ends mid-sprint debates over “what ‘In Progress’ means”.
• Enables reliable analytics (time in state becomes meaningful).
• Keeps Admin honest (no “misc” columns).

Quotemate example

A clear chain: RFQ → Quote → PO → In Progress → Completed → Invoiced → Paid with quick filters by status, property, amount, and created date. Colour is functional (contrast-first, daylight safe), not decorative.

Common pitfalls

• Over-granular state lists that no one can maintain.
• Colour without contrast rules or accessibility.
• Filters that don’t match real-world questions.

Pro tip: Each state should answer one question: “What needs to happen next, and by whom?” If it can’t, merge or rename.

6) State catalogue: empty, error, loading, offline (the forgotten 60%)

What it is: A gallery of non-happy-path patterns with recovery actions: empty, error, loading, offline, permission denied. Each includes copy, iconography, and component behaviours.

How to make it (fast)

• One Figma page with tiles per state pattern.
• Provide copy templates (“You’re offline. We’ll upload when you’re back.”).
• Document recovery routes (Retry, Save draft, Edit).

Why it saves time

• Prevents “we’ll fill it later” placeholders that mutate into production bugs.
• Reduces post-QA fixes; engineers aren’t guessing at edge cases.
• Maintains calm in the interface—no jump cuts during slow networks.

Quotemate example

Sunlight-first empties with high-contrast typography; offline photo uploads queue with clear status; retry patterns that never strand users.

Common pitfalls

• Lorem ipsum or vague error copy.
• Loaders that hide context or block navigation.
• No guidance on component behaviour in low-bandwidth environments.

Pro tip: Treat state patterns as reusable components. If you can’t drag-and-drop the “empty” into a new list in seconds, it’s not a pattern yet.

7) Decision log: one page, zero drama

What it is: A running record of choices with a short “because” and a link to the artefact. It’s there to stop backsliding, not to become a second knowledge base.

How to make it (fast)

• Date-stamped bullets in a shared doc or Notion page.
• Format: We chose X over Y because Z. Link →
• Limit entries to decisions that affect flows, data, or permissions.

Why it saves time

• Prevents déjà vu debates two weeks later.
• Onboards new devs and stakeholders in minutes.
• Provides context when you inevitably revisit a choice.

Quotemate example

Logged decisions include photos/POs centralised on the Job Card, the voice-to-text edit step (for accuracy), and the emergency RFQ fast path (for security staff).

Common pitfalls

• Letting it bloat into meeting minutes.
• Burying it in Slack, where knowledge goes to die.
• Writing novels—keep each entry under two lines plus a link.

Pro tip: If a decision doesn’t change a diagram or a spec, it probably doesn’t belong in the log.

Anti-patterns to avoid (the IA graveyard)

1) Starting from screens, not flows

• Smell: Beautiful static mock-ups, unclear what happens next.
• Cost: Endless “where does this go?” chatter; fragile navigation.
• Fix: Force every new UI request to name the verb first; if there’s no verb, it’s not a screen yet.

2) Letting the database name your UI

• Smell: Table names as labels; users must understand the schema to get work done.
• Cost: Cognitive load, misfiled items, support tickets that say “I can’t find X”.
• Fix: Build the content model from user mental models; map to the database later.

3) Colour without a contract

• Smell: Pretty badges and chips with no explicit status definitions.
• Cost: Status theatre; analytics that lie; arguments over red vs amber.
• Fix: Publish a status schema that spells out meaning, transitions, and ownership; choose colours for contrast and accessibility, not vibes.

4) Skipping empties/errors “until later”

• Smell: “We’ll add empty states after MVP.”
• Cost: QA chaos; stranded users; post-launch patches.
• Fix: Maintain a state catalogue. If a component has a happy path, it must have an empty and error sibling before sign-off.

5) Over-branching flows

• Smell: Flow diagrams that look like spaghetti.
• Cost: Paralysis; no one can see the happy path anymore.
• Fix: Limit to the happy path plus two failure modes. Everything else is a backlog note until reality demands it.

6) Wordplay in labels

• Smell: Clever verbs, inconsistent tense, “fun” names for serious actions.
• Cost: Mis-taps; slower decisions; legal risk on irreversible actions.
• Fix: Labels as promises. Prefer “Approve quote” over “Give the thumbs up”.

7) Unowned content

• Smell: Files float between chat, email, and uploads; no one knows the latest.
• Cost: Rework and mistrust; duplicated effort.
• Fix: A content model with ownership and default homes (e.g., all POs live on the Job Card, not in messages).

8) Push notifications without destinations

• Smell: Tapping a notification dumps you on the dashboard.
• Cost: Lost context; incomplete actions; user frustration.
• Fix: The navigation model must define deep links to the exact step in the flow.

9) Decision logs that become novels

• Smell: Three pages to justify a button colour.
• Cost: No one reads it; decisions get remade in meetings.
• Fix: One-line entries with a because and a link. Ruthless brevity.

10) Template worship

• Smell: A 40-page IA PDF no one updates.
• Cost: Theatre over traction.
• Fix: Keep artefacts small, versioned, and in the same workspace as design and tickets. The best deliverable is the one the team actually uses.

In Closing

IA is not a documentation tax; it’s how you avoid paying the rework tax in code. On Quotemate, the right seven artefacts gave everyone the same map: designers, developers, ops managers, and finance. The result wasn’t just tidier files; it was momentum.

When structure leads, speed follows.