DRAFT — under teacher review.

Data Collection Methods

Hamilton College · Year 12 · 2026

For C02 you must collect data using at least three different methods and explain why you chose each one. This page covers the four methods VCE Software Development recognises — what they are, when each works best, and how to use them in your SAT project.

The C2-1 rubric rewards specific, justified method choice at the 9–10 band. Picking interviews "because everyone uses interviews" will not score. Picking interviews "because I needed depth on three users' workflows that a survey couldn't capture" will.

The four methods at a glance

A strong project usually combines: 1 method for depth (interview), 1 for breadth (survey), and 1 for grounding (observation or reports).

1. Interview

When to use it. When you need depth — understanding why someone does something, what frustrates them, or what they would value most. Best for the first 1–3 stakeholders, before you know enough to design a survey.

Strengths

• Lets you ask follow-up questions and clarify confusing answers
• Captures rich detail and personal context a survey can't reach
• Adapts on the fly — you can probe an unexpected response

Weaknesses

• Slow — a serious interview is 20–45 minutes per person, plus prep and writing it up
• Your wording, body language, and tone affect what people say (interviewer bias)
• Hard to keep two interviews directly comparable

In your project

• Capture key points and direct quotes, not full transcripts. A short bulleted note file is enough.
• After each interview, write a 2-line summary of "biggest insight" and "thing I didn't expect" — these often become your strongest poster content.
• Plan 2–4 interviews, not 10. The C2-1 rubric rewards depth of analysis, not interview count.

2. Survey

When to use it. When you need breadth — to test whether something you heard in an interview is widely true, or to count preferences across a target user group.

Strengths

• Cheap and fast per response
• Reaches many people who would never agree to an interview
• Quantitative results are easy to summarise on a poster ("78% of Year 9 students said…")

Weaknesses

• People misread or skip questions you thought were clear (ambiguity = bias)
• You only get answers to the questions you asked — no follow-up
• Self-report; what people say they do is often not what they actually do

In your project

• Keep it short. 5–10 questions, max 5 minutes to complete, or response rate collapses.
• Mix closed (countable) with 1–2 open (texture) questions.
• Pilot it with 1–2 people before sending widely — you will catch ambiguous wording every time.
• Save the raw CSV export, not just a summary screenshot.

3. Observation

When to use it. When you want to know what people do, not just what they say they do — these are usually different. Especially powerful for workflows people perform so often they no longer notice the friction.

Strengths

• Captures real behaviour in context
• Catches workarounds and unspoken steps people forget to mention
• Cuts through self-report bias — what you observe happened

Weaknesses

• Time-consuming; you usually need multiple sessions to spot patterns
• People behave differently when watched (observer effect)
• You can only see external behaviour, not motivation

In your project

• Participant observation: you join in (e.g. shadow a teacher running the canteen). Non-participant: you watch from the side (e.g. observe a library queue at lunch).
• Note specific moments, not generalities. "At 12:47, a student gave up looking for the book and asked the librarian instead" beats "it took a while to find books".
• Cross-check observations against interview claims. Contradictions are gold for your poster's "explaining why" section.

4. Reports / existing data

When to use it. When you need to ground your project in real constraints — the technical environment, the regulatory environment, or population statistics that would take you months to collect yourself.

Strengths

• Free or cheap; you didn't pay to collect it
• Often covers populations or time spans you could never access yourself
• Excellent for the rubric's constraints and technical environment categories — areas students often have nothing to say about

Weaknesses

• Was collected for someone else's question, not yours — may not exactly fit
• Quality varies; you must judge the source
• Can be out of date (especially anything pre-2023)

In your project

• For technical environment: your school's IT device list, browser stats, OS versions, network policy.
• For constraints: school policy on student data, age-appropriate design code (UK ICO), accessibility guidelines (WCAG).
• For user characteristics: ABS census data, government education statistics, your school's enrolment breakdown.
• Always save the source link plus your own one-paragraph summary — examiners want to see you read it, not just cited it.

Sub-types worth knowing

• Literature review — academic papers, textbooks, OER like this wiki
• Government databases — ABS, Department of Education, ACMA
• Industry reports — Statista, Gartner, vendor white papers
• Web data — public APIs, open datasets (data.gov.au)

Choosing your mix

For C02 you must use three or more methods. A balanced mix:

The 9–10 descriptor expects you to explain why each method was chosen for its specific job — what data it would yield that the others wouldn't. Practise that explanation out loud before your C2-1 station defence.

See also

• Essential Terms — definitions of qualitative, quantitative, open-ended, close-ended, and the four method names
• Explaining vs Describing Your Data Collection — the verb ladder the C2-1 rubric uses to separate 7 from 9–10
• Context Diagram — once you have data, the entities you discovered go on this diagram
• What Is an Entity — your data sources may themselves be entities (e.g. a payment gateway, an LMS)

Adapted for VCE SD students from EDUCBA's Data Collection Methods overview, with project-specific framing for C02.