Level 1 HCI external · Task 10

Studied-Interface Evidence Bank — Know One Interface Well

Students choose an interface worth studying, observe it through repeatable task flows, separate evidence from assumption, and build examples they can later recall and reason with.

Duration65 minutes

GroupingIndividual · peer quality check

PreparationInterface + back-up

OutputSix records + two plans

Student choice Repeat observation Evidence status Closed-book recall

Assessment-facing purpose: the 2026 specification says candidates will study an interface of their own choice before the assessment. This lesson makes that study deliberate. The organiser is a learning tool, not promised examination material: students must not assume they may take it into the external.

Learning Intentions

Select an interface with enough complexity and repeatable evidence for useful analysis.
Observe complete user tasks before assigning usability principles.
Distinguish what was observed, what is documented and what remains assumed.
Build evidence that connects a feature to usability, interface purpose, comparison and improvement.

Success Criteria

I have at least six specific evidence records drawn from two or more task flows.
Each record names a user and task, not an abstract “user experience”.
My explanations show how the feature changes success, effort, error, access or confidence.
My comparison is like-for-like, and my improvement answers an evidenced limitation.
I use Mātāpono Māori only when the interface evidence genuinely supports that lens.

Before Class

Set the choice boundary

Ask students to arrive with one interface they know and one back-up. A website, app, game, software tool, kiosk or device interface may work; a single poster, passive video or one-screen splash page usually will not.

Protect privacy and access

Use test or public content where possible. Students should not expose private messages, account details, other people’s data or paid content. A task must be safe to repeat without making unwanted purchases, posts or changes.

Prepare a fallback

Have one public, teacher-approved interface available for students whose first choice fails the gate or cannot be accessed. The student still chooses whether to use that fallback or another suitable interface.

Keep notes unavailable at first

The opening retrieval is closed-book. Students reconstruct the analytical chain and principle families before seeing the organiser, so the evidence bank supports memory rather than replacing it.

Selection Gate: Is This Interface Worth Studying?

An interface passes only when the student can answer every gate with specific evidence. If access, scope or privacy is uncertain, move to the back-up choice quickly.

Complex enough

It has several states or screens and decisions that affect how a person completes a task.

Repeatable access

The student can revisit and safely repeat important actions rather than relying on memory of a one-off event.

Clear purpose and users

The student can state what the interface is for, who uses it and what success looks like.

At least two task flows

There are two end-to-end actions to observe, such as find-and-select, create-and-edit, or configure-and-recover.

Strengths and limitations

The choice is not being treated as either perfect or terrible; both effective decisions and friction can be investigated.

Evidence across principles

Several usability principles may be tested against what happens. No feature needs to be forced into every principle family.

No compulsory Mātāpono label: lack of evidence for a Mātāpono Māori analysis does not make an interface unsuitable. “Not evidenced here” is more defensible than translating an ordinary HCI feature into a Māori concept after the fact.

Observation Protocol

1. Frame

Name the interface purpose, a real user and one complete task before opening the principle list.

2. Run

Complete the task once naturally, then repeat it slowly from the same starting state.

3. Record

Write exactly what appeared or happened. Separate the observable feature from your interpretation.

4. Pressure-test

Vary one condition safely: error state, input method, text size, connection, route or user need.

5. Label status

Mark each claim observed, documented or assumed. Record where documented evidence came from.

6. Explain

Link feature → user/task → principle → effect on usability → effect on purpose.

7. Compare

Use the same task or outcome when comparing states, routes or interfaces.

8. Improve

Propose one change that addresses the evidenced limitation and acknowledge a trade-off.

Evidence-status rule: observed means directly seen or repeated; documented means supported by a named help page, design note or other source; assumed means plausible but not yet verified. An assumption can guide the next test, but it cannot be presented as an observed fact.

Lesson Sequence

Time	Phase	Activity	Teacher quality check
0–7	Closed-book retrieval	With notes and devices closed, students reconstruct the analytical chain, list principle families they remember and explain the difference between a feature and evidence for a principle. Pair-check, then reveal the organiser.	Listen for user/task and purpose. A list of definitions alone is not sufficient retrieval.
7–15	Selection gate	Students test their first and back-up choices against all six gates. They write the interface purpose, primary user and two task flows before receiving approval to continue.	Reject one-screen, inaccessible, unsafe or purely remembered choices. Approve a specific scope, not an entire ecosystem.
15–23	Model and status check	Model the fictional RouteLab record below. Colour-code or annotate what was observed, documented and assumed. Show why an ordinary HCI lens is more precise when Māori context is absent.	Students can tell evidence from interpretation and can explain why “not evidenced” is a valid finding.
23–38	Task flow one	Students run one task naturally, reset, then repeat it slowly. They complete records 1–3, including one strength, one limitation and evidence status for every claim.	Feature wording is observable: “a message remains for eight seconds”, not “the app is intuitive”.
38–50	Task flow two	Students repeat the protocol with a second end-to-end task or a meaningful changed condition. They complete records 4–6 and add one like-for-like comparison.	The second flow adds new evidence. It is not three paraphrases of the same button.
50–58	Evidence audit	Partners audit each other’s bank: underline evidence, box assumptions, challenge forced labels, and test whether each effect reaches the interface purpose. Students revise statuses and one proposed improvement.	Improvement targets a demonstrated limitation and names a likely benefit and trade-off.
58–65	Response plans and recall	Students build two response plans using different evidence combinations. Then they close the organiser and orally retrieve their three strongest examples, including one limitation.	Students can recall evidence without the sheet. Re-state that the organiser must not be assumed available in the external.

The Evidence-Bank Fields

Observable feature · user/task

Describe what the interface does in a named state, then identify who is completing which action and in what relevant context.

Principle · evidence

Name the most precise lens and point to the particular words, states, sequence, control, cue or behaviour that supports it.

Effect on usability · effect on purpose

Explain the mechanism first, then why the change in success, effort, error, access or confidence matters to what the interface exists to do.

Counterargument/limitation

Name a boundary, missing test, trade-off or plausible alternative explanation. Do not use a generic “however” sentence.

Comparison · improvement

Compare the same action or outcome, then propose a specific change that answers the evidence rather than personal taste.

Evidence status

Mark every key claim observed, documented or assumed. A documented design intention is not automatically proof of successful use.

Reasoned Model: Fictional RouteLab Interface

Kaiako model — fictional interface, not a product claim

RouteLab is a fictional journey planner created for this lesson. A traveller compares routes, saves one, and can reverse the save from a message that remains visible for eight seconds.

Feature, user and evidence

Observable feature: after “Save trip” is selected, the interface displays “Trip saved” and an “Undo” action for eight seconds. User/task: a commuter saving the correct route for later. Principle: visibility of system status and user control and freedom. Evidence: the confirmation appears after the action; selecting Undo returns the route to its unsaved state on a repeat test.

Effect, pressure test and judgement

Effect on usability: feedback removes uncertainty, while Undo reduces the cost of a mistaken save. Effect on purpose: the traveller is more likely to leave with the intended journey stored. Counterargument/limitation: eight seconds may be too brief for some users, and the visible message does not prove assistive technology announces it. Comparison: this gives clearer confirmation and recovery than changing an icon with no message. Improvement: keep Undo available in the saved-trips view and test that the status is announced to assistive technology. Evidence status: the visible message and repeatable Undo are observed; any assistive-technology behaviour remains assumed until tested or documented.

Should this record be labelled rangatiratanga because the user can undo?

Better explained by ordinary HCI evidence

The observed feature gives a generic user an escape from an unwanted state. No Māori authority holder, object of authority, or decision about tikanga, mātauranga or te reo Māori is evidenced. A Mātāpono Māori label would add association, not explanatory power, so user control and freedom is the more precise lens here.

Kaiako Quality Checks

Choice: the interface passes every selection gate and has a named back-up if access fails.
Coverage: six records draw on at least two task flows and include strengths as well as limitations.
Evidence: observations are concrete; documentation is named; assumptions are visibly labelled.
Reasoning: each principle is linked through a mechanism to the named user/task and interface purpose.
Precision: ordinary HCI and Mātāpono Māori are not treated as interchangeable labels.
Evaluation: comparison is like-for-like; improvement responds to evidence and acknowledges a boundary or trade-off.
Recall: the student can retrieve three strong examples and one limitation with the organiser closed.

Student Resource

Task 10 — Studied-Interface Evidence Organiser

A clean printable selection gate, observation protocol, six-record evidence bank, comparison/improvement audit and two response plans. It contains no model answers.

Open printable organiser →

Transition to Task 11

Photograph or save the completed organiser only if school privacy rules allow it.
Ask students to memorise relationships, not scripts: feature → mechanism → user effect → purpose.
Group the next lesson by the weakest link: evidence selection, explanation, comparison or judgement.
Carry the studied interface into timed unfamiliar-resource and studied-interface practice without promising access to notes.

New Zealand Qualifications Authority. Level 1 Digital Technologies 2026 Assessment Specifications, p. 2.
New Zealand Qualifications Authority. Demonstrate understanding of usability in human-computer interfaces, version 2.