Need Help but Still Want to Learn? Make the Request Clear in 3 Parts

State the result, show the visible mismatch, and say what kind of help would move you forward without taking the task away.

A learner in Kenya points to one part of a laptop screen while another person helps from the side without taking the keyboard.

This article is for you if

You are stuck on a task and want another person to understand the problem without taking over the whole job.

By the end, you will be able to

You will be able to make a short help brief that names the result, shows what went wrong, and sets the level of help you want.

You have the chat open and someone is ready to help. How do we explain the problem without giving them the whole job?

Maybe you are about to send a voice note to a classmate, or a coworker has replied, “Which part is giving you trouble?”

You could tell the whole story from the beginning. You could also send one short line that leaves the other person guessing.

There is a more useful middle ground.

Let’s give the helper enough to see the problem clearly while keeping the next move with you.

The short version

  • Let’s lead with the result we are trying to reach.
  • Let’s make the problem visible with what we expected, what happened, and what we already tried.
  • Let’s tell the other person whether we want a clue, an explanation, one example, or direct help finishing.

1. Put the result first, before the history of the problem

When something has gone wrong several times, it is natural to want to explain every attempt.

But the person helping you needs the destination before the backstory.

Imagine you are helping a small shop in Nakuru prepare a stock summary before closing. The table looks fine on the laptop, but part of it disappears when you save the file to send to the owner.

You could write:

“The file keeps causing problems and I have already changed many things.”

Or you could start with:

“I’m trying to save the stock summary so every item is still visible in the final file.”

The second sentence gives the other person a target. Once they know the result you want, they can tell which details matter and which ones can wait.

The same idea works with a shared task:

“I’m trying to make sure the newest customer list is the version everyone opens.”

It also works when you are learning:

“I want to understand why this step works, not only copy the answer.”

You do not need to prove how long you have struggled. You only need to show what success would look like.

A useful first line is:

“I’m trying to ______.”

That one sentence gives the rest of the request a direction.

2. Show the mismatch: what you expected, what happened, and what you tried

A clear result is only the beginning. The helper still needs to see the part that does not match what you expected.

Suppose you are sorting a customer delivery list for a small team in Kisumu. After you sort the rows by area, several phone numbers no longer appear beside the correct names.

Instead of writing, “The sheet has gone wrong,” break the problem into three visible parts:

Expected: I expected each phone number to stay with the same customer after sorting.
Happened: Some names moved, but the phone numbers beside them did not match.
Tried: I undid the sort, selected the full table, and tried again, but the mismatch returned.

Now the other person can compare what you wanted with what you can actually see.

Stack Overflow’s current Ask Wizard uses a similar communication pattern for first-time programming questions. It separates the description of the problem from what the person tried and what result they expected. That tool is for programming, so we are borrowing the structure rather than treating it as a rule for every kind of problem. (Stack Overflow Help Center)

The same structure can help with writing or presentation work.

For example:

Expected: I wanted the first paragraph of my update to make the request clear.
Happened: A teammate replied by asking what I needed them to do.
Tried: I shortened the paragraph, but the action I wanted is still easy to miss.

The question does not need more impressive language. It needs a gap that another person can see.

3. Say how much help would be useful right now

Even a well-explained problem can bring the wrong kind of help if the other person does not know where you want them to stop.

Picture yourself following an online lesson after a matatu ride home. A friend offers to send you the finished answer, but the thing you really need is an explanation of the step where your own work stops making sense.

You can ask for a clue:

“Can you point me to the first thing I should check?”

You can ask for an explanation:

“Can you explain why this changes when I do the next step?”

You can ask for one worked example:

“Can you show me this one case, then let me try the next one?”

Or you can say that finishing matters more at this moment:

“I need to complete this today. Can you help me fix it now and explain the key step afterwards?”

These requests are not the same. The useful choice depends on whether you mainly need to understand, to finish, or to do some of both.

A 2011 paper on help-seeking in a geometry tutoring system discusses a difference between help aimed at learning and help aimed mainly at completing a task. In two studies, feedback about help-seeking improved how students asked for help while they used the tutoring system. The second study also found improved help-seeking on new geometry content during the following month, after the special support had ended. Because the research took place in one specific learning setting, it does not show that one question format will work for every learner or every problem. It supports the narrower point that help-seeking behaviour can change through practice and feedback in at least some learning settings. (Roll, Aleven, McLaren and Koedinger, 2011)

That limited idea still matters in everyday work and study.

Sometimes you need someone to step in. Sometimes you need one missing explanation. Sometimes you need one example and then room to continue on your own.

Put the target, the evidence, and the help boundary into one message

The three parts each solve a different communication problem. The result tells the helper where you are trying to go, the evidence shows exactly what is not matching, and the boundary tells them how far you want their help to reach.

The order also matters. If you skip the result, the message can become a long history; if you skip the evidence, the other person has to guess; if you skip the boundary, they may do the whole task when you wanted to learn, or give a long explanation when you only needed a quick fix.

A complete request could sound like this:

“I’m trying to keep each phone number with the correct customer after sorting this delivery list. Some names move but the numbers no longer match, and I have already undone the sort and tried again with the full table selected. Can you show me what I should check next instead of fixing the whole sheet for me?”

It does not need to sound polished. It only needs to make the goal, the gap, and the next role clear to both of you.

Move closer to the person you want to become

  • Let’s start the next help request with the result we actually want.
  • Let’s turn “it went wrong” into three visible pieces: expected, happened, tried.
  • Let’s say whether we want someone to point, explain, show one example, or step in and finish.