Validation Guide

User testing answers one question: does your product actually work for the people you built it for? This guide gives you a simple recipe to follow, then explains each step in more detail below.

---

Watch first — assessment walkthrough

---

The recipe — five steps, every session

This is the core loop. Follow it every time you test. Aim for at least 5 sessions total across Weeks 5–8.

Step 1 — Find one person to test with

They should match your target user. A classmate who would genuinely use your product is fine. Someone from outside your team is better.

You need at least 5 participants in total for the Validation Report. Book them early — do not leave all sessions to Week 8.

Step 2 — Prepare 3 tasks (not questions)

A task asks them to do something, not say something.

Good task	Avoid
”Imagine you want to split a dinner bill. Show me what you would do."	"Do you like our app?"
"Find where to add a new expense."	"Is this design clear?"
"Check whether your friend paid you back."	"Would you use this?”

Write the tasks down before the session. Three tasks is enough.

Step 3 — Run the session (20 minutes)

Opening (2 min):

“Thanks for helping. We’re testing our design — not testing you. There are no wrong answers. Please think out loud as you go.”

During (15 min):

• Give them one task at a time
• Do not help them — if they get stuck, that is the data
• Write down: what they try first, where they pause, what they say, what they skip

After (3 min):

“Was anything confusing? What did you expect to happen when [thing that failed]? Would you actually use this?”

Step 4 — Write up what you found (10 minutes after the session)

Write one short paragraph per session. Include:

• What they struggled with (specific, not vague)
• One direct quote if you have one
• One thing that surprised you

Store it in your team’s shared folder with a date and participant number (not name).

Step 5 — Change something, then document it

Pick one thing they struggled with. Change it. Write in your Dev Log:

• What you found (participant quote or observation)
• What you changed
• Why that change should help

That is one complete iteration. Repeat.

---

What gets a better grade

The Validation Report is 10% of your module grade. Here is what moves your score up or down:

What you do	Lower score	Higher score
Participants	Fewer than 5 total	5+ with varied backgrounds
Evidence quality	”Users liked it” / “some had issues”	Direct quotes and specific observations
Iteration	”We improved the design"	"P3 couldn’t find delete → we moved it → P5 found it immediately”
Before/after	Changes described without evidence	Screenshots or notes showing the change
Documentation timing	Written at the end from memory	Notes taken during or right after each session
Appendix links	Missing or broken	Working links to transcripts, notes, or recordings

The most common reason for a low score: building for weeks, testing once at the end, and writing it up from memory. Test early. Document as you go.

---

Why this is assessed

The module assesses process over technology. Your Validation Report is built entirely from the evidence you collect here. Teams who test early and often, and who change their product based on what they learn, score significantly higher than teams who build for weeks and test once at the end.

The core mindset shift:

Before: “We think users will want this feature.” After: “We tested with 5 users and found that 3 of them couldn’t find the feature. We moved it to the main screen and tested again.”

---

Which stage are you in?

The type of testing changes as your product matures.

Week	What to test	What you are finding out
3–4	The problem (interviews)	Does the problem actually exist for real people?
5	The concept (sketch or Figma)	Do people understand what you are building?
5–6	Early prototype (partial working feature)	Can users complete the core task?
7–8	Working product	Where do users still get stuck before Demo Day?

---

Deeper guide — each stage explained

Stage 1 — Problem Validation (Weeks 3–4)

Purpose: Confirm that the problem you defined in your Project Brief is real — before you spend weeks building a solution.

If your team completed any validation in Week 3 (user conversations, survey reuse, competitive benchmarking, secondary research), your Stage 1 is done. Document it in your Week 3 Dev Log entry and move to Stage 2.

If you skipped validation in Week 3, do it now. Talk to 3–5 people who match your target user. You are not showing them a product — you are checking whether they genuinely experience the problem.

Good interview questions are open (not yes/no) and backward-looking (about real past experiences):

Good	Avoid
”Tell me about the last time you experienced [the problem]."	"Would you use an app that solved this?"
"What do you currently do when [the situation] happens?"	"Do you think this is a common problem?"
"Walk me through what happened — what did you do first?"	"Do you like this idea?”

People are unreliable predictors of their future behaviour. They are much more reliable reporters of past experiences.

Interview design prompt

“I am designing a user interview for a [type of product]. My target user is [description]. Write me 8 open-ended interview questions that explore whether they actually experience [the problem], without asking them whether they would use my product.”

Other options if interviews are hard to arrange:

• Competitive benchmark — find 3–5 existing products. Read their reviews. What do users consistently complain about? That gap is your opportunity.
• Secondary research — find evidence the problem exists: forum posts, Weibo, Xiaohongshu, market reports. Two or three credible sources confirming the problem is enough.
• Reuse ENT207TC research — if your team validated a problem last semester, reuse it. Document it in your Dev Log as evidence.

---

Stage 2 — Concept Testing (Week 5)

Purpose: Check whether your proposed solution makes sense to users before you spend weeks building it.

Show people your idea — a Figma prototype or paper sketches work. You are answering: “Do users understand what this product does, and do they want it?”

1. Show the interface without explaining anything
2. Ask: “What do you think this is? What would you do first?”
3. Observe — do not correct them or fill in gaps
4. After they explore, ask: “What is confusing? What is missing?”

The most common mistake in concept testing

Explaining your product before showing it. “So this is an expense-splitting app, and what you would do is…” — you have just removed all the information the test would have given you. Show first. Explain only after.

---

Stage 3 — Usability Testing (Weeks 5–8)

This is the main testing stage. Use the five-step recipe at the top of this page. Focus on watching — not explaining or defending.

What counts as a finding:

• Something a user tried that didn’t match your design
• A feature they expected that doesn’t exist
• A label or button they misread
• Something they didn’t notice at all

Sample sizes

• Weeks 5–6: 3–5 users per round is enough to find major problems
• Target: 5+ documented sessions total for the Validation Report

Consent and ethical practice

• Tell participants: “We are testing the product, not testing you. There are no wrong answers.”
• Ask permission to take notes or record (voice or screen)
• Do not use photos of participants without permission
• Keep notes and recordings confidential — use participant numbers, not names

---

Stage 4 — Iterating Based on Evidence

Testing is only valuable if you change something because of it. For each round, document all four:

1. What you tested — which feature, which users, which tasks
2. What you found — specific quotes and observations
3. What you changed — the exact change made
4. Why — connect the change back to the finding

Example Dev Log iteration entry

“Week 6 testing (3 users): All 3 tried to swipe left to delete — delete is currently only in a settings menu. We moved delete to a swipe gesture. Week 7 retest (2 users): both found it immediately with no guidance.”

---

Documenting for the Validation Report

Your Validation Report (Week 11, 10% of module) is built from evidence collected during Weeks 5–8. Keep records as you go — do not try to reconstruct them at the end.

⬇ Download Validation Report template — save a copy to your team folder now. Fill in the cover page. Add session notes as you go.

Section	What to include
Research Methodology	Who you recruited, how many, your session protocol
Key Findings	Findings by theme — direct quotes and observations, not summaries
Iteration History	What changed after each test round — before/after comparisons
Evidence Appendix	Links to notes, transcripts, recordings — must be accessible

Stay organised from Week 5

Create one shared folder (Google Drive or OneDrive) labelled User Research. Every note and recording gets a file named with a date and participant number (not name). You will thank yourself in Week 11.

---

Resources

Resource	Notes
Product Development Glossary	Definitions for validation, iteration, user story, etc.
Development Guide	Sprint structure, Kanban, Dev Log template
Assessment Brief	Validation Report rubric (Section 5.7.3)