Structural Blueprint
Table of Contents
This assignment turns a selected concept into a screen-by-screen structural model. Your wireframes should make the system’s logic legible without requiring narration: what matters first, what belongs together, where the user can go, and what changes when the system responds.
TL;DR (read this first)
You’re taking one concept (your campus food wireframe idea) and turning it into three different wireframe structures—A / B / C—to prove you understand screen-by-screen structure (what goes where, what comes first, and how the system responds).
Think:
same product + same goal, but three different “structural blueprints.”
What you’re making (the simple version)
3 wireframe variations (A, B, C)
Each variation is a small set of screens (about 3–5) that shows the core experience.
Each variation must include at least one non-default state (ex: loading, error, unavailable, confirmation, status update).
Clear structure in each variation, using the assignment’s four structural moves:
Hierarchy (what matters first)
Routing (where can I go)
Grouping (what belongs together)
Feedback / States (what changed + what the system tells me)
Tier 1 annotations (lightweight but specific):
Brief notes that clarify intent, key decisions, and what the system is doing (not implementation details).
HCI lenses must be visible in the work:
Always include: Hick’s Law, First-click clarity, Error prevention/recovery
Plus at least one additional lens per variation (ex: progressive disclosure, recognition vs recall, consistency, system status/feedback).
Submission package (what you upload):
Variations A, B, C (each: screens + Tier 1 annotations + at least 1 state)
Make sure your flows are clearly labeled and grouped together. For example, "Predictive Flow For Choosing a Meal" or "Progressive Disclosure Flow for Choosing a Meal". I want to ensure that I know what you are intending for each wireframe flow.
A short reflection (a few bullets) on how your changes connect to the HCI lenses and why you made the structural choices
My Core Concerns:
Do your screens feel like one coherent system across variations?
Are A/B/C meaningfully different structurally (not just rearranged boxes)?
Can I clearly see the HCI lenses and system states in your wireframes?
Are your annotations helping us understand your reasoning quickly?
The rest of the document will clarify the points above (if needed on your behalf). A lot of the detail is meant to help you recall the reasons for what we are doing later on after you graduate and prepare you for your portfolio.
Learning goals
By completing this assignment, you will be able to:
Translate a concept sketch + user flow into wireframes that communicate decision logic over time
Use low fidelity to explore structure quickly while keeping work easy to revise
Make constraints and state changes visible (availability, eligibility, errors, confirmation, status updates)
Apply HCI lenses to reduce cognitive load and support findability and recovery
Visual calibration (look before you build)
Use the examples below to calibrate what “effective” looks like at low fidelity.
What you must start from
Use the structural work you have already produced:
1 selected concept sketch (the concept you are committing to). This is from last week's assignment.
Your IA + user flows that support that concept
Any kind of constraints that may be applicable to your user flow (e.g., time pressure, availability/capacity, eligibility, order status changes, budget, knowledge)
What you will produce
You will complete a total of 5 or more wireframe flows. In your 5 flows, you should ensure that you do all 3 structural variations (happy path, progressive disclosure, IA driven). For example, you may do 1 happy path, 2 progressive disclosures, and 2 IA driven flows.
Part A — Three structural variations (A / B / C)
Each variation should include 3–5 wireframed screens and at least one non-default state.
Variation A — Linear path A straightforward progression with minimal branching.
Variation B — Progressive disclosureI nformation and commitment are staged; details appear when needed.
Variation C — IA-driven alternativeA different organization strategy (navigation-led, search-led, filter-led, constraint-led, or recommendation-led).
Part B — 5+ flows (system coherence)
Your work must show that your concept behaves like a system across at least five distinct flows. These can be selected from a family such as:
browse/search/filter
select pickup time / availability
customize item
checkout/payment/meal plan confirmation
order confirmation/pickup instructions
order status updates (ready/delayed/canceled)
change/cancel/edit actions (where allowed)
You may represent these flows as:
a clearly labeled set of wireframes, or
a “flow coverage” list that points to which screens belong to which flow
Required elements (what must appear in your wireframes)
1) Screen set per variation
For each variation (A/B/C):
3–5+ screens that show entry → key decisions/actions → outcome
A clear primary action on each screen
A clear end state (confirmation, success, or a realistic system outcome)
2) Non-default states (required)
Each variation must include at least one meaningful state beyond the default happy path, such as:
unavailable pickup time (capacity full)
sold out / unavailable item
empty results
payment or eligibility failure
loading/processing
confirmation and/or status update (accepted → ready → delayed/canceled)
3) Tier 1 annotations (lightweight, but specific)
Annotations should clarify intent and system logic without becoming implementation specs. Use brief, specific notes that communicate:
the structural rationale (why grouped this way)
the behavior (what happens after the action)
the assumption (what needs testing or critique)
Avoid vague language such as “intuitive,” “clean,” or “standard.” Prefer observable claims (e.g., “Availability is visible before item selection”).
HCI requirements (must be visible in the work)
Core HCI lenses (apply in every variation A/B/C)
Hick’s Law (choice complexity)
First-click clarity (routing clarity)
Error prevention + recovery (guardrails and fixes)
Additional HCI lenses (apply at least 1 per variation)
Choose at least one per variation:
Recognition vs recall
Progressive disclosure
Consistency/standards
System status/feedback
Submission package (what you upload)
Submit a single PDF (or a single link + PDF export) containing:
Variation A wireframes (3–5 screens + annotations + 1+ state)
Variation B wireframes (3–5 screens + annotations + 1+ state)
Variation C wireframes (3–5 screens + annotations + 1+ state)
Flow coverage (5+ flows clearly named and mapped to screens)
Short reflection (3–5 bullets): how HCI lenses changed your wireframe decisions
Evaluation (40 points)
Criterion | What earns full credit | Points |
Structural coherence | Work reflects one concept consistently across screens and across 5+ flows | 10 |
Variation quality | A/B/C meaningfully differ in structure (not cosmetic changes) | 8 |
States + constraints | Constraints appear at the moment they matter; non-default states are realistic; recovery is visible | 8 |
HCI integration | Core lenses are visible in structure; additional lenses are applied appropriately | 8 |
Annotation clarity | Notes communicate rationale, behavior, and assumptions clearly and specifically | 4 |
Reflection | 3–5 bullets connect decisions to HCI and system behavior | 2 |
Total: 40
Quality signals (what strong submissions tend to show)
Strong submissions typically make these things easy to see:
what the primary action is on each screen
why content is grouped the way it is
where routing choices happen (first click clarity)
what the system does when conditions change (states + recovery)
repeated patterns that could become components later
Bridge forward (why this matters for the next module)
High-fidelity mockups will formalize your validated structure into a visual system: typography, spacing rhythm, iconography, color emphasis, and reusable components. Wireframes that make structure and states clear are easier to convert into high fidelity without redesigning the experience logic.
Locked Message