NCEA L1 Hangarau common mistakes
NCEA L1 Hangarau · Understand the traps and how to avoid them.
The candidate describes what their digital outcome looks like or does, but never states which people it is for or what need or opportunity it addresses.
Candidates focus on making the product and treat the brief as a formality, so they assume the audience is obvious and never write it down.
What to do instead
Before building, write a short brief with three labelled parts: the intended user or stakeholder group, the specific need or opportunity, and one sentence on how the outcome responds to it. Check every later design decision against that brief.
The candidate lists the tools and steps they used (for example 'I used a spreadsheet and made a form') instead of explaining the design decisions and why they chose one option over another.
Candidates confuse a process diary with evidence of design thinking, and they are more confident describing actions than justifying choices.
What to do instead
For each key decision, write: the options considered, the criteria used, the option chosen, and the trade-off accepted. Use a simple decision table with columns for option, criteria, and reason.
The candidate produces a single design and calls it the outcome, with no evidence of testing with the intended users or acting on their feedback.
Testing feels like extra work after the product is finished, and candidates may not know how to approach potential users or how to record responses.
What to do instead
Plan two short testing rounds before the deadline. Use three to five members of the intended user group, ask task-based questions, record responses verbatim, and show one concrete change made in response to each round.
The candidate describes a digital outcome without naming or explaining the relevant concepts, for example using 'algorithm' or 'usability' as a label without showing what it means in their own outcome.
Candidates memorise terminology for tests but do not connect it to their own work, so the report uses jargon as decoration.
What to do instead
For each concept used, write one sentence defining it in plain language and one sentence showing exactly where it appears in the candidate's own outcome, with a specific example.
The candidate claims the outcome meets the brief but provides no evidence such as test results, measurements, or user comments.
Candidates assume a finished product proves success, and they do not plan for collecting evidence of fitness for purpose.
What to do instead
Build an evaluation table with one row per requirement in the brief, a column for the evidence gathered, and a column for the judgement. Cite specific test data or user statements in each row.
The candidate presents a long chronological log of every action taken rather than selecting and annotating the evidence that shows the required skills.
Candidates believe more evidence is safer, and a diary format is easy to produce, so they submit volume instead of relevance.
What to do instead
Select a small number of artefacts per skill, annotate each with what it demonstrates and why it was included, and cut anything that does not map to a specific requirement.
The candidate writes about a digital outcome in general terms without identifying the specific components, inputs, outputs, and interactions of the one they built.
Candidates describe the idea of the outcome rather than its actual structure, often because they built it by trial and error without mapping it first.
What to do instead
Draw a simple component diagram showing inputs, processing, storage, and outputs, then label each part with the actual names used in the candidate's build. Refer to these labels throughout the written work.
The candidate treats a single successful test as proof the outcome works, without testing edge cases, unusual inputs, or use by someone other than the developer.
Testing is done at the end by the person who built the outcome, so they unconsciously follow the happy path they designed.
What to do instead
Write a short test plan covering normal use, boundary values, invalid input, and a first-time user. Record expected versus actual results for each case and fix or document failures.
The candidate describes the social or ethical implication of a technology only in vague terms such as 'it could be misused' or 'it helps people', with no specific group, scenario, or trade-off identified.
Candidates have not practised reasoning about implications, so they reach for safe generalities that cannot be credited as analysis.
What to do instead
For each implication, name the affected group, describe a specific scenario, identify who benefits and who is disadvantaged, and state one measure that would reduce the harm.
The candidate leaves out consideration of the wider context, such as data privacy, accessibility, cultural appropriateness, or sustainability, when describing and evaluating their digital outcome.
Candidates concentrate on functionality and appearance, and these contextual factors are not visible in the finished product so they are easy to overlook.
What to do instead
Use a short checklist covering privacy and data handling, accessibility for users with different needs, cultural appropriateness, and sustainability of use. Address each item in the evaluation with a sentence of specific evidence.