← Course home N5 Computing Science  ·  James Gillespie's
SDD  ·  Software Design & Development

Design: Wireframe UI Design

Lesson SDD3b Approx 60 min Prerequisite: SDD3 — Structure Diagrams & Flowcharts
Learning intentions
  • Understand what a wireframe is and why it is used during the Design stage of software development
  • Identify and name common input and output elements used in user interface design
  • Justify the choice of an appropriate UI element for a given program scenario
  • Create a wireframe using draw.io to plan a user interface
Success criteria
  • I can define the term wireframe and state at which stage of the development cycle it is created
  • I can name at least 5 different input elements and describe when each is used
  • I can name at least 3 different output elements and describe what each displays
  • I can choose and justify an appropriate UI element for a described scenario, explaining why it is better than an alternative
  • I can produce a wireframe in draw.io that includes labelled input and output elements
Warm up — what do you already know?

Answer before the lesson begins. These check prior knowledge — it's fine if you're unsure.

1. At which stage of the software development cycle is a wireframe typically created?

2. Which input element is designed for a user to type a single short line of text, such as their name?

3. What does a wireframe not typically include?

Key vocabulary

wireframe
A low-fidelity diagram showing the layout of a user interface — positions, sizes, and types of elements, without real colours or images.
user interface (UI)
The part of a program that the user sees and interacts with — screens, forms, buttons, and displayed output.
input element
A component the user interacts with to provide data — e.g. text box, dropdown, radio button, checkbox, button.
output element
A component that displays information to the user — e.g. label, table, paragraph text, image placeholder.
annotation
A note on a wireframe explaining what an element does, what data it holds, or what validation rules apply.
dropdown list
An input element that lets the user select exactly one option from a predefined list. The user cannot type a custom value.
radio button
An input element used when the user must select exactly one option from a small fixed set (e.g. Yes / No).
checkbox
An input element the user can tick or un-tick. Unlike radio buttons, multiple checkboxes can be selected at once.
low-fidelity
Simple and sketch-like — a wireframe is low-fidelity because it shows structure without realistic styling.

Wireframe UI Design

What is a wireframe?

A wireframe is a simple, low-fidelity diagram that shows the planned layout of a user interface (UI) before any code is written. It is created during the Design stage of the software development process, after requirements have been agreed in the Analysis stage.

A wireframe looks like a sketch: plain grey boxes represent input fields and images, labels name each element, and buttons are shown as filled rectangles. There are no real colours, fonts, or photographs — those details come in later, higher-fidelity prototypes or in the finished program.

Why create wireframes?

  • Plan before you code: it is much faster to move a box on a wireframe than to rewrite HTML and CSS.
  • Communicate the design: wireframes let developers, clients, and teammates agree on the layout before implementation starts.
  • Spot usability problems early: reviewing a wireframe often reveals missing elements or confusing layouts before any development effort is invested.
  • Serves as a blueprint: once agreed, the wireframe guides the programmer during Implementation.

Input elements

Input elements are the parts of the UI where the user provides data to the program. Choosing the right element matters — the wrong choice can cause errors and frustration.

Element When to use Example
Text box User types a short, free-text value (one line) Name, username, search term
Text area User types a longer, multi-line piece of text Comments, description, review
Dropdown list User selects exactly one option from a long predefined list Country, genre, category
Radio button User selects exactly one option from a short fixed set (2–5 options) Yes / No, Delivery / Collection
Checkbox User can tick or un-tick one or more options independently Interests, "Remember me", terms agreement
Number input User enters a numeric value, often with a min/max limit Quantity, age, rating (1–5)
Date picker User selects a date from a calendar widget Date of birth, booking date, due date
Button Triggers an action when clicked Submit, Search, Log In, Add to Cart

Output elements

Output elements display information to the user — results, confirmations, or labels that describe other elements.

Element What it displays Example
Label / heading Text that identifies or describes another element or section "Username:", "Search Results", page title
Paragraph text A longer block of text displayed to the user Error message, confirmation message, instructions
Table Data displayed in rows and columns Search results, student records, product list
Image placeholder A box (often with an ✕) marking where an image will appear Product photo, user avatar, banner
Result / calculated text Output generated by the program (calculation or database query) "Total: £24.50", "Your score: 8/10"

Annotations

Good wireframes include annotations — short notes beside each element that explain its purpose, what data it holds, validation rules, or how it behaves. For example:

  • "Dropdown — user selects from predefined list; cannot type own value"
  • "Text box — max 50 characters; must not be blank"
  • "Table — displays records returned from database query"

Annotations make a wireframe useful to the whole development team, not just the designer who created it.

Justifying element choices

In the SQA exam, you are often asked to justify why a particular input element is appropriate. A strong justification always links the element's properties back to the scenario. For example:

  • Dropdown instead of text box → "restricts input to valid options, preventing typing errors"
  • Radio buttons instead of checkboxes → "only one value can be selected at a time"
  • Date picker instead of text box → "ensures correctly formatted date input and prevents invalid dates"

The key question to ask yourself is: could the user enter invalid data with a text box that this element prevents?

Worked examples

Example 1 — Identifying elements in a wireframe

The wireframe below shows a planned login screen for a school quiz app. Identify and name the type of each UI element shown.

quiz.jghs.ac.uk/login SCHOOL QUIZ APP Username: Password: ● ● ● ● ● ● Log In Forgot password?
Fig 1 — Login form wireframe for a school quiz app
1
The "SCHOOL QUIZ APP" bar at the top is an output element — a label / heading. It displays the app name; the user cannot interact with it.
2
The grey placeholder box below it represents the login card heading (another label — e.g. "Login" or "Welcome back"). In a wireframe, placeholder text is shown as a grey bar.
3
The "Username" field is a text box (input element) — the user types a single line of text (their username).
4
The "Password" field is also a text box (input element). The circles (●●●●●●) indicate the text will be masked — a standard behaviour for password fields.
5
The filled rectangle "Log In" is a button (input element) — clicking it submits the form and triggers the login action.
6
"Forgot password?" is a hyperlink (output/navigation element) — it displays a clickable link that takes the user to a password reset page.
Example 2 — Planning inputs and outputs for a cinema booking form

Scenario: A cinema booking website needs a page where users can select a film, choose a date, pick a seat type (Standard, Premium, or Accessible), enter their email address, and confirm their booking.

1
Film selection → Dropdown list. There is a fixed number of films currently showing. A dropdown restricts the user to valid films only — typing would risk misspellings or films that aren't available.
2
Date selection → Date picker. This ensures a correctly formatted date and only shows available screening dates. A text box would allow the user to type an invalid date.
3
Seat type → Radio buttons. There are exactly three options and the user must choose exactly one. Radio buttons enforce single-selection from a short, visible list — ideal for 2–5 options.
4
Email address → Text box. Email is a short, free-format text value. A text box is appropriate here because there is no fixed list to choose from.
5
Submit → Button ("Book Now"). Buttons trigger actions. The user clicks "Book Now" to submit the completed form.
6
Output — confirmation message: after booking, a paragraph of text displays the booking reference and summary.
CITY CINEMA · Book a Ticket Film: ▼ dropdown list Screening date: 📅 date picker Seat type: Standard Premium Accessible radio buttons Email address: text box Book Now button
Fig 2 — Cinema booking form wireframe with element annotations
Example 3 — Exam-style justification of element choice

Question: A music streaming app has a "Search" page. Justify why a dropdown list is more suitable than a text box for selecting a music genre to browse.

1
State what a dropdown does: a dropdown list restricts the user to a predefined set of valid genre options (e.g. "Pop", "Rock", "Jazz"). The user selects from the list — they cannot type their own value.
2
State the problem with a text box: a text box would allow the user to type anything — including misspellings ("Jaz"), variations ("hip hop" vs "Hip-Hop"), or genres that don't exist in the database.
3
Link to the scenario: genre must match an existing category in the music database. A dropdown ensures only valid genres can be selected, so the search always returns results.
4
Model answer: "A dropdown list should be used because it restricts the user to valid genre options that exist in the database. This prevents errors caused by typing (such as misspellings or invalid genres) and ensures the search always finds matching results. A text box would allow any input, making it possible to search for a genre that does not exist."
Now you try

A school is building a homework tracker app. When a pupil adds a new task, they must enter:

  • The subject (from a fixed list of school subjects)
  • A description of the task (a few sentences)
  • The due date
  • The priority level — Low, Medium, or High

Answer the following:

  1. Name a suitable input element for the subject field and justify your choice.
  2. Name a suitable input element for the description field and justify your choice.
  3. Name a suitable input element for the priority level field and justify your choice.
  1. Subject → Dropdown list. The school has a fixed set of subjects (e.g. Maths, English, Science). A dropdown restricts the pupil to valid choices and prevents typing errors. It also ensures the subject name is stored consistently in the database.
  2. Description → Text area. A task description may span several sentences, so a multi-line text area is more appropriate than a single-line text box.
  3. Priority level → Radio buttons. There are exactly three options (Low, Medium, High) and the pupil must choose exactly one. Radio buttons make all three options visible at once and enforce single-selection. (A dropdown would also be acceptable with a brief justification.)
Common mistakes
✕
Confusing text box and text area. A text box is single-line — use it for short inputs like names or search terms. A text area is multi-line — use it only when the user needs to type a longer piece of text (e.g. a comment, description, or message).
✕
Using a text box when options are fixed. If the user should only be able to choose from a known list of values (e.g. countries, genres, categories), use a dropdown or radio buttons — not a text box. A text box would allow invalid input and make validation much harder.
✕
Forgetting output elements. Wireframes must show both inputs AND outputs. Common omissions are labels (needed to name every input field), result text (e.g. a total price or confirmation message), and tables (for displaying query results). A form with no labels is unusable.
✕
Drawing the finished interface instead of a wireframe. A wireframe uses grey placeholder boxes, plain text labels, and no real images or colour. Pupils sometimes produce a fully styled mockup — this is a high-fidelity prototype, not a wireframe. In an exam, a simple annotated sketch is all that is required.
✕
Weak justifications. Writing "use a dropdown because it is better" scores zero. Always link the element's properties back to the scenario: explain what problem it prevents (e.g. "restricts input to valid options, preventing misspellings") and why that matters for this program.
Exam tip

Wireframe / UI design questions typically appear as part of the Design topic in Section 1 of the question paper. Common question stems are:

  • "Identify two suitable input elements for this program." (1 mark each)
  • "Justify why [element A] is more suitable than [element B] for this field." (2 marks)
  • "Name an appropriate output element that could display the results." (1 mark)

For a 2-mark justify question, you need: (1) name the chosen element and (2) explain why it fits the scenario — specifically what problem it solves that the alternative does not. Always reference the scenario directly. A general answer about dropdowns being "easier to use" is worth 0 marks; an answer that says "restricts input to the 5 available ticket types, preventing invalid entries" is worth full marks.

Task Set

Questions 1–5 are auto-checked. Questions 6–7 are self-marked written responses. Questions 8–9 are draw.io wireframe tasks — create your diagram in draw.io, then upload or paste it below.

1. Which input element lets a user select exactly one option from a long predefined list (e.g. choosing a country)? TYPE 1

2. A registration form asks users to tick all the topics they are interested in (they can choose more than one). Which input element is most appropriate? TYPE 1

3. What type of output element is best for displaying a list of database records in rows and columns? TYPE 1

4. A booking form asks the user to enter the date of their appointment. Which input element best prevents the user from entering an invalid date? TYPE 1

5. Which statement best describes the purpose of annotations on a wireframe? TYPE 1

6. Describe two reasons why a developer creates a wireframe before writing any code. TYPE 2

Any two of:

  1. It is much faster to change a wireframe than to rewrite code — design problems can be spotted and fixed at the planning stage, saving significant development time.
  2. A wireframe communicates the planned design to clients, other developers, and teammates before implementation begins, so everyone agrees on the layout before work starts.
  3. Reviewing a wireframe helps identify usability problems early — for example, missing fields, unclear navigation, or a confusing layout — before any effort has been invested in coding.
  4. Once agreed, the wireframe serves as a blueprint during the Implementation stage, guiding the programmer on what to build.

7. A weather app is being designed. The "Search" page must allow the user to enter a location name, choose whether to see a daily or weekly forecast, and view the results. Identify three suitable UI elements for this page, giving the element type and what it is used for in each case. TYPE 2

Three from the following (element type + purpose both required for each mark):

  • Text box — for the user to type a location name (short, free-text input with no fixed list of valid values)
  • Radio buttons — to select Daily or Weekly forecast (only two fixed options; exactly one must be chosen; radio buttons make both options visible at once)
  • Button (e.g. "Search") — to submit the location and trigger the forecast lookup
  • Table or paragraph text — to display the weather forecast results (an output element showing temperature, wind speed, conditions, etc.)
  • Label — to identify the location input field or the results section

Accept dropdown for forecast type with appropriate justification.

For wireframe questions (Q8, Q9): create your wireframe in draw.io, then either (a) click Upload to select your saved PNG, or (b) in draw.io use Edit → Copy as Image (or right-click → Copy), then click Paste from clipboard. Your wireframe will appear inline and be included when you export your answers. See the draw.io Quick Guide for help.

8. Using draw.io, create a wireframe for a "Add a Book" form for a school library app. Library staff use this form to add a new book record. The form must allow the user to enter: the book title, the author's name, the genre (from a fixed list), the publication year, and save the record. Your wireframe must include at least 4 labelled input elements and a Save button. Upload or paste your completed wireframe below. TYPE 3

Your wireframe should include:

  • Text box — Book title (short free-text input)
  • Text box — Author name (short free-text input)
  • Dropdown list — Genre (fixed list of categories; prevents invalid input)
  • Number input — Publication year (numeric; could include min/max validation, e.g. 1000–2025)
  • Button — "Save" or "Add Book" (triggers the save action)
  • A heading or label for each input field
  • Optional: a success/error output message area after saving

Award yourself a mark if your wireframe is clearly low-fidelity (plain boxes, no real colour/images) and uses appropriate element types as above.

9. Using draw.io, create a wireframe for a "Quiz Results" output page for a school quiz app. The page should display: the quiz title, the pupil's total score, their grade, and a table showing each question with whether their answer was correct or incorrect. Annotate at least 3 elements on your wireframe to explain their purpose. Upload or paste your completed wireframe below. TYPE 3

Your wireframe should include:

  • Heading / label — quiz title (output element; displays the name of the quiz)
  • Result text — score display, e.g. "Score: 8 / 10" (calculated output)
  • Result text — grade display, e.g. "Grade: A" (output derived from score)
  • Table — one row per question; columns: Question number, Question text (or summary), Correct/Incorrect indicator (output showing database query results)
  • Button — optional "Try again" or "Return to menu" navigation button
  • At least 3 annotations explaining element purpose (e.g. "Table — displays one row per question from the database"; "Score text — output calculated by comparing answers"; "Heading — output showing quiz name from database")

This page is almost entirely output elements — that is appropriate because the user is viewing results, not entering data.

Teacher notes — Shift+T to hide

Suggested timing: 60 minutes. Warm up 8 min; vocabulary 5 min; notes + tables 15 min; worked examples 12 min; now you try 7 min; task set Q1–5 5 min; Q6–7 8 min. Q8–9 are draw.io tasks — best completed in a second period or as homework with draw.io open.

Key misconception to address: pupils often produce a fully styled mockup (with colour, fonts, and images) and call it a wireframe. Stress that a wireframe is deliberately low-fidelity — grey boxes, no real images, placeholder text. The value is in planning layout and element types quickly, not in visual polish.

Live demo suggestion: open draw.io and create a login wireframe together in real time. Use: Rectangle → input box; filled Rectangle → button; text label → field name; circle → radio button. Show how to add an annotation arrow using the "callout" shape. Takes about 5 minutes and immediately makes the task concrete.

draw.io tip for pupils: search "mockup" in the shape library (left panel → Search shapes) to find dedicated wireframe shapes including text boxes, buttons, dropdown arrows, and browser frames. These are faster than drawing rectangles manually.

Extension question: "A client asks for a high-fidelity prototype instead of a wireframe. What additional information does a high-fidelity prototype include, and why might a developer prefer to start with a wireframe?" (Colours, real fonts, styled images, interactive clicks — wireframes are faster to produce and cheaper to change.)

SQA command words covered: "identify" (name the element — 1 mark each), "describe" (explain what it does), "justify" (name + reason why it is better than the alternative — 2 marks).

Past paper mapping: wireframe / UI design questions appear as part of the Design topic in Section 1. Check SQA past papers from 2023 onwards — questions asking pupils to identify inputs/outputs for a described scenario are increasingly common. The 2023 exam included a question asking pupils to name suitable input elements for a described program.

  • Assignment relevance: SDD Assignment Task 1 requires evidence of Design (25 marks). A wireframe is accepted as UI design evidence alongside a structure diagram or flowchart. Q8 and Q9 are deliberate practice for producing assignment-quality wireframes.