Skip to content

Learn

Write a task, and how you’d know it worked

Every usability study, walkthrough and design review starts with a task: one thing a person needs to get done, and the sign that they did. Write both down before anyone looks at a screen.

Usability

Name what the person is trying to do

Use their words, not your feature’s name. “Invite a teammate with the right access” is a task. “Use the Members page” is a tour of a screen, and tells you nothing about whether people get what they came for.

Keep it to one outcome. If the sentence needs “and”, it’s two tasks. Review them separately, so a problem in one doesn’t hide the other.

Say where they start

The same task is harder from the home page, signed out, than from a dashboard the person already knows. Name the page, whether they’re signed in, and as whom: a new administrator on their first day, or a member who has used the product for a year.

Say how you’d know it worked

Write what a person could point to afterward. “The teammate appears in Members as Pending, with the Member role” can be checked. “The invitation works” and “it feels intuitive” can’t.

  • Name what’s on screen or stored, in the words the product shows.
  • Say what would make it fail even if the task ended: two invitations sent, or the wrong role.
  • Prefer what survives a reload. A message that disappears proves less than a row in a list.

Say who is trying

Describe the person attempting the task: their role, how well they know the product, and what limits them, such as using only a keyboard or a screen reader, or a phone in a hurry. Add only what changes what they can see or do. A favorite color changes nothing; never having seen the product changes a lot.

Give them what they’d know

A real person inviting a teammate knows the teammate’s email address. Put details like that in the task. When a participant has to invent a value the task depends on, you learn about their guess, not your design.

Leave out the steps

Don’t write the clicks. A task that says “open Settings, then Members, then choose Invite” checks your instructions. Whether a person can find Members on their own is what the study is for.

Before and after

WeakStronger
Check onboarding.A new user signs up from the pricing page and creates their first project. It worked when the project appears on their dashboard.
Make sure invites work.An administrator invites Sam, a new teammate, as a member. It worked when Sam appears in Members as Pending, once.
Can people find the invoices?A member downloads last month’s invoices as a spreadsheet, starting from the dashboard. It worked when the file downloads.

See it on a product