Wireframing

Grant Application & Approval Management System — Teaching Tool

What is a wireframe? Story + wireframe pairs Discussion prompts
Concept

What is a wireframe — and why do we use one?

A wireframe is a low-fidelity visual sketch of a screen. It shows layout, structure, and content — but deliberately leaves out colour, typography, and visual polish. The point is to communicate how something works, not how it looks. Wireframes exist to start conversations early, before anything is built.

Fidelity levels

Wireframes exist on a spectrum from rough sketches to near-finished mockups. The right fidelity depends on what question you are trying to answer.

LO-FI — Sketch
When: Early discovery Boxes and labels only. No detail. Used to explore layout and get fast feedback before committing to anything. Often hand-drawn. The roughness is intentional — it signals "this is not final."
MID-FI — Annotated wireframe
When: Requirements sign-off More structure. Placeholders for content. Annotations explain behaviour. Used to align stakeholders on what each screen does before design begins.
HI-FI — Prototype
When: Design handover Close to the final product. Real content, visual design, interactive states. Used for usability testing and developer handover.
Why wireframe at all?
💬
Start the right conversation
A wireframe makes abstract requirements visible. Stakeholders who struggle to engage with a user story will immediately have opinions about a screen layout.
⚡
Fail fast and cheaply
It costs nothing to move a box in a wireframe. It costs a lot to restructure a built screen. Wireframes surface problems before they become expensive.
🔗
Bridge stories and screens
A user story says what someone wants to do. A wireframe shows what the system gives them to do it with. Together they form a complete requirement.
🚫
Resist premature detail
Low fidelity keeps the focus on structure and flow. Adding colour or branding too early derails conversations into aesthetics rather than function.
The story–wireframe relationship

Each user story in this system has a companion wireframe. The wireframe does not replace the story — it extends it. The story tells you who needs what and why. The wireframe shows how the system will let them do it. Use the tabs above to explore four story–wireframe pairs from the grant management system.

Pair 1 of 4

Applicant submission form

USER STORY
"As an applicant, I want to complete and submit a grant application so that I am considered for funding."
WHAT THE WIREFRAME MUST SHOW
The applicant needs to enter information and submit it. The wireframe should show what data is collected, how it is organised, and what happens when they press submit.
LO-FI WIREFRAME — Application submission form
Grant Application Portal New Grant Application Fields marked * are required APPLICANT DETAILS Organisation name * Enter organisation name Contact name * Contact email * Phone number GRANT DETAILS Project title * Funding category * Select category ▾ Amount requested (£) * Project description * Describe the project and its intended impact… Submit application Save draft 1 2 3
1
Text inputs

Plain boxes — no styling detail. The wireframe communicates that a text field exists here, not what it looks like.

2
Dropdown

The ▾ signals a dropdown. We don't need the full list of categories here — that's a content decision, not a structural one.

3
Two actions

Submit (primary, dark) and Save draft (secondary). Visual weight communicates hierarchy without any colour or branding.

Questions Answer individually
FACILITATOR — CLASS DISCUSSION
Talk through these with the group
The wireframe has no colour, no logo, and no font choices. What does that deliberately prevent people from talking about — and why is that useful at this stage?
The user story says "complete and submit." What does the wireframe add that the user story cannot tell us on its own?
What is missing from this wireframe that a developer would need before building this screen?
Pair 2 of 4

Grants officer decision screen

USER STORY
"As a grants officer, I want to approve or reject an application with a rationale so that the decision is formally documented."
WHAT THE WIREFRAME MUST SHOW
The officer needs enough information to make the decision, a way to record their rationale, and two distinct actions. The wireframe must make the weight of the decision visible — this is a consequential action.
LO-FI WIREFRAME — Decision screen
Grant Application Portal ← All applications Application REF-2024-0047 Under review APPLICANT SUMMARY Organisation: Northbridge Community Trust Project: Youth Digital Skills Programme Amount: £24,500 Category: Education Reviewer avg score: 82 / 100 REVIEWER SCORES Reviewer A85/100"Strong community impact evidence" Reviewer B79/100"Budget breakdown needs clarity" + 1 more reviewer DECISION RATIONALE * Record your rationale for this decision… 0/500 This action cannot be undone. A notification will be sent to the applicant. ✓ Approve ✗ Reject 1 2 3
1
Reviewer scores visible

The officer needs the reviewer scores to make an informed decision. The wireframe shows this information is present without specifying its exact format.

2
Mandatory rationale

The asterisk (*) signals this field is required. The wireframe enforces the business rule without writing it as a requirement elsewhere.

3
Warning before action

"This action cannot be undone" is a UX decision communicated in the wireframe. It prompts a conversation about irreversibility before anything is built.

Questions Answer individually
FACILITATOR — CLASS DISCUSSION
Talk through these with the group
The user story says "approve or reject." The wireframe shows these as two visually different buttons. What does that design choice communicate — and what conversation does it start?
The rationale field has a 500-character limit shown in the wireframe. Is a character limit a design decision or a business rule? Who should make that call?
What system stories would automatically fire when the officer clicks Approve? Can you spot evidence of them in the wireframe?
Pair 3 of 4

Reviewer scoring panel

USER STORY
"As a reviewer, I want to score an application and record my written comments so that my assessment is available to the grants officer when making their decision."
WHAT THE WIREFRAME MUST SHOW
The reviewer needs to see the application content, enter a numeric score, and write comments. The wireframe should also make clear what they can and cannot edit — they are assessing, not modifying the application.
LO-FI WIREFRAME — Reviewer scoring panel
Grant Application Portal ← My assigned applications Score application REF-2024-0047 Review deadline: 15 Jan 2025 — 6 days remaining APPLICATION SUMMARY (read only) Organisation:Northbridge Community Trust Project:Youth Digital Skills Programme Amount:£24,500 Description:[Full project description — truncated] YOUR SCORE Overall score (0–100) * — Enter a number between 0 and 100 Scoring guidance 0–40: Does not meet criteria 41–70: Partially meets criteria 71–90: Meets criteria 91–100: Exceeds criteria WRITTEN COMMENTS * Provide your written assessment of the application… 0/1000 Submit score Save draft 1 2 3
1
Read-only section

The grey background signals this area is read-only. The reviewer sees the application but cannot change it — a permission boundary communicated visually.

2
Scoring guidance inline

The scoring scale is shown next to the input. A wireframe decision — do reviewers need guidance on screen, or is training sufficient? That question is now visible.

3
1000-char comment limit

A larger limit than the officer rationale field. This reflects a business decision: reviewer comments are more detailed. Is 1000 right? The wireframe starts that conversation.

Questions Answer individually
FACILITATOR — CLASS DISCUSSION
Talk through these with the group
The application summary section uses a grey background to signal "read only." What other ways could a wireframe communicate that a field cannot be edited?
The scoring guidance is shown inline on the screen. What are the arguments for putting it there versus leaving it to reviewer training?
Which system story fires when the reviewer clicks "Submit score"? What would its trigger, action, and outcome be?
Pair 4 of 4

Reporting officer dashboard

USER STORY
"As a reporting officer, I want to view portfolio-level reports on grant status and spend so that I can report to the funding board."
WHAT THE WIREFRAME MUST SHOW
The reporting officer needs an at-a-glance view of the portfolio. The wireframe must show what data surfaces here, how it is grouped, and what actions (if any) are available. This is primarily a read screen.
LO-FI WIREFRAME — Portfolio dashboard
Grant Application Portal Portfolio Dashboard Financial year: 2024–25 Export CSV KEY METRICS 47 Applications 18 Approved £312k Committed 4 Non-compliant STATUS BREAKDOWN [Bar chart — applications by status] Submitted / Under review / Approved / Rejected BREAKDOWN BY CATEGORY Category Applications Approved Education147 Community114 Environment95 + 3 more categories Total4718 Generate report Export CSV 1 2 3
1
KPI tiles

Four headline numbers. The wireframe raises an immediate question: which four? That is a business decision, not a design one — and the wireframe surfaces it.

2
Chart placeholder

The chart is labelled but not drawn. A lo-fi wireframe says "a chart goes here" — not what kind. Bar, pie, or line? That conversation happens after structure is agreed.

3
"+ 3 more categories"

A wireframe shorthand for "there is more data." It communicates that the table is paginated or expandable without designing how that works yet.

Questions Answer individually
FACILITATOR — CLASS DISCUSSION
Talk through these with the group
The chart is a placeholder box with a label. What decisions about the chart are being deliberately deferred — and who should make them?
This is primarily a read-only screen. What does that tell us about which system stories keep the data on this dashboard accurate?
If the reporting officer asked for "a live view of the portfolio," what would that mean for the system stories behind this screen? What would need to change?