Apply user-centred design and usability principles to design and evaluate a user interface, considering accessibility, user experience and the needs of the target audience

What this dot point is asking

QCAA wants you to design interfaces around the user, not the developer. You must apply user-centred design and recognised usability principles, account for accessibility, and evaluate your interface against the needs of a defined target audience. In Unit 3 a digital solution is judged partly on user experience, so a technically correct program with a confusing interface still loses marks.

The user-centred design cycle

User-centred design is iterative, not linear:

1. Understand users and context: who are they, what are their goals, what constraints (device, environment, ability) apply?
2. Specify requirements: turn user needs into concrete interface requirements.
3. Design solutions: sketch wireframes and prototypes before coding.
4. Evaluate against requirements: test with representative tasks, gather feedback, refine.

You loop until the interface meets the users' needs, then build it. Designing for yourself, or for a generic "user", is the failure mode this process exists to prevent.

Usability principles

A widely used set of heuristics gives you concrete criteria to design and evaluate against:

• Visibility of system status: the interface tells users what is happening (loading spinners, confirmation messages).
• Consistency: the same action looks and behaves the same way everywhere.
• Error prevention and recovery: stop mistakes before they happen, and make them easy to undo.
• Recognition over recall: show options rather than forcing users to remember commands.
• Feedback: every action produces a visible response.
• Aesthetic and minimalist design: remove clutter that competes with the task.

Each heuristic is a sentence you can use in an evaluation: "The Save button gives no feedback, breaking the visibility-of-status principle."

Accessibility

An accessible interface works for users with a range of abilities and is often a legal and ethical expectation. Practical measures:

• sufficient colour contrast and never colour alone to convey meaning;
• text alternatives for images;
• keyboard navigation, not mouse-only;
• readable font sizes and clear labels;
• logical reading and tab order.

The Web Content Accessibility Guidelines (WCAG) summarise this as content that is perceivable, operable, understandable and robust. Designing for accessibility usually improves usability for everyone.

Prototyping with wireframes

A wireframe is a low-fidelity layout that shows structure, placement and flow without final visuals. It is cheap to change, so you test ideas before investing in code.

Evaluating an interface

Evaluation must be evidence-based, not opinion. Methods you can cite:

• Task-based user testing: give a representative user a real task and observe where they hesitate or fail.
• Heuristic evaluation: score the interface against the usability principles above.
• Feedback against criteria: compare the result to the requirements you specified at the start.

Report findings as specific, actionable changes tied to a principle and a user need, not vague preferences.

How this appears in IA1 and IA2

The IA1 technical proposal asks you to design and justify the interface against user needs and usability principles, usually with annotated wireframes. IA2 implements and then evaluates the working interface. Markers reward a clear target-audience definition, design choices justified by named usability principles, evidence of accessibility, and an evaluation backed by user testing rather than personal preference.