Web Design & Development · Design

WDD3 - Wireframes and low-fidelity prototyping

Mon 16 Nov 2026 · P1+P2 (double)

~120 minutes

Learning intentions

I can describe the purpose of a wireframe.
I can design page and form wireframes that show layout, inputs and outputs.
I can describe how a low-fidelity prototype can be used before implementation.

Success criteria

I can label navigation, content, media, input fields, buttons and output areas on a wireframe.
I can explain what should not be included in a wireframe, such as final colours, fonts or exact images.
I can explain how personas, test cases and scenarios can be used later to test a low-fidelity prototype.

Warm up - from structure to screen

WDD2 organised pages. WDD3 plans what appears on those pages.

WU1

What is the top page in a site structure called?

WU2

Which page from WDD2 is most likely to need a form wireframe?

Opening Times
This is mainly display information.
Workshop Enquiry
Correct. An enquiry page needs input fields and a submit button.
Mammals
This is likely to show animal information, not collect user input.
Prices
This is mostly output content.

WU3

Before a website is built, which of these is most useful to sketch out first?

The exact CSS colours for every page
Exact colour choices come later, once layout is agreed.
A rough layout showing where navigation, content and buttons will go
Correct. This is what a wireframe provides before any styling or code.
The JavaScript functions the page will use
JavaScript is implementation, taught much later in WDD11-13.
The final photographs for the page
Placeholders are enough at this early stage.

Key vocabulary

Wireframe

A simple labelled sketch showing page layout and interface elements before styling or coding.

Low-fidelity prototype

A rough, early model of a design used to test layout, navigation and user flow.

Input area

Part of the interface where a user enters or selects data.

Output area

Part of the interface where information is shown back to the user.

Persona

A fictional profile of a target user, used to think about real user needs.

Scenario

A realistic task a user tries to complete, used later in usability testing.

Planning before building

What a wireframe does

A wireframe is a rough, labelled plan of a page. It shows the position and purpose of the main interface elements: headings, navigation, content areas, media, input fields, buttons and output areas. A wireframe is not a finished visual design. It should not spend time on exact colours, fonts, shadows, final photographs or decorative details.

Include

Navigation areas
Headings and content blocks
Images or media placeholders
Input fields, buttons and outputs

Leave out

Final colours and fonts
Exact photographs
Detailed CSS spacing
HTML tags and code

Purpose

Agree layout early
Check the user flow
Find missing elements
Avoid building the wrong thing

Low-fidelity prototyping

A low-fidelity prototype joins wireframes together so a user can try the rough journey through a site. It might be paper sketches, a simple slide deck, or clickable boxes in a design tool. The point is speed: if the navigation, labels or page layout are confusing, it is much cheaper to fix a rough prototype than a finished website.

Persona

"Primary teacher booking a workshop for 28 pupils."

Scenario

"Find a suitable school workshop and send an enquiry."

Test case

"Enter school name, class size and preferred date, then submit."

This lesson only previews those testing terms. WDD14 teaches usability testing with personas, test cases and scenarios properly.

Worked examples

Example 1 - Home page wireframe

A home page wireframe for Meadows Wildlife Centre should make the main sections visible and promote the most important content. This follows the same notation SQA uses in Appendix 12 (design, WDD): a window frame around the page, plain-bordered boxes labelled by purpose, a crossed box with a filename for any media placeholder, and underlined text for links.

Meadows Wildlife Centre - Home Page

Header: logo + site title

Hero area: welcome message + visit call-to-action

Three fundraising campaign cards

Opening times summary

animal.jpg

Accessibility information

Footer: contact details + social links

Boxes are labelled by purpose, not styled as a finished page — the crossed box marks a media placeholder, matching SQA's own convention.

Example 2 - Form wireframe

The workshop enquiry page needs a form. A good wireframe shows the inputs and action clearly, and still keeps the site's normal navigation so the wireframe reflects the whole page, not just the form.

Meadows Wildlife Centre - Workshop Enquiry

Workshop Enquiry

Input field: school name

Input field: teacher email

Input field: class size

Input field: preferred date

Text area: additional needs or questions

Button: submit enquiry

Output area: confirmation message

WDD5 will implement forms in HTML. For now, the wireframe identifies what the form needs.

Example 3 - Improving a weak wireframe

Weak version: "Big picture, nice title, some information, button." This is too vague because it does not say what each area does.

Improved version: "Hero image placeholder, page heading, opening times summary, prices link, location map placeholder, accessibility information link."

A useful wireframe labels elements by function, so another person can understand what must be built.

Now you try

Sketch a wireframe for the Animal Profile page. It should show an animal name, photo, conservation status, short facts, care notes and a link back to the Animals section.

Header and navigation
Animal name heading
Large image placeholder
Conservation status box
Short facts list
Care notes content area
Back to Animals link

Common mistakes

Drawing a finished design. A wireframe is a rough layout plan, not a polished visual mock-up.
Leaving boxes unlabelled. Every major area should say what it is for.
Forgetting form outputs. A form wireframe should include the confirmation or error message area.
Designing one page in isolation. A wireframe should still respect the site structure and navigation from WDD2.
Testing terminology too early. Personas, scenarios and test cases are previewed here; WDD14 handles them properly.

Exam tip

If asked to design or describe a wireframe, label the parts by function: navigation, input, button, output, media, main content. Do not waste time describing exact colours or fonts unless the question specifically asks for visual style.

Task Set A - Core questions

Task Set B - Extension

Use this for deeper prototype thinking or extra double-period practice.

Create one persona, one scenario and one simple test case for the wildlife centre's low-fidelity prototype.

One possible answer

A visitor tries to find accessibility information on their phone with a slow internet connection. Suggest one wireframe design decision that would help this scenario succeed, and explain why.

One possible answer

Compare a paper wireframe sketch with a clickable low-fidelity prototype tool. Give one advantage of each for testing the wildlife centre website early.

One possible answer

File this in OneNote under:
Higher Computing Science > Web Design & Development > WDD3

Teacher notes - Shift+T to toggle

Suggested timing: 8 min warm up, 15 min notes, 15 min page wireframe, 15 min form wireframe, 10 min prototype/testing preview, 35 min Task Set A, remaining time Task Set B or hand-drawn wireframe practice.

Scope control: do not teach HTML forms here. The form wireframe identifies fields and buttons only; WDD5 implements them.

Preview note: personas/test cases/scenarios are intentionally introduced lightly here and returned to properly in WDD14.

WDD3 - Wireframes and Low-Fidelity Prototyping

WDD3 - Wireframes and low-fidelity prototyping

Key vocabulary

Planning before building

What a wireframe does

Low-fidelity prototyping

Worked examples

Task Set A - Core questions

Task Set B - Extension