Case Study: Card Anatomy System for Requisition Item Selection

Overview

Designed a reusable card anatomy framework that improves scanability and reduces decision errors when adding items to requisitions.

Quick facts (chips or bullets):

  • Role: UX Design (systems + interaction)

  • Product area: Purchasing / Requisitions

  • Outputs: Card hierarchy model, tier rules, icon/token guidance, Jira-ready criteria

  • Impact focus: Faster decisions, fewer mistakes, consistent UI across teams

Problem

Before: The requisition “add item” card tried to show too much at once. Critical flags (like recall) competed with secondary info (like kit/subs metadata), making it harder to scan and increasing risk of adding the wrong item.

Design challenge:
How might we display decision-critical item signals instantly, while keeping helpful context discoverable—without making the card feel dense or noisy?

Goals

Make “can/should I add this item?” answerable in 1–2 seconds

  1. Separate critical vs contextual vs operational info

  2. Create rules that scale across many item types (stock, non-stock, recall, etc.)

  3. Keep accessibility intact (icons + labels, not icons-only)

Approach: Tiered Information Architecture

Tier 1 — Decision-Critical (Always Visible)

Signals that change whether an item can/should be added (e.g., Recall, Latex, Replacement, Non-Stock).
Rule: If it changes whether I can order it → Tier 1.

Tier 2 — Structural & Relationship Info (Collapsed by Default)

Context that’s helpful but not blocking (e.g., Kit, Substitutes, Complementary, Special handling).
Shown as a single “Item Details” row with counts/links.

Tier 3 — Operational Metadata (Low Emphasis)

Reference/verification details (e.g., Stock on hand, UOM, contract/line info).
Visible but visually quiet.

Footer — Actions

Clear primary action (e.g., Add to Requisition) with predictable placement.

Rules & Governance

Visual hierarchy rules created to protect consistency:

  • Never show more than 4 Tier-1 chips

  • Never mix Tier-1 and Tier-2 visually

  • Tier-2 content must be collapsible / link-based

  • Red reserved for Recall

  • Icons must remain understandable with text labels

What I Delivered (Concrete outputs)

  • Card anatomy checklist for consistent builds

  • Tier model (what belongs where + why)

  • Icon + token mapping and visibility rules

  • Jira-ready acceptance criteria (implementation-ready)

Outcome

This tier system gave the team a shared language for content priority, reduced debate in implementation (“what goes where”), and provided a reusable standard for future item-card variations—supporting faster scanning and fewer decision errors.