NCEA Level 2 Technology common mistakes
NCEA Level 2 Technology · Understand the traps and how to avoid them.
Writes a brief that already names the outcome and its materials (for example, "The brief is to make a rimu phone stand for the library") instead of starting from an issue, need or opportunity and letting the attributes drive the choice of outcome.
Candidates have often decided what they will make in the first week, then write the brief to fit, copying the project-management habit of 'defining the task' rather than doing genuine brief development. This locks out alternatives and makes later evidence of exploration impossible.
What to do instead
Start with a documented issue or opportunity and stakeholder voice (interview notes, survey data, observation). Write a conceptual statement of intent plus attributes expressed as fitness-for-purpose criteria, then revise the brief after each modelling or trialling cycle to show refinement.
States attributes as bare adjectives or wish-lists ("strong", "durable", "appealing", "cheap") with no measurement, no acceptance criteria and no link back to a stakeholder need.
Everyday product language is imprecise, and candidates do not realise that the assessor needs to see how each attribute will be judged; they assume the meaning is obvious to the reader.
What to do instead
For every attribute, record who needs it, why it matters, a measurable acceptance criterion and the test that will check it (for example, "survives a 1.2 m drop onto concrete three times with no cracking" or "fits a 210 mm tablet with 5 mm clearance"). Build these into a table you carry through to evaluation.
Writes the development record as a chronological diary ("Monday: I cut the timber. Tuesday: I glued it") that says what was done but never why, and never records alternatives that were considered and rejected.
Candidates equate 'evidence of practice' with volume of activity, and a dated log is easy to produce. Justification requires having weighed options, which is harder to reconstruct afterwards.
What to do instead
Keep a decision log with four columns: decision, alternatives considered, evidence used, and reason for the choice. Include at least one rejected option per decision with the trade-off named (cost, strength, time, sustainability, manufacturability).
During brief development, identifies only the client or 'the user' and ignores the wider stakeholders affected by the outcome - the people who maintain it, those excluded by its cost or accessibility, or the community whose materials or cultural forms are used.
Candidates treat technology as a transaction between maker and buyer, and school projects usually have one obvious end user, so other perspectives are never gathered.
What to do instead
Map stakeholders broadly at the start (primary user, client, manufacturer, maintainer, community, mana whenua where relevant) and show evidence you consulted at least two of them. Record what each wanted and how the attributes changed as a result.
Skips evidence gathering and testing, then claims the final outcome 'worked really well' or 'met the brief' with no data, no test results and no comparison against the original attributes.
By the time the outcome is finished, deadlines are close and the testing planned at the start is dropped; success is judged by personal satisfaction rather than by the agreed criteria.
What to do instead
Plan the tests before making, schedule them into the production timeline, and record quantitative results in a table against each acceptance criterion. Finish with an evaluation that lists which attributes were met with evidence, which were not, and what you would change.
Uses 'modelling' as a single idea: cannot say what a specific model was for, what it actually proved, what it could not prove, and which decision it changed - for example calling a cardboard mock-up a materials test.
Candidates see every model as 'a smaller version of the thing' and have not separated functional modelling (does it work?) from prototyping (does the whole outcome perform for the user in context?), so their explanations stay descriptive.
What to do instead
For each model, record its purpose (which attribute or risk it targets), its fidelity and limitations, the evidence it produced, and the decision it informed. Practise stating clearly that a scale model shows proportions but not structural performance, and that a prototype tests performance with a user in the intended environment.
Justifies material and component selection with generic textbook properties ("steel is strong", "plywood is cheap") without comparing alternatives against the outcome's specific requirements, context of use or end-of-life.
Candidates revise material properties as isolated facts and do not connect them to the fitness-for-purpose criteria of their own outcome; comparison also requires holding two or three options open, which feels like wasted time.
What to do instead
Compare two or three candidate materials or components in a table keyed to the attributes: strength, mass, weather resistance, joining method, tooling available, cost per unit, sustainability, and availability in the workshop. Justify the final choice by naming the trade-offs accepted.
Describes a technological system as a list of parts or a straight input-to-output flow, missing the transformation, the feedback or control element, and the boundary and subsystems.
Everyday talk about 'systems' (a sound system, an IT system) names components but not purpose, so candidates reproduce a parts list and assume the sequence of steps is self-explanatory.
What to do instead
Draw a labelled diagram showing inputs, the transformation process, outputs, and feedback loops with control elements, mark the system boundary, and state the system's purpose. Explain in words what would fail or be corrected if a feedback loop were removed.
Describes technology as applied science, or assumes technological development proceeds in a straight line from scientific discovery to product, with no role for trial and error, user feedback, competition or failure.
A slogan learned earlier ('science discovers, technology applies') survives into Level 2 unchallenged, and it is an easy answer to write when the candidate cannot recall a specific case.
What to do instead
Prepare at least two named examples where technology developed knowledge or posed questions for science, and where an outcome was shaped by users, manufacturers or regulation rather than by a discovery. Explain each using two-way cause and effect, not a timeline.
Answers 'explain' and 'justify' questions with description and generic examples ("people like phones", "technology helps society"), with no named case, no specific stakeholder and no cause-and-effect linking, and ignores the context given in the question paper.
Candidates write everything they know about the topic instead of answering the specific verb, and generic examples feel safer than a specific case they might state incorrectly. Under time pressure, they also skip the resource material and any unfamiliar context.
What to do instead
For each practice question, underline the verb and the context, then structure the answer as claim, named specific evidence, and consequence for a named group. Rehearse short answers on two or three contexts you know well (for example, e-scooters or a local water-treatment plant) so specific detail is available under pressure.