Sri Krishnadevaraya University: How to Run a Usability Test With Five Classmates

You can run a useful usability test with five classmates in about three hours of sessions, using a fixed script, a shared observer sheet and a simple severity scale. Five people will not give you statistics, but they will reliably expose the biggest problems in a flow, which is exactly what an early product decision needs. This guide gives you the full kit and shows how to compress the whole exercise into a 14-day internship.

What a Guerrilla Usability Test Is, and What Five Sessions Can and Cannot Tell You

A guerrilla usability test is a short, informal session where you watch a real person try to complete a task with your product, prototype or even a paper sketch. You do not need a lab, a budget or a recruitment agency. A classroom corridor, a library table or a quiet corner of a hostel common room is enough.

Five participants is a long-standing rule of thumb in usability practice: the first few sessions reveal most of the serious, repeated problems, and later sessions mostly repeat what you have already seen. Treat it as a practical guide rather than a law. It works best when:

• you are testing one flow (for example, “book a library seat” or “apply for a hostel room”), not a whole product;
• your participants resemble the real users of the product;
• you fix problems and retest, instead of running one big test and stopping.

What five sessions cannot tell you: how many people in total will struggle, which design people will prefer in a market, or whether anyone will pay. Usability testing answers “can people use this?”, not “do people want this?”. Keep that distinction clear in your report.

Choosing the Product, the Task and the Five Participants

Pick something small enough to test in 20 minutes

Good test subjects for a student include a clickable Figma or Canva prototype, a college club’s registration form, a campus-services mobile page, a small app you built, or a competitor’s app you want to analyse. Avoid testing a product so large that no one can finish a task in one sitting.

Write tasks as goals, not instructions

A task must describe what the person wants, not which buttons to press. Compare these:

• Weak: “Click the Menu icon and choose Fee Receipts.”
• Strong: “You need a copy of last semester’s fee receipt for a scholarship form. Show me how you would get it.”

Recruit five people who fit the user profile

Classmates are convenient, but they are also friendly and may know you built the thing. Reduce that bias by choosing people who have not seen the design, by mixing confident and less confident phone users, and by asking one or two juniors or friends from another department if the product is meant for all students. Note each person’s relevant background on the observer sheet so you can spot patterns later.

The Test Script: Word-for-Word Facilitator Guide for a 20-Minute Session

Use the same script with every participant. Consistency is what makes five sessions comparable. Read the opening aloud; it protects the participant and sets expectations.

Opening (3 minutes)

1. “Thanks for helping. We are testing the product, not you. You cannot do anything wrong.”
2. “Please think aloud: say what you are looking at, what you expect, and what confuses you.”
3. “I may not answer questions during the tasks, because I want to see what you would do on your own. I will answer afterwards.”
4. “Is it okay if my teammate takes notes? We will not record your face or share your name.” (Ask for explicit permission before any screen or audio recording.)
5. “You can stop at any time.”

Warm-up questions (2 minutes)

• “How do you usually handle [the activity] today?”
• “Which apps or sites do you use for it?”

Tasks (10 minutes, two or three tasks)

Hand over the device or prototype and read each task card aloud. Prompts to use when the participant goes quiet or stalls:

• “What are you thinking right now?”
• “What did you expect to happen?”
• “What would you do next?”

Do not point, hint or say “try the top right.” If a person is stuck for more than three minutes, say, “Let’s move on to the next task,” and record the task as failed.

Wrap-up (5 minutes)

• “What was the easiest part? What was the most frustrating part?”
• “If you could change one thing, what would it be?”
• “On a scale of 1 to 5, how easy was this overall?” (1 = very hard, 5 = very easy)

Thank them, and note anything they said after you stopped recording, because candid comments often arrive at the door.

The Observer Sheet: A Ready-to-Copy Template for Note-Takers

One person facilitates; another observes. The observer never speaks during tasks. Use one sheet per participant, then merge them. Here is the table structure to copy into a spreadsheet or a notebook page.

Keep observations and interpretations apart. “She tapped Profile twice looking for receipts” is an observation. “The navigation is bad” is an interpretation, and belongs in a different column or a later step.

A Severity-Rating Scale for Usability Problems, from 0 to 4

A scale stops the team arguing about whose favourite problem matters most. Rate each issue on impact, then adjust for how many of the five people hit it.

A simple adjustment rule: if three or more of five participants hit the same issue, raise its priority by one level when ordering your list. A 2 that hits four people usually deserves attention before a 3 that hit one.

Illustrative Example: Scoring Five Sessions on a Hostel-Room Request Form

The following is an invented example to show the method, not real data. Suppose a student builds a prototype form for requesting a hostel room change. The task is: “You want to move to a room closer to your department. Submit a request.”

The wrong-block choice is rated 4 because a mistaken request could mislead the warden’s office. The button problem hit three of five, so it ranks first by reach even though its severity is 3. The order of work becomes: fix the dropdown labels, move the button, change the placeholder style, ignore the colour comment. That ranking, with evidence, is what a product manager brings to a team.

Turning Raw Notes Into a One-Page Findings Summary

Nobody reads a ten-page report from a student project. A one-page summary respects the reader and forces you to decide what matters. Build it in this order:

1. Test overview (3 lines): what was tested, the tasks, number and profile of participants, date, test format (prototype or live).
2. Headline result: one sentence, such as “Three of five completed the request unaided; two failed at block selection.”
3. Task success table: one row per task with completed, completed with hint, failed counts.
4. Top three to five issues: each with severity, how many people hit it, a short quote and a proposed fix.
5. What worked: one or two things to keep. This shows balance and protects good design from being “fixed”.
6. Next steps and open questions: what you will change, what you will retest, and what this test could not answer.

Write issues as problem, evidence, recommendation. For example: “Block names use codes. 2 of 5 chose the wrong block. P5: ‘I think A1 is near my department?’ Recommend labelling blocks by building name.” Avoid vague words such as “confusing” without saying who was confused and where.

Bias Traps in Friendly Classmate Sessions and How to Control Them

• Leading questions: ask “What did you expect here?” not “Was that button clear?”
• Rescuing: the urge to help is strong when a friend struggles. Silence is data.
• Defending the design: if you built it, let a teammate facilitate and stay quiet yourself.
• Politeness bias: friends say “it’s fine.” Judge by behaviour and completion, not by compliments.
• Over-reading one voice: a single comment is a lead, not a finding. Look for repeats across participants.

Sri Krishnadevaraya University Students: Fitting a Usability Test Into Your Own Coursework and Projects

No official Sri Krishnadevaraya University page was verified for this article, so nothing here claims what the university’s curriculum, internship rules or project requirements say. What can be said is that a usability test is a self-contained exercise that does not depend on any particular university scheme. It needs only a product to test, five willing people and a few hours, which suits students at a state university in Anantapur whether they study computer science, management or another subject.

Where it can matter is in how you present the work. If you want it to appear in a mini-project, a seminar, a department presentation or a portfolio, the rules for that are set by your department or college, and you should not assume them. Participants from your own campus also have practical advantages: they share your timetable, can meet between classes and are the real users of many campus-facing products.

Before you plan, settle these points in writing:

1. Ask your project guide or class coordinator whether a usability study can count toward a mini-project, report or presentation, and in what format.
2. Ask the department office whether any consent or ethics procedure applies when you involve other students as participants.
3. Check the current syllabus or scheme document on the university’s official website, or ask your department for a copy, to see which project or internship rules apply to your programme and year.
4. If you plan to test a campus service (hostel, library, exams), ask the relevant office for permission before using its name or screenshots.
5. Confirm with the training and placement cell, if your college has one, whether it accepts a one-page study summary as supporting material for internship records.

A 14-Day Plan for Running and Reporting Your Usability Test

If you are doing this as part of a short online programme, the free two-week internship at CareerSwami is one way to structure the work over 14 days; you receive a free offer letter and, after successful completion, a free completion certificate. The plan below fits that window, and it works equally well on your own.

Frequently Asked Questions

Is five participants really enough for a usability test?

It is enough to find the most obvious, repeated problems in a single flow, which is the purpose of a guerrilla test. It is not enough to estimate percentages or compare designs statistically. Fix the main issues and retest with a fresh small group.

Should I record the sessions?

Only with the participant’s clear permission. Notes from a dedicated observer are usually enough for a student project. If you do record, keep faces out of the frame where possible and do not share the recordings publicly.

What if a participant finishes every task easily?

That is a valid result. Check whether the tasks were too easy or too leading, and whether the person was typical of your users. If the result holds across five, report it as a strength rather than inventing problems.

How do I rate severity if my team disagrees?

Rate each issue separately, then compare. Discuss only the issues where scores differ by two or more points, and settle them by pointing to the observed behaviour: failure, hint, delay or no effect.

Can I test a paper sketch instead of a working app?

Yes. Paper or a clickable image prototype works well for early flows. The facilitator can swap pages as the participant “taps”. Findings about wording, layout and navigation carry over, though not those about speed or performance.

How do I word a task without giving away the answer?

Describe the situation and the goal, using the participant’s language, and avoid the names of buttons, menus or screens. “You want to change your room” is better than “open the Requests tab.”

What belongs on the one-page summary if I only have time for three issues?

Include the headline result, a task success table, your top three issues with severity and evidence, one thing that worked and your next step. Cut anything that does not help a reader decide what to change first.

How do I show this work in a product management portfolio?

Present the one-page summary, a sanitised observer sheet, the severity table and any before-and-after screens. Describe what you changed because of the test. Remove participant names and any private information.