IDEA9105 Chap.4 Wireframes and Prototype Iteration

Wireframes and Prototype Iteration

A wireframe represents hierarchy, content priority, controls and navigation at a chosen level of fidelity. It should contain enough realistic content to expose spatial and labelling problems. Placeholder blocks can hide the very complexity the design must support. A paper wireframe is efficient for flow and grouping; a clickable mid-fidelity version can test sequence and navigation.

High fidelity is justified when visual trust, brand or microinteraction is the actual question. A form works with short placeholder labels but breaks when medical instructions and validation messages are inserted. Using realistic content earlier reveals scrolling, grouping and error-recovery needs. Write one research question on the prototype cover.

During review, defer comments that the chosen fidelity cannot answer and collect them for the appropriate later artefact. Accessibility belongs inside the interface model. Ask whether wireframe remains perceivable and operable with different input, vision and reading conditions.

Apply fidelity through contrast, hierarchy, labelling and focus order, then inspect whether realistic content communicates status without relying on colour alone. These checks often reveal general usability defects because explicit structure benefits more than one access need. Audit wireframe through keyboard order, focus visibility, readable hierarchy, labels and non-colour feedback.

Ask whether fidelity remains understandable at magnification and whether controls expose name, role, state and error recovery. Accessibility evaluation combines standards, inspection and use by people with relevant access needs. Record realistic content as a concrete interaction defect and verify the repair in the same state, not only on the ideal starting screen.

A test gives a participant a goal without scripting the exact route, records actions and interpretation, and links observations to a design question. Completion alone is insufficient: hesitation, detours, recovery, confidence and misunderstanding reveal where the interface model diverges from the user's. Changing several layers at once can improve the experience while obscuring which assumption was wrong.

Prioritise the breakdown connected to the research question, revise it and preserve a short rationale for comparison. Participants complete a booking task but repeatedly reopen the summary before confirming. The issue is not completion; uncertainty about consequences suggests the summary does not communicate date, cost or reversibility clearly enough. Separate observation from interpretation in notes.

Triangulate repeated patterns, retain minority failures with serious consequences, and choose the smallest prototype able to test the proposed repair. Interface evidence becomes actionable when prototype is tied to a user goal, a context and an observable interaction. Convert usability test into a design requirement that can be inspected in a wireframe or prototype.

Then define the success and failure states for iteration, including the recovery path. A polished screen is not enough if the transition, feedback or accessibility behaviour remains implicit. Write a state inventory for prototype: entry condition, available action, system response, next state and recovery route. Connect usability test to the cue a user can perceive rather than an intention known only to the designer.

What this chapter covers

• 01

  Wireframes make information and flow criticisable

• 02

  Prototype iteration converts failure into evidence

Worked application: Wireframes make information and flow criticisable

Key terms

Wireframe critique

Wireframes make information and flow criticisable — A wireframe represents hierarchy, content priority, controls and navigation at a chosen level of fidelity. It should contain enough realistic content to expose spatial and labelling problems. Placeholder blocks can hide the very complexity the design must support. Write one research question on the prototype cover. During review, defer comments that the chosen fidelity cannot answer and collect them for the appropriate later artefact.

Evidence-driven prototype iteration

Prototype iteration converts failure into evidence — A test gives a participant a goal without scripting the exact route, records actions and interpretation, and links observations to a design question. Completion alone is insufficient: hesitation, detours, recovery, confidence and misunderstanding reveal where the interface model diverges from the user's. Separate observation from interpretation in notes. Triangulate repeated patterns, retain minority failures with serious consequences, and choose the smallest prototype able to test the proposed repair.

Wireframes and Prototype Iteration FAQ

Assessment move

Maintain a decision trail for Wireframes and Prototype Iteration. Connect each user observation to a requirement, interface state, prototype change and next test. Begin with wireframe and reconstruct the reasoning without looking at the worked response. Then change one condition in the example and decide whether fidelity still explains the outcome.

Use the chapter questions to compare direct observation with inference, and write the strongest rival account in full. Before closing the chapter, return to iteration and state the precise boundary it places on transfer. Check that every conclusion names an observable consequence and that uncertainty is attached to the step it affects.

A final retrieval pass should be fast enough to reproduce the method from headings and diagrams while leaving the detailed prose for checking nuance.

IDEA9106 Design Programming · DESN1001 Design Process · INFO5990 Professional Practice