What the client and the people who actually use a solution say and do about it, gathered on purpose through questions, interviews and watching them use it.
User feedback is only useful when it is allowed to be negative, and most people will not volunteer criticism to the person who made the thing.
Friends, family and classmates protect your feelings, which is kind and useless for criterion D.
The wording of your question decides the answer, so "do you like it?" reliably produces "yes".
Say out loud that you are hunting for problems and that finding one helps you, because permission changes what people say.
Ask people outside your friend group where you can, including at least one person in the same situation as the client.
Questions That Make Honesty Easy
An open question starts with what, how or when, and it produces sentences instead of a yes or a no.
Avoid leading questions, since "how much easier is the new layout?" has already told the person what to think.
Tie each question to a specification point, so "how long did it take you to find the timetable?" beats "is the website good?".
Mix in closed questions and rating scales when you need numbers to compare, such as comfort rated 1 to 5.
Ask for one thing they would change, because people will criticise a future version when they will not criticise this one.
Keep it to six questions or fewer, since a long form gets rushed answers near the end.
Example
Weak: "Do you think the app is easy to use?"
Better: "Show me how you would book a badminton court, and say what you are thinking as you go."
Then: "What stopped you the first time you tried?"
The Client and the Users Answer Different Questions
The client is the person who asked for the solution and owns the need, so they judge it against the brief and the specification.
The users are the people who handle it day to day, and they find the things the client never notices.
A form tutor might approve a classroom storage box that the Year 7 students cannot lift off the shelf.
Ask the client about fitness for purpose, size, cost and whether they would genuinely use it next term.
Ask users about the moment of use: gripping it, reading it, carrying it, finding the button.
Record both and say plainly when they disagree, because a disagreement is itself a finding.
Watching Beats Asking
Observation means handing someone a task and staying quiet while they do it, writing down what happens.
People report their own confusion badly, but you can see them pause, turn the box over, or tap the wrong corner twice.
Count what you can see: seconds to finish, wrong turns, times they asked for help, times they gave up.
Think aloud testing asks the user to narrate what they are trying, which shows why they went the wrong way.
Do not rescue them the moment they struggle, since the struggle is the data you came for.
Film or photograph the session if you have permission, and note in your folder that permission was given.
Common Mistake
Asking three friends and calling it user testing is the weakest evidence in most design folders.
Always get permission before filming or quoting someone, and identify people by role or first name only.
Recording Feedback So It Counts as Evidence
Write answers down during the session in the person's own words, since a summary written that evening loses the sharp bits.
Keep a simple table of who, their role, the date, the question and the answer.
Quote the strongest lines directly in your evaluation, for example "I could not tell which end opened".
Attribute each quotation to a role rather than a full name, such as "Year 9 user 3" or "the client".
Keep the blank questionnaire or interview script in your folder, because the questions prove how the data was gathered.
Activity
Give your prototype and one task to someone who has never seen it, and time them without speaking.
Write down every pause longer than five seconds and what they were looking at.
Afterwards ask only two questions: what were you expecting, and what would you change.
Turning Comments Into Findings
Group similar comments together, so four separate mentions of a stiff lid become one finding with four sources.
Count how many people raised each problem, since 5 of 6 users is a pattern and 1 of 6 is a note to keep an eye on.
Separate the problem from the fix the user suggested, because users are good at spotting the first and often wrong about the second.
Rank the findings by how badly they block a specification point, not by how loudly they were said.
Carry the ranked findings into your improvements section, where each one turns into a specific change.
Active recall
Rewrite "Do you like my design?" as two questions that could produce useful criticism.
What is a leading question, and why does it ruin your data?
Name two things you can count while watching someone use a solution.
Why do client feedback and user feedback need to be recorded separately?
One user says the handle should be red. What is the problem here, and what is the suggested fix?