When I evaluated the HSBC UK mobile app for a university project during my MSc in User Experience Design at the University of Brighton, the part of the study that did the most work was also the shortest: four task descriptions.
Five participants worked through those tasks while thinking aloud, then filled in the System Usability Scale (SUS) questionnaire and answered a short four-question interview. The current app scored a mean SUS of 38.0. After the redesign, the same core flows scored 90.5, and all five participants completed every task.
Those numbers only mean something because the tasks were realistic, neutral and repeatable. This guide covers how I write usability test tasks, using that study as the worked example, and ends with the checklist I run before any session. (It was an MSc project, not work for HSBC.)
What a usability test task is
A usability test task is a realistic goal you give a participant, worded so it doesn't tell them how to reach it. A good task has three parts:
A scenario: a short reason the person would do this.
A goal: what they're trying to achieve, in their words rather than the product's.
A finish line: a state you can observe, so you know when the task is done.
The task is your measuring instrument. If it leaks the answer, you end up measuring whether people can follow instructions, which almost everyone can.
The four tasks from the banking app study
The study covered three of the most used areas of the app: Home, Pay and Cards. Participants completed four scenario-based tasks:
Find your current account balance.
Send a payment to someone in the UK, and to someone abroad.
Find your most recent transaction.
Get to your card settings.
Those are summaries of the tasks. Below is how I'd write tasks like them for any banking or fintech test, and the rules behind the wording.
Rule 1: Describe the goal, never the interface
The fastest way to ruin a task is to use the interface's own labels. Compare these two:
Directions: "Tap Pay, then select Pay someone in the UK."
Task: "You owe a friend in France £50 for a trip. Send it to them."
The first tests whether someone can find a button you've just named. The second tests whether your labels match what people are trying to do.
In this study, that difference produced one of the clearest findings. The label "Pay someone in the UK" misled participants who needed to send money internationally, even though a Global Money Account was visible on the same screen. A task phrased in the app's vocabulary would have walked people straight past the problem.
Testing guides make the same point. Userbrain suggests rewriting "Click on the Sign Up button" as "Register an account", and Maze flags phrases like "click here", "go to" and "navigate to" as hints.
A quick check: read the task aloud and listen for any word that appears on screen as a button, tab or menu item. If you hear one, rewrite the task around the person's goal.
Rule 2: Give a reason, and keep it short
A one-line scenario helps people act as they would at home. "Check whether your salary has arrived" gives a balance task a reason. "You're about to pay for dinner and want to check you have enough first" does the same job.
Keep scenarios to a sentence or two. Long stories turn into a memory test, and participants start re-reading the task card instead of using the product.
Rule 3: Set a finish line you can see
Before the first session, decide what "done" looks like for every task. For tasks like the four above, I'd define it as:
Balance: the current account balance is on screen.
Payment: the participant reaches the confirmation step for the right kind of payment.
Transaction: the most recent transaction is on screen.
Card settings: the card settings screen is open.
Without a finish line, "completed" becomes a judgement call made after the fact. With one, a claim like "all five participants completed every task" is something you can check against your notes.
Rule 4: Keep the count low and start easy
Four tasks left enough time in each session for think-aloud, the SUS questionnaire and the interview. For remote unmoderated tests, Maze suggests no more than eight tasks per session.
Starting with a simple task, such as finding a balance, lets people settle into thinking aloud before the harder ones. If the hardest task comes first, every later result carries the stress of it.
Rule 5: Keep tasks identical between rounds
Round 2 tested the redesigned prototype on the same core flows as Round 1 tested the original app. That's what makes 38.0 to 90.5 a fair comparison: the questionnaire, the flows and the goals stayed the same, and only the design changed.
If you reword tasks between rounds, you can't tell whether the score moved because of the design or because of the words. Write the tasks once, save them with your test plan, and reuse them word for word.
Rule 6: Stay neutral after the task too
A task can be clean and the follow-up can still lead. "Was that confusing?" suggests an answer. "What were you expecting to happen there?" doesn't. Maze's example of a leading question is "How much did you enjoy this product?", which assumes the person enjoyed it.
During think-aloud, prompts like "What are you looking for?" or "What would you do next?" keep people talking without steering them.
A checklist before you run the session
I run every task through these questions:
Does it name a button, tab, menu or label from the product? Rewrite it.
Does it give a reason someone would do this in real life?
Is there one goal, with a finish line I can observe?
Would it make sense to someone who has never used the product?
Will I use exactly the same wording in the next round?
Are my follow-up prompts free of words like "easy", "confusing" or "like"?
If a task fails one of these, fix it before the first participant arrives. Analysis can't rescue data from a task that gave away the answer.
What tasks can and can't tell you
Five participants and four tasks showed where people struggled and why. They can't tell you what percentage of all users would struggle. The participants were university students aged 18 to 30, and the study covered three flows, so the results describe that group and those journeys.
Small-sample usability testing is built for exactly this: finding problems quickly enough to fix them and test again. Nielsen Norman Group's well-known argument for testing with 5 users rests on running several small rounds rather than one big one.
What I'd do next
If I ran this study again, I'd keep the same four tasks so the scores stay comparable, and add to them:
A third round with a more diverse group, including older adults and people with visual impairments, to check the changes hold beyond students.
Tasks for the flows that were out of scope, such as notifications, savings, account statements and the wider settings.
A VoiceOver session on a physical iPhone using the same tasks, to complement the design-stage accessibility audit I ran with Stark in Figma.
An A/B test against the live app, for statistically meaningful data from a larger and more representative group.
The full project, from heuristic evaluation to the redesign and accessibility audit, is in my HSBC app redesign case study.
Work with me
I'm Ahmed Amine Tiffrent, a product designer in Brighton who researches, designs and builds. I'm open to product and UX designer roles (full-time, part-time or contract) and to freelance projects, including usability testing and redesigns. Get in touch here.
