User Experience Design: From User Stories to Prototypes

A user is someone who uses a product directly. Think about finding a club on a phone. The screen matters, but so do the time it takes and whether joining feels clear.

The interface and the experience

UI is part of UX. Beautiful buttons cannot fix a journey that leaves students unsure whether they joined. Useful, clear, quick, and pleasant all describe parts of the experience.

Follow a cycle

In user-centered design, real users' needs, abilities, goals, and situations guide decisions throughout the project. The designer involves users early and keeps learning from them.

1. Understand the users and their needs.
2. Define the problem and write requirements.
3. Generate ideas and choose one to develop.
4. Plan screens, journeys, and structure.
5. Build a prototype that users can try.
6. Test it with suitable users.
7. Improve it using the findings.

A school might call these activities "investigate, plan, create, evaluate." The names can differ while the work stays the same. This process suits apps, websites, games, kiosks, and other interactive products, which respond to people's actions.

Let testing change the plan

Suppose students cannot find ClubFinder's Join button. The team returns to the screen sketch, moves the button, updates the prototype, and tests again. This repeating process is iterative. One round is an iteration.

Testing can send the team further back. If students need to see a club's finishing time before joining, the team may need to change a requirement. The stages help organize the work; they do not lock the team into its first decisions.

A rough sketch makes early changes cheap. Moving a drawn button takes little effort. In a finished app, the change may need programming, checks, and an update. Early testing finds problems before that work grows.

Look behind a request

A student asks for "a giant red banner about sign-ups." Ask what problem the banner would solve. The student keeps missing deadlines. A reminder might solve that need without taking over the screen. Users describe the problem; designers compare ways to solve it.

A designer may think, "It works for me, so it works." The designer already knows every screen. New students do not. Watch people who match the intended users and have not learned the design. Their actions give evidence that personal taste cannot supply.

ClubFinder affects more people than the students tapping Join. A design team needs to know who those people are and what matters to them.

Identify the people involved

A stakeholder affects the product, is affected by it, or has an interest in it. Users are stakeholders. The client is the person or organization the product is made for. The target audience is the main group it is designed for; an end user uses the finished product.

For ClubFinder, students aged about 11 to 14 are primary users. Club leaders are secondary users: they post details and check lists. Parents need pickup information. The school office is the client and wants fewer paper forms. The design team also has an interest in the result.

Needs can differ. Students want quick joining, parents want a message, and the office wants accurate lists. One design can support all three: joining updates the list and sends the linked parent a notification.

Choose a way to learn

Ask neutral questions about real events. "Tell me about the last club you joined" invites an account. "Wouldn't an app make this easier?" pushes an answer. Open questions invite detail. Closed questions, including yes/no or ratings, help count responses.

Turn findings into a profile

Record three kinds of finding:

• A need states what someone must be able to do or have.
• A pain point describes a frustration in the current task.
• The context of use describes the place, time, device, and abilities involved.

For example, students check information on phones at lunch. A paper list in the office means some miss sign-ups. The need is access to club information when they can act on it.

A user profile, or persona, brings findings into a short picture of a typical user. Maya is 12, uses a phone, wants to join a friend's club, and finds long text tiring because she has dyslexia. These details help the team choose readable screens. A profile must reflect research; inventing a convenient user gives the team false evidence.

Include a range of users, devices, languages, internet access, and abilities. A student using a screen reader may meet barriers that a teammate never notices.

Handle people's information carefully

Explain the purpose, ask permission, allow skipped questions, and collect only needed information. In shared results, replace names with labels and remove identifying details. "Student A" still identifies someone if a photo or rare personal detail gives them away. Store notes and recordings safely, with extra care for young people's information.

Research findings need to become clear goals for the design. A user story describes one thing someone wants to do, from that person's point of view.

Write who, what, and why

The usual shape is: "As a [type of user], I want [goal] so that [reason]."

For ClubFinder: "As a student, I want to see Tuesday clubs so that I can find one that fits my schedule."

• Who: a student.
• What: see the clubs meeting on Tuesday.
• Why: choose a club that fits the schedule.

The reason helps designers make choices. A day filter helps, but the student also needs meeting times to decide whether a club fits.

Different users need different stories. A club leader wants the sign-up list to plan supplies. A parent wants a joining message to arrange pickup. Giving each role a story helps the team see needs that a student-only list would miss.

Keep the goal small and clear

"As a user, I want the app to be good" gives no clear action. Name the role and a goal the team can design and test. For example: "As a new student, I want to find and join a club in under a minute so that I can finish before lunch ends."

One story should focus on one goal. A long story about finding clubs, chatting, posting photos, and arranging pickup hides several different needs. Split it so each goal can be checked.

A story about "a blue button in the top corner" fixes the screen too early. Ask what the button helps someone achieve. Joining quickly is a user goal; button color and position are design choices to test later.

Decide what counts as done

Acceptance criteria are checkable conditions for completing a story. All its criteria must hold. For the Tuesday-club story, write:

1. The club list offers a day filter.
2. Choosing Tuesday shows only clubs meeting that day.
3. Choosing a day with no clubs shows a clear empty-result message.

A useful format is "Given [situation], when [action], then [result]." For example: "Given the club list is open, when Tuesday is selected, then only Tuesday clubs appear."

The empty-result criterion matters. A blank screen could mean no clubs, a failed search, or a broken app. A message lets the student understand the result and try another day.

Keep the connection to the finding

A story should trace back to something learned from users. It then leads to requirements, screens, and user flows. Later, the same goal becomes a realistic task for a tester.

Leaving out the reason weakens that chain. "I want a list" gives little help choosing its contents. "I want a list so I can find a club before my bus leaves" makes the meeting time and a quick path useful design decisions.

A problem statement says who needs help, what they need, and why it matters. ClubFinder's problem is that students miss clubs because joining happens on paper lists in the office.

A design brief describes the wider project. It may include the problem, audience, goals, requirements, limits, and deadline. The problem statement is one part of that picture.

Separate actions from qualities

A requirement states something the product must do or a quality it must have.

Joining a club and closing sign-ups are functions. Working on Android and iPhone phones is a compatibility condition. Clear contrast is an accessibility quality. Using the school logo and colors is an appearance condition.

Non-functional does not mean optional. A product can offer every feature and still fail because it loads slowly or cannot be used with a screen reader.

Replace vague words with checks

"Fast and easy" leaves the team guessing. Ask what evidence would let someone judge the requirement.

• "The club list loads in under 2 seconds on school Wi-Fi."
• "At least 4 of 5 test users can join a club within 1 minute without help."
• "All text has a contrast ratio of at least 4.5:1."

Keep every condition during testing. The joining check needs enough users, the time limit, and no help. A quick average alone cannot show that four people met it.

One story can lead to several requirements. A parent needs a joining message to arrange pickup. The app must send the message to the linked parent and include the club name, day, and finishing time. Those describe behavior. Arrival within 5 minutes describes speed, so it is non-functional.

Work within limits

A constraint limits the possible design. Time, cost, tools, team skills, available devices, and school rules all count. "Finish in 3 weeks using a free tool" sets a deadline and a tool-cost limit. List constraints beside the requirements.

Together, requirements and constraints form design criteria, also called success criteria or a design specification. They are the checks used to judge the design later.

Decide what comes first

MoSCoW sorts requirements into four priorities:

• Must have: without it the product fails, such as joining a club.
• Should have: important, such as a day filter.
• Could have: a useful extra, such as club photos.
• Won't have this time: left for a later round, such as member chat.

The last group records a decision about this round. It keeps a limited project from growing every time someone suggests another feature.

The first workable idea is a starting point. Generating alternatives gives a team something useful to compare before it invests in detailed screens.

Make ideas before judging them

First diverge: produce different possibilities. Then converge: compare and choose. Mixing these too early can stop useful ideas before anyone understands them.

During brainstorming, hold back criticism, record every idea, welcome unusual suggestions, and build on other people's ideas. Keep one conversation at a time. A short time limit, such as 10 minutes, helps the group stay focused.

Other ways to begin include:

• A mind map, with the problem in the center and branches for ideas.
• Crazy 8s, with eight sketches in eight minutes, one per panel.
• A question such as "How might we help students notice deadlines?"
• Reviewing existing products for helpful patterns and problems.

Quick sketches support thinking. Boxes, labels, and arrows can explain an idea without polished artwork.

Make the alternatives meaningfully different

For ClubFinder, the team could try a phone list, an interest quiz, a hallway kiosk, or a weekly text message. These change how students reach the goal. Changing only the color of one screen gives much less to compare.

Show rough ideas to users and stakeholders. Ask what they understand and what would help their task. Their reactions can support scores and reveal useful parts to combine.

Compare against the same criteria

A decision matrix gives each idea a score for each criterion. Use the same scale throughout, such as 1 for poor and 5 for strong.

For A, add the four scores:

If meeting the must-have stories counts double, multiply that score before adding:

The weighted totals are 23 for A, 19 for B, and 13 for C. Weighting changes how much a criterion contributes; it does not change the evidence behind its score.

Explain the decision

A has the highest score, but check how those scores were chosen. A score of 5 based on a teammate's guess is weaker than one supported by user feedback and a working sketch.

The chosen design can combine useful features. The team could keep A's club list and later add B's discovery quiz. Extra features still need a reason: adding more can bury the main task. Record why the chosen idea meets the criteria and what the team learned from the alternatives.

A wireframe is a simple plan of one screen. It shows the parts, their positions, and their rough sizes. Like a building's floor plan, it helps people discuss the arrangement before choosing the finish.

Use simple drawing conventions

Draw rectangles for content areas and buttons. A crossed box can stand for an image or video. Lines can stand for paragraphs, but headings, menu items, and buttons need real words so others know their purpose.

Add annotations: short notes with arrows explaining behavior. A note might say, "Tap Join to open a confirmation." A box labeled "button" tells the reader much less.

Each screen needs its title, content, navigation, inputs, action buttons, and media positions. Keep shared parts in consistent places.

Sketch the ClubFinder details screen

Start with the information a student needs before deciding to join. Arrange it from top to bottom:

1. A back arrow and the title "Chess Club."
2. A photo placeholder.
3. Day, time, room, and club leader.
4. "Spaces left: 4 of 12."
5. A large "Join club" button.
6. Bottom navigation: Home, Search, and My Clubs.

The title identifies the club. Time and room support the decision. The button offers the next action. Add the note, "When full, show Join waiting list." This explains a different state of the screen.

Make the screen fit its device

List the content and actions first. Try two or three rough arrangements, choose one, and annotate it. Draw a phone screen in the shape users will hold. Put important actions within comfortable reach.

For a website, sketch a narrow phone view and a wider computer view. A responsive design rearranges content to fit the available width. A row of cards might become a vertical list. The purpose stays the same even when positions change.

Know what each kind of model shows

Fidelity means the level of detail and closeness to the planned product. More detail takes longer to change. Early decoration can turn a useful layout discussion into a color discussion.

Check for missing states as well as missing screens. An empty search needs a message and a way to try again. A club details screen needs a route back. Unlabeled boxes, crowded content, and missing navigation make the plan hard to judge.

Finally, compare the drawings with the requirements. If students must filter by day, show where that happens. This catches gaps before the team starts linking screens.

A screen plan cannot show everything about a person's task. Storyboards add the real-life situation. User flows show the route through the product.

Draw the person's story

A UX storyboard is a sequence of panels, like a short comic. Show the problem, the setting, the person's actions, and the result. Short captions explain what changes.

Maya's ClubFinder storyboard could show six moments:

1. At lunch, Maya hears her friend joined Art Club.
2. She opens ClubFinder on her phone.
3. She searches for "art."
4. She sees Wednesday, 3:30 to 4:30 p.m., with 2 spaces left.
5. She joins and sees "You're in!"
6. Her parent receives the pickup time, and Maya feels relieved.

The storyboard shows why time matters and who needs the final message. It focuses on the person, setting, and feelings, not only on button positions.

In interactive media, storyboard can also mean annotated plans of each screen. These show content, media, colors, fonts, and link destinations. Ask which kind of storyboard a project needs: the user in a situation, or the detailed screen plans.

Map one task through screens

A user-flow diagram uses boxes for screens and labeled arrows for actions. A diamond can show a decision with separate routes.

For joining Chess Club, the main route is:

• Home → tap Search → Search.
• Search → type "chess" and tap the result → Club details.
• Club details → tap Join club → Confirm message.
• Confirm message → tap Yes → "You're in!"
• "You're in!" → tap My Clubs → My Clubs.

The route to "You're in!" uses four taps plus typing. Labels explain what makes each move happen; arrows alone leave that unclear.

Include the branches

At "Spaces left?", one branch leads to joining and another to a waiting list. Add a route for Cancel and for a search with no results. These are ordinary parts of the task, not details to leave until the end.

A dead end is a screen with no useful route out. A flow can also reveal too many steps, loops, or a missing action. If My Clubs shows a joined club but no way to leave, the team can add that route before building.

User stories give each flow its purpose. The flow tells the team which wireframes are needed. Its arrows become prototype links, and its goal later becomes a test task. A storyboard helps check that the whole journey still makes sense in the user's real situation.

Information architecture is the way content is grouped, named, and arranged. Navigation is the set of controls people use to move through it. Clear organization and clear routes work together.

Show the whole structure

A site map, also called a structure chart, shows the product's pages and connections. It often looks like a tree.

ClubFinder has Home at the top. It leads to Clubs, My Clubs, Messages, and Settings. Clubs offers clubs by day and by type, both leading to club details. This gives the team a view of the whole product.

A site map can show many possible routes. A flow follows one goal through that structure.

Choose a useful structure

A linear structure moves through pages in order using Next and Back. It suits a tutorial or a step-by-step sign-up form.

A hierarchical structure groups pages into categories and smaller categories. It suits larger amounts of information.

A non-linear structure links pages in many directions. It allows flexible exploration but needs clear signs to help people stay oriented.

Many products use a hybrid. ClubFinder can have a hierarchy of club types and a linear joining process inside it.

Use names people understand

Students looking for clubs are unlikely to search for "extracurricular enrichment programs." Use their word, "Clubs." Group content around user tasks and expectations.

Check confusing overlap. If menus offer both "Sports" and "Games," someone may not know where Chess Club belongs. Clearer labels or another way to find it can help. Search by name and filters by day or type provide extra routes through a long list.

Balance breadth, the number of choices together, with depth, the number of levels. A huge menu is hard to scan. Many nested levels mean repeated taps. Phone apps commonly offer three to five main sections in a bottom bar, with more choices inside.

Answer three navigation questions

On the Chess Club screen, a title answers "Where am I?" The bottom bar answers "Where can I go?" A back arrow answers "How do I get back?" A highlighted current tab or a breadcrumb such as "Home > Clubs > Chess Club" can also show location.

The idea that every page must be within three clicks is a myth. Clear progress matters more than a fixed click count. A longer route can work when each choice is understandable and leads toward the goal.

Consistency means that things doing the same job look and behave in the same way. It helps users carry what they learn from one screen to the next.

Keep shared parts predictable

Internal consistency is consistency within one product. Use "Join" for the same action everywhere. Keep the back arrow in a shared place. Different screens can have different content while their common controls stay familiar.

External consistency follows conventions from other products. A magnifying glass suggests search, an X suggests close, and a linked logo often returns home. Breaking a familiar pattern can make people stop and guess.

A style guide records shared design choices: color codes, fonts, sizes, buttons, icons, spacing, logo use, and writing tone. ClubFinder might specify dark blue #1A5FB4 buttons with white text, headings at 24 pt, and body text at 16 pt. A writing rule could say, "Use you and short, friendly sentences."

Templates and reusable parts help apply these rules. A change to shared navigation should not need a separate guess on every screen.

Show what happened

Feedback is the response after an action. A button can darken when tapped. A spinner can show waiting. "Step 2 of 3" shows progress. "You joined Chess Club" confirms success. Sound and vibration can add feedback too.

Give feedback promptly. When an action needs time, show that work is happening. Otherwise users may tap again or leave. Keep the current state visible: highlight the current tab, show "Joined ✓" for joined clubs, and display remaining spaces.

Make errors useful

A useful error message explains the problem and the next step in plain words. Place it near the problem and avoid blaming the user.

"Invalid input" gives little help. "This club is full. Tap Join waiting list to hear when a place opens" explains both the situation and an available action.

The wording must match what the product can do. A message offering a waiting list needs a working route to that list.

Prevent mistakes as well as explaining them

Disable or hide joining for a club already joined. Ask for confirmation before a hard-to-undo action: "Leave Chess Club?" with Yes and Cancel. Offer Undo where possible. A confirmation should name the action so users know what they are agreeing to.

To review a set of screens, compare the same action across them. If two screens say "Join" and a third says "Sign up," choose one term. If one back arrow moves to the opposite side, restore the shared position.

Feedback is needed after success too. Without a joining confirmation, the student may repeat the action because the result is unclear.

Accessibility helps people with disabilities perceive, understand, navigate, and use a product. Inclusive design considers the wider range of users, languages, devices, ages, and situations.

Plan for different ways of using a screen

Needs may involve vision, hearing, movement, attention, or learning. A limit may be permanent, such as blindness; temporary, such as a broken arm; or situational, such as bright sunlight. Captions help deaf viewers and people watching somewhere noisy.

Assistive technology includes screen readers, magnifiers, switches, voice control, and braille displays. A screen reader reads content and control labels aloud. An unlabeled icon leaves its action unclear.

Give meaningful images useful alternative text, or alt text. A club photo could say, "Two students playing chess in Room 12." An icon-only search button needs the accessible name "Search." Mark decoration so screen readers skip it. Use captions for video and a transcript for audio. Keep essential details, such as the room, in readable text too.

Check text contrast

A contrast ratio compares the lightness of text and background. It ranges from 1:1 to 21:1. Under WCAG level AA, normal text needs at least 4.5:1. Large text needs at least 3:1; large means 18 pt or more, or 14 pt bold or more.

On white, gray #767676 gives about 4.5:1 and passes for normal text. Lighter #999999 gives about 2.8:1 and fails. A contrast checker calculates the ratio from the two color codes.

Never use color as the only signal. Red for full and green for open leaves some users unable to tell the status. Add "Full" or another clear non-color cue.

Make text and controls usable

Use readable text that can enlarge, clear headings, short paragraphs, and everyday words. "Ask a parent or guardian to say yes before you join" is easier to use than a long formal permission sentence.

WCAG 2.2 AA sets a pointer-target minimum of 24 by 24 CSS pixels, with exceptions including sufficient spacing and links within text. Apple's iPhone and iPad guidance recommends 44 by 44 points; Google's Material guidance recommends 48 by 48 density-independent pixels. These are different measurement units and guides. Leave space between controls.

Every control needs keyboard access in a sensible order. A visible focus indicator shows which control responds to the next key press. Give each form field a visible label; hint text inside the field disappears during typing.

Check a ClubFinder screen

Add missing alt text. Write "Full" beside its color signal. Enlarge a 30-by-20-pixel Join control for the chosen target size. Darken #AAAAAA hint text, which has only about 2.3:1 contrast on white. Add the meeting room as text if it appears only in a photo. Put these checks in requirements and tests at the start of the project.

A prototype is an early model for trying out an idea. Its purpose is to answer questions before the real product is built. It needs enough detail for those questions, not every feature of the finished product.

Start with paper when it helps

A paper prototype uses hand-drawn screens. A tester points to a button. One teammate plays the computer and swaps in the next screen; another records what happens.

Paper is quick, cheap, and easy to change. Its roughness can make people more willing to criticize it. It suits questions such as "Do students understand these club categories?"

Paper cannot show real loading speed, animation, or the feel of a control on an actual phone. Choose a different model when those details are what you need to learn.

Link digital screens

A clickable prototype connects screens with hotspots: areas that respond to a tap or click. A hotspot over Join could open a confirmation panel.

The model simulates behavior. It does not need a working database or a programmed sign-up system. A search may show a prepared result, and joining may save nothing. Tell testers which parts are simulated before they try the task. This keeps their findings about the design within what the model can show.

Fidelity describes how closely the model represents the planned product. A detailed clickable model may include realistic words, images, colors, and responses. Clickable models can also stay visually rough.

Choose tools by what they let you do

No-code tools use drawing, dragging, and linking without programming. Low-code tools allow some code or settings for extra behavior. Interface-design tools with prototype modes, such as Figma or Penpot, and presentation tools with hyperlinks can support simple models. App builders may also offer design views.

Name the needed behavior first: separate screens, working links, and preview on the test device. Then choose an available tool that supports it.

Match effort to the learning goal

To test one-thumb reach, use a clickable model on a real phone. To compare early menu labels, paper may answer the question sooner.

High fidelity is not always better. Polish takes time, may shift comments toward colors, and can make testers reluctant to criticize. A prototype is a learning tool. The team can replace or discard it after learning what the next design needs.

A clickable prototype turns planned screens and flows into actions a tester can try. Build from a clear screen list so a key route is not left unfinished.

Set up screens and shared parts

1. List the screens needed by the user flows.
2. Make a frame or artboard for each screen at the target-device size. In presentation software, use one slide per screen.
3. Add the wireframe's shapes, text, and media placeholders.
4. Make repeated parts, such as the navigation bar, reusable.
5. Add and link hotspots, then set the start screen.

A component is a reusable element whose copies update when the original changes. It helps keep shared controls consistent. Use realistic club names, times, and space counts where testers must decide. "Club 1" and "Club 2" hide information they need.

Define what each action does

An interaction connects a trigger, such as a tap, to an action, such as opening a screen. A transition is the animation between screens. An overlay is a panel above the current screen, such as a confirmation.

Important phone actions cannot depend on hover: touch screens have no hover action. Give users a way to reach the information by touch.

Build the ClubFinder joining route

Link Home's search control to Search. Link the "Chess Club" result to Club details. On that screen, Join opens an overlay reading "Join Chess Club?" with Yes and Cancel.

• Yes opens "You're in!"
• Cancel closes the overlay and returns to Club details.
• My Clubs on the success screen opens the student's club list.

Add working back and bottom-navigation links on each main screen. The visible button and its hotspot should line up. A small or misplaced hotspot can make a good-looking control fail.

In a slide tool, place a linked shape over the button and send it to the correct slide. Turn off click-anywhere advance so only planned links move the model. PowerPoint offers this through its "Browsed at a kiosk" slideshow setting.

Preview before user testing

Click through every branch in preview mode. Start at the chosen opening screen, complete each must-have story, try Cancel, go back, and try an empty result. Compare the paths with the user flows and requirements.

A teammate can catch links the builder missed. A link to the wrong screen, a dead end, or a Cancel button with no response needs repair before the session. Every visible button should respond; an unfinished feature can show "Not available in this prototype."

Share the link and try it on the real device. Save named copies, such as v1 and v2, before changing a tested version. Keeping versions makes later comparisons possible.

A usability test watches target users complete realistic tasks with a prototype. The test checks the design. A person getting stuck is evidence of a design problem, not a failure by the tester.

Plan what you need to learn

Write a goal such as "Can new students join a club quickly?" Choose testers who match those students. Designers and teammates already know the routes. A small group, often about five people, can reveal common problems, followed by another round after fixes.

The plan names the goal, testers, tasks, device, place, measures, and roles. The facilitator guides the session. The note taker records results and useful comments.

Give a goal without the route

Turn a user story into a task scenario. For example: "You want to join a club meeting on Tuesdays. Find one and sign up."

"Tap Search, then tap Join" gives away the route. It prevents the team from seeing whether someone can discover those controls. A task scenario describes what to achieve without using button wording to guide each step.

In think-aloud testing, the tester says what they are thinking while working. "I'm looking for the days" helps explain a pause. Let the tester explore. Ask a neutral question such as "What would you try now?" Avoid defending the screen or showing where to tap.

Give help only when the tester cannot continue, and record it. An assisted completion is useful evidence, but it is different from completing alone.

Record actions and comments

For every task, record:

• Completion without help, with help, or not at all.
• Time taken.
• Wrong taps, long pauses, and where they happened.
• Useful words from the tester.

A note such as "Tester 3 searched the top for 40 seconds, then gave up" is more useful than "Tester 3 was confused." Add the person's words: "I can't see where the days are."

After the task, collect opinions with a rating and an open question. "How easy was joining? 1 = very hard; 5 = very easy" gives a countable response. "What was most confusing?" invites detail. Thank the person when finished.

Protect the tester and the evidence

Explain the purpose, ask permission, and get a parent or guardian's permission when needed. People can stop at any time. Use tester labels, remove identifying details from shared notes, blur faces in recordings, and store records safely.

Client, classmate, and stakeholder comments can add useful views. Watching target users do the task gives stronger evidence of usability than "Do you like it?" A friendly rating does not show whether the person found the route alone.

An evaluation judges the design using evidence and the design criteria. Organize the results before drawing conclusions, so a strong rating does not hide a failed task.

Keep the records together

ClubFinder's Tuesday-club task produced these results:

Three of five completed without help: 60%. Including help, four completed: 80%. These answer different questions, so label the figures clearly.

For the three unaided completions, calculate the mean time:

The average is 55 seconds. The mean rating uses all five ratings:

A tester who gave up has no completion time. Keep that failed task visible instead of treating its time as zero.

Check every part of a criterion

The criterion is "At least 4 of 5 users join within 1 minute without help." Tester 2 was unaided but too slow. Tester 4 finished with help and took too long. Only Testers 1 and 5 meet both conditions. The criterion is not met.

A 55-second average does not establish this criterion. It describes the unaided completers as a group and hides the individual cutoff.

Use met, partly met, or not met with evidence. Body text at 7.0:1 and hint text at 2.8:1 partly meet an all-text contrast requirement of 4.5:1. Successful task completion on both tested Android and iPhone devices supports compatibility for those devices. Merely running a test supplies no passing result.

Find the problems and their severity

Count repeated observations. Three testers looked for the day filter at the top, though it sat at the bottom. That suggests a placement problem.

Severity describes how serious a problem is: high stops the task, medium slows or confuses users who still succeed, and low is a minor annoyance. The filter issue is high because one tester gave up.

Separate observation from interpretation. "Three looked at the top" is observed. "They expected filters there" is an interpretation supported by behavior and comments. One person's wish for purple is taste; one person blocked by a control is still a usability concern.

Judge fitness for purpose

Fitness for purpose is how well the design meets the need it was made for. Combine criterion results and user feedback. Keep strengths too: all five found the meeting time immediately.

An iteration is one round of designing, prototyping, testing, and changing. Each round should respond to evidence and leave a clear record of what improved.

Link a problem to a change

Three ClubFinder testers could not find the day filter. They looked near the top of the list. The likely cause is that the filter is below where they expect it. Move it below the search bar, then test whether students find it more easily.

The chain is problem, likely cause, change, and expected result. "Move it because I prefer it there" gives no connection to the observed difficulty.

Compare impact and effort

One simple impact score multiplies severity by the number of affected testers. Use high = 3, medium = 2, and low = 1.

The high-severity filter problem affects three testers:

An unclear confirmation confuses two testers at medium severity:

Then estimate effort. Moving a filter changes one screen; rewriting the message takes a minute. Both are low effort, so the higher-impact filter fix goes first. A big change needing much more work may wait when a quick fix solves most of the immediate problem. Personal color preferences do not get a usability severity score.

Keep a change log

Save each tested version. In the change log, record the version, change, and supporting evidence. For example: "v2: moved day filter to the top because 3 of 5 testers missed it; changed Are you sure? to Join Chess Club? because 2 testers did not know what they were confirming."

Avoid changing every screen at once. Keep what already works and choose changes that address the need behind comments. Some findings may require revisiting a user story or requirement, not just moving a control.

Retest the same task

Use the same tasks and measures to compare versions. New suitable testers are ideal because previous testers may remember the old routes. Retesting also catches problems caused by a change.

In ClubFinder v2, five new testers join without help in 30, 42, 35, 48, and 35 seconds. Their mean is:

All five are within a minute without help. The criterion requiring at least four of five is now met. The individual results establish that; the 38-second mean adds a useful summary.

Stop when the criteria are met and remaining problems are minor, or when constraints end the project. Record unfinished improvements and one lesson for next time, such as testing on paper earlier. The final prototype, requirements, and test evidence support the team building the real product.