The first clue is often not a request for software. It is a pause, a repeated step, or a workaround someone has learned so well they no longer think to mention it.

Those moments can be useful. They are not yet a product brief. A person may do something slowly because the task is genuinely difficult, because it happens rarely, because they prefer a different outcome, or because a constraint we cannot see is shaping the work. If we jump straight from a visible inconvenience to a feature, we can end up making the wrong part faster.

What to learn first

Government Digital Service guidance asks teams to understand the whole user problem, test assumptions, and use quick prototypes to examine hypotheses. We use the same discipline as a starting point, then adapt the method to the task.

Understand users and their needs

Watch the task, not just the explanation

When someone describes a problem from memory, they naturally organize it into a story. That story matters, but the work itself gives us another kind of information. What do they open first? What do they copy? Where do they stop to check something? What do they do when the expected next step is missing?

We can learn from that without turning a conversation into an inspection. Explain what we are trying to understand, let the person choose what they are comfortable showing, and treat their current method as a reasonable response to their circumstances. We are there to understand the work, not grade it.

Useful notes stay close to what actually happened. “The form is confusing” is already an interpretation. “They returned to the previous screen twice to compare two fields” describes something we can discuss. The interpretation may still be right, but keeping it separate gives us room to consider other explanations.

Look for the shape of the workaround

A workaround is a clue about the job someone is trying to get done. It might reveal missing information, a need to compare alternatives, fear of losing work, or an approval step the software does not acknowledge. The workaround does not automatically mean the tool should absorb that entire job.

Ask what the workaround protects. Does it make the result easier to check? Does it leave a record? Does it give the person control over a step they do not trust another system to handle? Does it help them recover if something goes wrong? A proposed shortcut that removes one visible step may also remove the reason that step was there.

The frequency and consequence both matter. A frustrating action that happens once a year may deserve a different response from a small delay repeated all day. A rare action can still be important if a mistake is costly. Count and context belong together.

Build a map before proposing a route

For a useful first pass, write down four things:

1. The task: what the person is trying to complete, in their words.
2. The moment: where they pause, repeat, switch tools, or ask for help.
3. The workaround: what they do now and what that method protects.
4. The consequence: time, effort, uncertainty, risk, or something else that matters to them.

This is a lens, not a scoring system. Its job is to make the problem discussable before we choose an interface. If one of those parts is unknown, mark it as unknown. Do not fill the gap with a confident sentence.

Consider a clearly hypothetical example: someone copies details from a short note into a planning document before beginning a creative task. It might be tempting to propose automatic document generation. But first we would want to know why the details are copied. Maybe the note is unstructured. Maybe the planning document is shared with another person. Maybe the writer is checking that they have enough information before committing. These explanations point to different designs, and perhaps to no new software at all.

Choose a response that fits the uncertainty

Once we can state what we do not know, we can choose a test that answers that kind of question. If we do not know whether the task happens, watch the task. If we do not know why a person takes a particular step, ask about it while it is fresh. If we do not know whether a new sequence is understandable, sketch the sequence and ask someone to try it. If we do not know whether a system can handle a messy input, make a small technical prototype with realistic examples.

The smallest test is not always the cheapest-looking artifact. A quick mock can take more time to explain than a plain conversation. A manual service might be the clearest way to learn what a person needs before automating anything. A technical spike may be necessary when the biggest uncertainty is feasibility. The test should be small relative to the decision it informs, not small for its own sake.

Before running it, write down what you will do with each plausible outcome. If the observation confirms the problem, what becomes the next question? If it points somewhere else, what will you revise? If the result is mixed, what is too uncertain to conclude? This keeps the work honest when a neat answer would be convenient.

Leave room for a different idea

Research is useful only if it can change the work. Sometimes it confirms that the original problem is worth solving. Sometimes it shows that the difficulty sits elsewhere, or that a workaround is doing something we did not understand. Sometimes the best outcome is to make an existing tool clearer instead of introducing another one.

We do not need to make every inconvenience into a company or product. We need to see the person, the task, and the consequence clearly enough to decide what deserves our attention. That is a better beginning than designing a feature because it is easy to picture.

Sources and scope

This essay gives a practical way to apply research guidance. Its note-taking sequence and creative-task example are Einhar's framework and an explicitly hypothetical illustration, not findings from a study. The external reference is the GOV.UK Service Standard, point 1, which recommends understanding user needs and testing assumptions early.