💳 Secure Payment

Full-Service Web & Software Agency · Klamath Falls and Redding

Identifying user needs

Work with Sean

A user story is only as good as the need behind it, and the need is often not the first thing a person asks for. It turns up through listening, watching and a few plain questions. Here are nine ways to go looking.

User interviews

The most direct route is to ask: one-on-one or in a group, with the people who use the result or the staff who serve them. A few habits make an interview pay:

  • Bring open questions, the kind nobody can answer with a yes or a no.
  • Listen more than you talk, and let each answer lead to the next question.
  • Watch as well as listen: a pause or a frown says what the words leave out.

Surveys and questionnaires

A short survey, such as a few questions emailed to regulars or a card at the counter, reaches the customers no one has time to interview. When writing one:

  • Keep it to a few questions, so people finish it.
  • Ask about the last visit, such as what they came for and whether they found it, rather than what they would like.
  • Read the answers for the need that comes up again and again, then ask about it in an interview.

Observation and user testing

Watching people at work, at the counter, on the phone or in the software they use now, shows what they actually do, which is not always what they say. User testing puts a prototype or the current software in their hands and watches what happens.

  • Write down what people do, what they say and what their faces say.
  • Note each place someone hesitates, backtracks or asks for help: that is where the pain points are.

The people who serve customers

The owner, the counter staff and whoever answers the phone talk with customers every day. They hear the same questions all week, and they know the workarounds.

  • Ask them regularly what customers ask for, and what they work around.

Online analytics

If the business already has a site, its analytics show what visitors do: the page they land on, how far they get and where they leave. The numbers say where to look, and an interview says why.

  • Find the step where most visitors leave, such as a booking form left half done, and ask the staff what customers say about it.

Support and feedback channels

Support emails, messages and social media show the questions customers ask again and again, and the pain points behind them.

  • Read the support log and the feedback regularly, and note what keeps coming back.

Personas

A persona is a short sketch of one kind of person the job serves, such as the regular who orders ahead, the visitor who has never been in or the clerk at a county counter, with what they need to get done and what gets in their way. It is drawn from what the interviews and observation found, never guessed.

  • Name the persona in each story, so “As a regular who orders ahead” means the same person to everyone on the job.

Contextual inquiry

Contextual inquiry joins the interview to the observation: sit beside someone while they do the work, and ask about each step as it happens, such as why a phone order goes on paper before it goes into the register. They lead, as the expert on their own work, and the questions follow what they do.

  • Ask about the step in front of you while it happens, rather than about the job in general.

Brainstorming together

Bring the webmasters on the job, the owner and the staff together to compare what each has heard. Brainstorming finds options; the interviews and observation above say which of them answer a real need.

The request against the need Two bars across one afternoon. The PDF menu shows Brisket all day. Today's menu shows Brisket until 1 p.m., then sold out, highlighted. A highlighted line at 2 p.m. crosses both bars, where a customer opens the menu. the request: a PDF menuBrisket, all daythe need: today’s menuBrisketsold out1 p.m.2 p.m.
One afternoon, two menus. The PDF says Brisket all day; today’s menu marks it sold out from 1 p.m., outlined in violet. The violet line is the customer who opens the menu at 2 p.m.: only the need’s version tells them the truth.

Finding needs doesn’t end with the first interview. Each conversation adds to what the team knows about the people the job serves: what it finds before the scope is signed shapes the stories, and a need it finds afterwards that no story in the scope covers is a change, written as a new story.

To try it, take one request from your own week and ask the person who made it when it was last a problem. If the request would fix what happened, it was the need all along; if it wouldn’t, what happened is the need, and the story starts there.

The next lesson, on capturing user requirements effectively, writes the sold-out need down as a requirement the owner can check before the scope is signed and a test can check once the work is built.

Copyright Sean Paul Payne Dinwiddie
All Rights Reserved