User Feedback

When you present your prototype to real users and ask them what they think, you are collecting user feedback. Done well, user feedback is some of the most powerful evidence you can include in your assessment — the ISMG explicitly requires refinements and recommendations to be justified by user feedback. Done poorly, it is just a collection of opinions that adds nothing to your response.

This page explains how to design a feedback instrument, how to collect feedback, and — critically — how to split the raw data from your analysis so that your response earns marks.

Why user feedback matters¶

The Evaluating criterion in both IA2 and IA3 awards marks based on how well you evaluate your solution and justify refinements and recommendations. At the highest performance level, the ISMG requires:

• judgements explicitly connected to success criteria

• clear evidence from user feedback used to justify those judgements

• recommendations that logically follow from the evaluation

Raw responses from users are not evidence by themselves. The evidence is your analysis of those responses, connected back to your success criteria and used to justify a decision about your solution.

Designing your feedback instrument¶

A feedback instrument is the tool you use to collect responses — most commonly a short survey. Design it before you ask anyone for feedback, and design it around your success criteria.

Align questions to success criteria¶

Every question should target a specific criterion. If you have a success criterion such as “users can navigate between screens without prior instruction”, your survey should include a question that tests exactly that. Vague questions like “Did you enjoy using the app?” do not give you usable evidence because you cannot connect them back to a specific criterion.

Use a mix of question types¶

A good feedback instrument uses both:

• Rating scale questions — these produce numerical data that is easy to summarise. A five-point scale (1 = Strongly disagree, 5 = Strongly agree) works well. For example: “I could find the search feature without help.” These are quick to answer and easy to aggregate into averages or percentages.

• Open-ended questions — these allow users to explain their experience in their own words. For example: “Was there anything confusing or frustrating about the application? Please describe it.” These take longer to analyse but often reveal issues your rating questions did not anticipate.

Aim for no more than eight to ten questions. A survey that is too long will produce rushed, low-quality responses.

Reference the usability principles¶

For the user experience component of your evaluation, you need evidence against the usability principles — accessibility, effectiveness, safety, utility and learnability. Write at least one question that addresses each principle you intend to evaluate.

Consider who you ask¶

You should ask people who represent your target users — ideally matching the personas or user profiles in your task stimulus. Two to four testers is generally sufficient for a prototype evaluation. Ask them to use your solution to complete a realistic task before filling in the survey, rather than just looking at screenshots.

Collecting feedback¶

Give each tester time to actually use your solution. Watch how they interact with it — note where they hesitate or make errors — then have them complete the survey independently. If they fill it in while you are watching over their shoulder, they are more likely to give polite answers rather than honest ones.

Keep a record of:

• who completed the survey (name or role — not necessarily full personal details)

• when feedback was collected

• the version of the prototype they tested

This information matters because your teacher needs to be confident the feedback is authentic.

Where feedback goes in your response — and why it matters¶

This is the most important distinction to understand: the raw survey data belongs in an appendix; the analysis belongs in the body of your response.

The appendix: raw data only¶

An appendix holds supplementary material — things that support your response but are not themselves the assessed evidence. This is exactly where completed survey forms, response tables and rating summaries belong. Markers do not assess appendix content directly. It is there to show that real feedback was collected and to support the authenticity of your analysis.

Typical appendix content for user feedback:

• a copy of the survey instrument

• a table of all responses (one row per respondent, one column per question)

• rating averages and percentages if you have calculated them

The body: analysis only¶

Your analysis is the assessed evidence. It must appear in the main pages of your response, not in the appendix. Analysis means:

• summarising what the feedback revealed (e.g. “Three of four testers rated the navigation as 4 or 5 out of 5, indicating strong learnability. However, two testers noted confusion when returning to the home screen.”)

• connecting findings to your success criteria (e.g. “This finding suggests that criterion UX3 — users can navigate without instruction — was mostly met but not fully achieved.”)

• making a judgement about your solution based on that evidence

• stating a specific refinement you made or a recommendation for future development, and explaining why the feedback justified it

Without the analysis in the body, your marker cannot award marks for it, regardless of how thorough your appendix is.

A practical structure¶

A clear way to present feedback analysis in your response is a table with the following columns:

This format makes the link between evidence and judgement explicit, which is exactly what the ISMG looks for at the highest performance level.