Perspective

Prompt Writing Is Becoming a Learning Design Skill

Useful prompts make the design brief explicit: the performance problem, learner context, constraints, and evidence that will help you judge the result.

Ask AI to create a course on handling difficult customers, and you have already made several design decisions.

You have decided that a course is needed. You have decided that the problem is something people can learn their way out of. You have decided that “handling difficult customers” describes the work clearly enough to build around.

Maybe those decisions are right. But the prompt does not give us much reason to believe them.

I think this is where the conversation about prompting gets interesting for learning designers. The useful skill is being able to explain what we are trying to improve, what we know about the people doing the work, and what a useful response would need to accomplish.

A prompt makes those decisions visible. It can also make their absence visible, if we take the time to look.

The prompt exposes the brief

A useful prompt is a design brief you can question.

That is why I see prompt writing becoming part of learning design. It gives us another place to practice the work of defining a problem, setting constraints, and deciding what counts as good.

Better wording cannot repair a weak decision

There is a temptation to treat every disappointing AI response as a wording problem. Add a role. Ask for more detail. Change the tone. Tell it to be more engaging. Try a longer prompt.

Sometimes those changes help. But they can also keep us polishing an answer to a question we should have reconsidered.

“Act as an expert instructional designer and create an engaging five-minute course” still starts with a course. “Use adult learning principles” does not explain the decision someone needs to make at work. “Make it interactive” does not tell us what the interaction should let someone practice.

You can get an attractive draft from a vague brief. That is part of the problem. A complete-looking answer can make unfinished thinking harder to notice.

Before asking for a better version, ask what you left the model to guess. Who is the audience? What are they struggling to do? What evidence supports that interpretation? What information is missing? Which decisions have already been agreed, and which are still open?

If you cannot answer those questions, another adjective in the prompt probably will not solve it.

Give it the context that changes the design

“Frontline employees” is an audience label. It is not enough context to design meaningful practice.

A new employee learning a process for the first time needs something different from an experienced employee who knows the process but cannot find the current policy during a customer conversation. Both might appear in the same training request.

The useful details are the ones that change your design decisions: prior experience, tools available, working conditions, time pressure, accessibility needs, language, and the consequences of a mistake.

Constraints matter just as much. A mobile experience used between tasks has different requirements from a facilitated workshop. A decision that must be made from memory needs different preparation from one supported by a searchable reference.

I would also tell the model what it must not invent. If a refund rule has not been supplied, it should flag the missing rule. If the cause of a performance gap is uncertain, it should preserve that uncertainty rather than turn a stakeholder’s opinion into a finding.

This does not mean pasting every document you have into a chat. Select the material relevant to the decision, use information you are authorized to share, and explain which sources govern the answer.

A useful constraint

“Separate documented facts, working assumptions, and unanswered questions. Do not invent policies, learner data, or evidence of impact.”

The same request, a different design task

Here is a hypothetical example. A customer support manager asks for refresher training because agents are escalating too many refund requests.

The quick prompt might be:

“Create a five-minute microlearning course on handling refund requests. Include three knowledge checks and make it engaging.”

That prompt gives AI a production assignment. It does not ask whether the assignment makes sense.

Now imagine that a review of sample cases suggests agents can explain the basic policy, but hesitate when an exception applies. They have a policy reference available during calls. Some cases also show that the exception guidance is unclear.

That changes the design task. We might need decision practice, a clearer reference, and a policy clarification before we need a refresher on the basics.

A more useful prompt would be:

A prompt built around the decision

“Help me examine a request to reduce unnecessary refund escalations among experienced customer support agents.

In this hypothetical case, a review of sample cases suggests that agents know the basic refund policy but hesitate around exceptions. They can access the policy during calls. Some exception guidance may be ambiguous. We have not established how much each factor contributes to escalation.

Before drafting training, separate possible practice needs from policy or reference problems. Identify the questions we need answered and the evidence that would help us choose a response.

If decision practice is justified, outline three short cases in which agents must choose whether to resolve, consult the reference, or escalate. Each case should test a different boundary. Explain what each case would let us observe.

Use placeholders for policy details I have not supplied. Do not invent refund rules. Flag any case that cannot be judged without a policy decision. Return a diagnostic table first, followed by a provisional practice outline.”

The second prompt does more than describe the output. It defines what is known, what remains uncertain, and the sequence of decisions we need to make.

It also allows an answer we may not have expected: clarify the policy before building the activity.

That is design work.

Write the criteria before reading the answer

One of the most useful things you can put into a prompt is an explanation of how you will judge the result.

If you are asking for a scenario, “realistic” needs a definition. Does the learner face a decision that occurs in the actual workflow? Do they have the information they would really have? Is there a plausible reason to choose the weaker option? Does the feedback explain a consequence or merely announce a score?

Those questions give you something to inspect beyond whether the writing sounds convincing.

For the refund example, I would check whether each case tests a distinct decision boundary, whether the correct response follows the approved policy, and whether feedback explains when consultation or escalation is appropriate. I would also check that the scenario does not punish an agent for ambiguity the organization has failed to resolve.

You can ask AI to review its draft against those criteria. That may surface problems. It is not independent validation, and it does not establish that the policy is correct or that the practice will improve performance.

You still need to inspect the sources, involve the people who know the work, and try the experience with intended users where practical.

The model can help you apply a standard. You remain responsible for deciding whether the work meets it.

Reuse the structure, revisit the decisions

I like reusable structures. They save us from starting over and remind us to ask questions we might otherwise skip.

But a saved prompt can also carry yesterday’s assumptions into today’s project. A template that always asks for a course outline quietly makes every problem look like a course problem.

The structure I would reuse is a short design brief:

  1. Performance: What does someone need to do, decide, or recover from?
  2. Evidence: What do we know about the current problem, and what is still an assumption?
  3. Context: Who is doing the work, under what conditions, and with which tools or support?
  4. Constraints: Which requirements must the response respect? Which sources govern it?
  5. Design task: Are we diagnosing, comparing responses, drafting practice, or reviewing an existing solution?
  6. Quality criteria: What would make the result useful, accurate, and appropriate for this situation?
  7. Uncertainty: What should be flagged, questioned, or left unresolved rather than guessed?

You do not need to turn every small request into a giant prompt. Match the brief to the task. Rewriting a sentence requires less context than recommending a response to a performance problem.

For a larger project, work in stages. Examine the request, review the evidence, compare possible responses, then draft the part you have enough information to design. Carry the agreed decisions forward and revisit them when new evidence changes the picture.

The goal is to keep the reasoning available for review, rather than burying it inside a polished final output.

Judge the work beyond the chat window

A stronger prompt can produce a more relevant draft. That does not mean we have improved learning.

The draft still has to survive contact with the job. Can people understand the situation? Can they use the support when they need it? Does the practice expose the decisions we care about? Does the feedback help them improve?

In our hypothetical refund example, fewer escalations would not be enough on its own. Agents could reduce escalations by approving requests they should have referred. We would need to examine the appropriateness of decisions as well as the escalation rate.

That is another design judgment a prompt cannot settle for us. We decide which evidence matters and what tradeoffs we will accept.

I do not see prompt writing as a career guarantee. It does not make someone irreplaceable, and a collection of clever prompts is not a substitute for understanding learning or the work people do.

I see it as a practical skill that makes our thinking inspectable. It forces us to express intent, name uncertainty, and define the standard before we ask for an answer.

Try it with the next prompt you were going to use. Underline every decision you have already made. Circle every detail the model would have to guess. Then ask whether those decisions are supported.

You may need a better prompt. You may need a better brief. You may need to go back to the stakeholder with a question you had not thought to ask.

Prompt writing earns its place in learning design when it helps us make better decisions about what people need.

Learning Rewired Lab™

Make the brief stronger before you generate the response.

The Lab is the complete professional workspace for turning a learning request into a defensible performance solution. Challenge the request, investigate the system, design the response, and plan the evidence in one connected project.

Challenge the request, examine the system, and design for performance before production begins.

Inside The Lab
  • One connected project record
  • Request and performance diagnosis
  • Product-minded learning tools
  • AI-assisted design workflows
  • Practical workplace application