Wireframing

Purpose

Create structured, low-fidelity visual layouts that define the information architecture, content hierarchy, navigation structure, and interaction patterns of a concept —without visual design polish (colour, typography, imagery). Wireframes bridge the gap between sketches (too rough for meaningful testing) and high-fidelity mockups (too expensive before validation), providing the “lowest fidelity that enables decision.”

When to Use

Use wireframing when:

• Concept requires more structural clarity than sketches provide
• A2.3 testing needs navigable prototypes (clickable wireframes)
• Stakeholder review requires a level of formality beyond hand-drawn sketches
• Information architecture decisions need to be validated before visual design investment

Do NOT use when:

• Sketches are sufficient for the planned testing approach (paper prototype testing)
• Concept is non-visual (process, policy, or business-model innovation)—use written specification instead
• The team is at risk of over-investing in fidelity—use sketches or Balsamiq to enforce roughness

Sample Size and Duration

Per concept: 2–4 hours (3–7 screens)

Full A2.2: 20–40 hours for 8–12 concepts

Prerequisites

• Selected sketch direction from A2.2 Step~2 (or Design Studio output)
• A1.2 user journey (scenarios to wireframe)
• A1.3 P0/P1/P2 success criteria (must-have elements)
• Wireframing tool (Figma, Sketch, Balsamiq, or paper templates)
• Design system component library (if available)
• 2–4 hours per concept (3–7 screens)

Complete Procedure

Step 1: Define Screen Inventory (15 minutes per concept)

1. List the screens needed to represent the user journey (typically 3–7 per concept)
2. Prioritise: start with the core interaction screen, then entry point, then result/outcome
3. Identify which screens the engineering SME should review for feasibility

Step 2: Layout Each Screen (20–30 minutes per screen)

1. Define content zones: header, primary content area, navigation, calls to action, supporting information
2. Establish hierarchy: what does the user see first? What is the primary action?
3. Use grey boxes and placeholder text; avoid colour, imagery, or brand elements
4. Apply platform conventions (iOS safe areas, Android material grid, responsive breakpoints for web)

Step 3: Connect Screens (15–30 minutes per concept)

1. Define navigation flow between screens (Figma interactive links, arrows on paper)
2. Show decision points: what happens if the user takes path A vs. path B?
3. Create clickable prototype if planned A2.3 testing requires one

Step 4: Annotate Design Rationale (10–15 minutes per concept)

1. Add annotations explaining key design decisions
2. Link decisions to A1 evidence: “This element addresses A1.3 P0 criterion: [specific criterion]”
3. Note open questions: “Is this navigation pattern intuitive? To be tested in A2.3.”

Quality Criteria

1. 3–7 screens per concept at consistent fidelity
2. Information hierarchy clear (primary action identifiable within 3 seconds)
3. Navigation flow documented (screens linked)
4. Design rationale annotations present
5. No visual design polish (grey boxes, placeholder text)
6. Platform conventions applied where relevant

Theoretical Foundation

Seminal references:

• : Defined the five planes of user experience (strategy, scope, structure, skeleton, surface) and positioned wireframing at the skeleton plane: the arrangement of elements that gives the interface its form. Garrett's model clarifies why wireframes must precede visual design—structure must be validated before surface is applied.
• : Demonstrated that paper wireframes and prototypes produce testing insights comparable to digital prototypes at a fraction of the cost and time. Established that user feedback quality depends more on concept clarity than visual fidelity.

Contemporary references:

• : Distinguished between wireframes as “sketches” (used for exploration, intentionally ambiguous) and wireframes as “specifications” (used for handoff, intentionally precise). A2.2 wireframes are closer to the sketch end: they communicate structure and intent, not pixel specifications.

Challenges and Solutions

Challenge: Fidelity Creep

• Symptoms: Wireframes evolve into high-fidelity mockups (colour, typography, icons added)
• Solution: Use Balsamiq (intentionally rough aesthetic) or enforce a grey-only colour rule in Figma. Remind team: “If it looks finished, users won't give honest feedback about structure.”

Relationship to Other Methods

Wireframing receives input from:

• Design Studio (the referenced method) or A2.2 Step~2 sketches (selected direction)
• User Flow Mapping (the referenced method) (interaction sequence to wireframe)

Wireframing provides output to:

• Design Critique (the referenced method) (artefact reviewed in Step~4)
• A2.3 Idea Selection (wireframes as test prototypes)
• A2.4 Concept Specification (wireframes as input to technical specification)

• B. Buxton (2007). Sketching User Experiences: Getting the Design Right and the Right Design. Morgan Kaufmann.
• C. Snyder (2003). Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. Morgan Kaufmann.
• J. J. Garrett (2010). The Elements of User Experience: User-Centered Design for the Web and Beyond. New Riders.