My progress
Menu

UI/UX Product Designer · Focus area 2: Journeys and information architecture

UX5: Sketches, wireframes and forms

Goal: explore ideas quickly with sketches, turn the best into wireframes with a clear hierarchy, lay screens out for phones first, design forms that people complete without mistakes, and improve designs through critique.

You'll need: UX1 to UX4, Module 13 (Forms and Inputs), Module 15 (Page Layouts), Module 16 (Responsive Websites), paper and a pen, and the SehatSlot practice kit.

Where this is used: before anyone builds or polishes a screen, designers try several layouts on paper, pick the strongest, and draw it in grey boxes so the team can agree on content and order. Most of the design decisions that matter are made at this stage.

How it differs: high-fidelity design (UX6, UX8) decides how things look. Wireframes deliberately leave out colour and style, so people discuss structure, priority and content instead of taste.

Time: reading about 2 hours · practice (the Try it tasks) about 3 hours · assignment about 3 hours.

Lessons

  1. 1Sketching many ideasReading 15–25 minutes, plus practice✓
  2. 2Wireframes and visual hierarchyReading 15–25 minutes, plus practice✓
  3. 3Mobile-first and responsive layoutReading 15–25 minutes, plus practice✓
  4. 4Forms that people completeReading 15–25 minutes, plus practice✓
  5. 5Critique and iterationReading 15–25 minutes, plus practice✓

🛠️Assignment: Wireframe SehatSlot's booking journey

  1. Sketch at least three different ideas for choosing a time and pick one using the problem statement.
  2. Wireframe the four screens (search, choose a time, details, confirmation) with real content and annotations.
  3. Check the wireframes at 320 pixels wide, and note the content order on a phone.
  4. Design the details form: fields, labels, hints, input types, error messages and the error summary.
  5. Get feedback from one person using the critique format, and write a change log for your next version.

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

How do you go from a problem to a layout that works on a phone?

Show a good answer

A good answer mentions: sketching several truly different ideas and choosing with the problem statement; wireframes with real content, one primary action and a clear hierarchy; mobile-first layouts that reflow at 320 pixels; forms with visible labels, the right input types, accepted formats, worded errors with a summary and kept input; and critique tied to goals, leading to tested iterations recorded in a change log.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. A designer sketches three versions of a time list in different colours. What's the main problem?

Why each option is right or wrong

  • “Three sketches are too many for one screen, and a single sketch is enough” (Incorrect): More ideas are better at this stage, as long as they differ.
  • “Sketches should be in black and white only, not in colour” (Incorrect): Colour in a sketch isn't the issue; sameness is.
  • “The sketches should be drawn in a design tool, not by hand” (Incorrect): Hand sketches are quicker for exploring.
  • “They're variations of one idea, not genuinely different solutions” is correct.

    Going wide means different approaches, such as a calendar, a next-available card or a call-back.

    • Method: Crazy 8s.
    • Then: score against the problem statement.

📖 Revise: Lesson 1: Sketching many ideas

Question ID sp-ui-ux-05-q1 · Report a mistake in this question
2. A wireframe has three bold buttons at the bottom: "Continue", "Save" and "Share". What would improve it?

Why each option is right or wrong

  • “Make all three buttons larger, so they're easier for people to tap” (Incorrect): Larger buttons still compete for attention.
  • “Add a fourth button labelled "Help" with the same style as the others” (Incorrect): More competing buttons make the choice harder.
  • “Colour each button differently, so people can tell them apart” (Incorrect): Different colours don't say which matters most.
  • “Keep one primary button and make the others secondary or links” is correct.

    A single main action makes the next step obvious.

    • Primary: the action most people need.
    • Check: what people notice first.

📖 Revise: Lesson 2: Wireframes and visual hierarchy

Question ID sp-ui-ux-05-q2 · Report a mistake in this question
3. A booking page needs sideways scrolling at 320 pixels wide. What's the likely cause?

Why each option is right or wrong

  • “The text is too short for such a narrow screen width” (Incorrect): Short text fits more easily, not less.
  • “The phone's browser doesn't support websites at that width” (Incorrect): Browsers support it; the layout is the problem.
  • “There are too few breakpoints in the design for phones and tablets” (Incorrect): More breakpoints don't fix a fixed-width element.
  • “A fixed-width element on the page that is wider than the screen” is correct.

    Fixed pixel widths don't shrink, so the page overflows on narrow screens.

    • Fix: max-width and flexible grids.
    • Kit: test 8 checks every page.

📖 Revise: Lesson 3: Mobile-first and responsive layout

Question ID sp-ui-ux-05-q3 · Report a mistake in this question
4. Why does the accessibility checker axe report no label problem for a text box that only has a placeholder?

Why each option is right or wrong

  • “Because placeholders are a perfectly good replacement for visible labels” (Incorrect): They give the box an accessible name, but disappear while typing.
  • “Because axe only checks colour contrast and nothing else at all” (Incorrect): axe checks many rules, including labels.
  • “Because the box is optional and optional boxes don't need labels” (Incorrect): Every field needs a label.
  • “axe counts the placeholder as a name, but people still lose track of it” is correct.

    Automated tools check some rules; they don't watch people forget what a box was for.

    • Kit: test 2 checks for visible labels.
    • Research: P2 and P3 forgot which box was which.

📖 Revise: Lesson 4: Forms that people complete

Question ID sp-ui-ux-05-q4 · Report a mistake in this question
5. A patient types their phone number as "00000 54321". The form says "Invalid number". What should change?

Why each option is right or wrong

  • “Add a hint that says spaces aren't allowed in the phone number box” (Incorrect): The form should accept a reasonable format instead.
  • “Split the number into ten separate one-digit boxes for each digit” (Incorrect): That's slower and causes more mistakes.
  • “Show the error in a brighter red so that people notice it sooner” (Incorrect): The error itself shouldn't happen.
  • “Remove spaces and dashes before checking the number has 10 digits” is correct.

    People write numbers in groups; accepting that removes a needless error.

    • Then: check for 10 digits.
    • Error: "Enter your mobile number as 10 digits".

📖 Revise: Lesson 4: Forms that people complete

Question ID sp-ui-ux-05-q5 · Report a mistake in this question
6. Which piece of feedback on a design is most useful?

Why each option is right or wrong

  • “"I don't really like the grey colour of the slot boxes."” (Incorrect): Taste without a link to a goal.
  • “"Make it look more like a popular app I use every day."” (Incorrect): It doesn't say what problem that solves.
  • “"Looks good to me, ship it to the users as it is!"” (Incorrect): Encouraging, but nothing to act on.
  • “"The chosen slot barely differs from the rest, and 4 of 5 couldn't tell what they chose."” is correct.

    It names an observation, a measure and the evidence.

    • Next: a change linked to F1.
    • Then: re-test.

📖 Revise: Lesson 5: Critique and iteration

Question ID sp-ui-ux-05-q6 · Report a mistake in this question
7. Why should wireframes use real clinic names and times instead of placeholder text?

Why each option is right or wrong

  • “Clients don't like Latin text and may complain about it” (Incorrect): Possibly, but the main reason is practical.
  • “Real content makes the wireframe look like the finished design” (Incorrect): Wireframes stay grey; content is about fit and sense.
  • “Developers need real content to estimate the size of the database” (Incorrect): That's not what wireframes are for.
  • “To check that real content fits and makes sense” is correct.

    Real names, dates and times reveal layout and wording problems early.

    • Kit: data/clinics.json.
    • Example: long clinic names wrapping.

📖 Revise: Lesson 2: Wireframes and visual hierarchy

Question ID sp-ui-ux-05-q7 · Report a mistake in this question
8. A form clears every field after a failed submit. What's the main harm?

Why each option is right or wrong

  • “It shows that the form is very strict about the data it accepts” (Incorrect): Strictness isn't the issue; lost work is.
  • “The page has to load again, which uses a little mobile data” (Incorrect): Minor compared with retyping everything.
  • “It breaks the browser's back button for the rest of the session” (Incorrect): Not necessarily; the bigger harm is lost work.
  • “People retype everything and may give up or make new mistakes” is correct.

    Keeping input and marking only what's wrong respects their effort.

    • Also: an error summary with links.
    • Focus: moved to the summary.

📖 Revise: Lesson 4: Forms that people complete

Question ID sp-ui-ux-05-q8 · Report a mistake in this question
9. What is the main benefit of designing the phone layout first?

Why each option is right or wrong

  • “Phone layouts take less time to design than any other kind” (Incorrect): Not necessarily; they need careful priority decisions.
  • “Desktop users don't mind a layout that was designed for phones” (Incorrect): Larger screens still need adapting.
  • “It means the design team doesn't need to test on larger screens” (Incorrect): Every size still needs checking.
  • “It forces early decisions about what matters most on every screen” is correct.

    A small screen leaves room for only the essentials, which helps every size.

    • Kit's survey: 95 of 120 booked on a phone.
    • Then: adapt for larger screens.

📖 Revise: Lesson 3: Mobile-first and responsive layout

Question ID sp-ui-ux-05-q9 · Report a mistake in this question
10. A designer's version 5 has had no testing since version 1. What's the risk?

Why each option is right or wrong

  • “Version numbers above 3 confuse the developers on the team” (Incorrect): Version numbers aren't the problem.
  • “Earlier versions might be lost if they aren't saved in time” (Incorrect): Saving is good practice, but the bigger risk is untested changes.
  • “The design might look dated compared with competitors' apps” (Incorrect): Looks aren't the main risk.
  • “The changes may not fix the findings, or may cause new problems” is correct.

    Iteration means change, test, learn; without testing, changes are guesses.

    • Log: each change and the finding it answers.
    • Re-test: the important tasks.

📖 Revise: Lesson 5: Critique and iteration

Question ID sp-ui-ux-05-q10 · Report a mistake in this question

ProLearners Assist