Learn UI design by translating a brief into a consistent set of screens, including the states people see when something goes wrong. Start with hierarchy and layout, then define reusable controls, colour roles, and typography. Your practice project is a fictional community workshop booking interface. The finished work should explain what a person can do, what happens next, and how the design remains readable on a narrow screen.
Read the brief as a set of tasks
The workshop visitor needs to choose a session, see its date and remaining seats, enter contact details, and review a booking confirmation. Do not begin by choosing fashionable gradients. List the information needed at each decision and identify the main action. On the session page, the date and booking action matter more than a decorative photograph.
Sketch three screens in plain shapes: session list, booking form, and confirmation. Add an unavailable-session state. Use realistic fictional content, including a long workshop title and a two-line venue name. Short placeholder labels can hide spacing problems that appear immediately when real text arrives.
Build a small visual system
Choose a limited type scale for page titles, section headings, body copy, and supporting labels. Define spacing steps and apply them consistently. Name colours by purpose, such as text, surface, action, and error, rather than only by their hex values. W3C’s designing tips address contrast, identifiable controls, and consistent navigation Source 1. Use those principles to assess decisions, not simply to decorate a checklist.
Create reusable button, input, card, and message components. The GOV.UK Design System demonstrates documented components and their usage guidance Source 2. Study how a component includes behaviour and content expectations, then design your own fictional workshop system. Reusing a component should keep a booking button recognisable across screens while allowing its label to match the action.
Give controls default, focus, error, and unavailable states. A keyboard focus indicator is a functional part of the design, not an optional stylistic flourish. Do not use a pale grey label to carry essential instructions. Check colour contrast using a suitable tool and record the tested foreground and background pairs.
Work through the booking example
Create a session called “Repair a desk lamp safely” with eight fictional seats remaining. The form asks for a name and email address, with a clear explanation of how booking updates will be delivered. Use visible labels rather than relying on placeholder text. W3C’s forms tutorial covers labels, instructions, and feedback Source 3.
Design an invalid-email state that identifies the field and explains the correction. Preserve the name already entered. A successful confirmation should state the session, date, booking reference, and what the visitor should do next. Label all contact details and references in the portfolio as fictional so the mockup cannot be mistaken for a real booking service.
Now change the remaining-seat count to zero. Replace the booking action with an honest unavailable message and a way back to other sessions. Do not leave a bright button that only reveals the problem after the form is completed. This exercise shows how interface consistency must coexist with clear changes in state.
Review the interface at different sizes
Arrange the screens at a wide desktop size and a narrow mobile size. Keep the reading order and main task intact as columns stack. Test a long email address, a long title, and an error message that wraps. If the design depends on every label fitting one line, revise the component rather than shrinking all text.
Ask a peer to identify the session date, start the booking, recover from the email error, and explain the confirmation. Record confusion in their words. A polished screen is not proof that those tasks are clear. Your final case study should include the brief, component sheet, key states, mobile layouts, and two changes made after review.
For the next learning step, implement a small part in HTML or collaborate with a developer. Compare the live control with the drawing, especially focus, wrapping, and validation. UI design becomes more reliable when you understand which visual choices imply behaviour and implementation requirements.
- TaskList decisions and necessary information.
- SystemDefine type, spacing, colour roles, and components.
- StatesDesign default, error, focus, and unavailable cases.
- ReviewObserve tasks and revise the unclear parts.
| Checkpoint | What to produce | How to review it |
|---|---|---|
| Hierarchy | Date and primary action are easy to locate | Peer identifies them without hints |
| Components | Buttons, inputs, cards, messages | Same role behaves consistently |
| Errors | Invalid email with preserved name | Correction is clear and local |
| Responsive layout | Narrow-screen booking flow | Long content wraps without overlap |
- Visual consistency
- Shared spacing and type create recognisable structure.
- Behavioural consistency
- The same control role produces predictable actions.
- Content clarity
- Labels say what happens rather than merely “Continue”.
Common questions
Should I master a design tool before starting?
Learn enough to create frames, text, reusable components, and simple connections, then start the project. Tool fluency improves through purposeful work. Spending weeks on shortcuts without testing a booking flow can postpone the more important skills of hierarchy, content clarity, state design, and explaining your choices.
How many fonts should a beginner interface use?
One readable family with a small, consistent hierarchy is enough for this exercise. Add another only when it serves a clear purpose and remains manageable. Check real body text, labels, and numbers at their intended sizes. A striking heading font cannot compensate for difficult form labels or weak supporting text.
Do I need to design error states?
Yes, because the booking task includes mistakes and recovery. Show where the problem occurred, explain how to correct it, and preserve valid input. A portfolio containing only perfect-path screens leaves important behaviour unspecified. Error states also reveal whether your component spacing and text hierarchy can handle longer messages.
Is a greyed-out button enough for a full session?
Usually it does not explain the situation by itself. State that the session is full and offer a relevant next action, such as returning to available sessions. Ensure the explanation is readable. The design should help the visitor understand what happened rather than forcing them to infer meaning from a colour change.
How should I choose spacing values?
Start with a small set of repeatable spacing steps and apply them according to grouping. Related labels and fields should feel connected; separate sections need more space. Test the result with real content. The exact numbers matter less than a clear rationale and consistency that survives desktop and narrow-screen layouts.
Can I claim my mockup is accessible?
You can describe specific accessibility decisions and checks, such as contrast, visible labels, and focus-state design. A static mockup cannot demonstrate every behaviour of a functioning interface. Be precise about what was tested and what remains for implementation and assistive-technology review rather than making a blanket accessibility claim.
What should I show in the component sheet?
Show each control’s purpose, text style, spacing, and important states. Include examples with long content and errors, not just attractive defaults. Add a short usage note explaining when the component belongs in the booking flow. This makes the sheet a practical handoff reference rather than a decorative collection of boxes.
How is this different from UX research?
This roadmap focuses on the interface’s visual and interactive expression. UX research investigates people’s needs, behaviours, and difficulties using suitable methods. The two inform each other: observed confusion can change hierarchy or labels, while a prototype provides something concrete to investigate. Do not substitute attractive screens for evidence about user needs.
Continue your learning
UX Research Learning Roadmap: Plan, Run and Summarise a Small Study. Wireframing Roadmap: Turn a User Task into Clear Screen Layouts.
Sources and further reading
- W3C: designing tips — Contrast, control identification and navigation considerations.
- GOV.UK components — Reusable component documentation and usage examples.
- W3C: forms — Visible labels, instructions and feedback.
Skills & Learning Desk
MP Job Hub’s organisational byline for sequenced practice, course evaluation and useful learning habits.
Skill roadmaps · Learning resources · Practice projects
View profile →Read our research process or request a correction.
