Perspective
We Want Designers to Validate AI. Will We Give Them Time?
Validating AI-generated learning takes judgment, access, and time. What happens when delivery pressure rewards the designer who skips it?
Imagine a learning designer receiving an AI-generated onboarding course on a Thursday afternoon. The slides are clean, the narration sounds reassuring, and the knowledge checks have that familiar corporate confidence in which every question has four answers and the correct one is considerably longer than the others. Someone has already shown the draft to a leader. The leader likes it. Could we have this live by Monday?
The designer starts reading. A procedure sounds almost right, but the sequence differs from the one in the operations guide. A policy statement has no identifiable source. A scenario rewards an employee for making a decision that, in the actual workplace, requires a supervisor. None of these problems announces itself through a broken layout or an obvious spelling error. The course looks finished. Finding out whether it deserves to be finished will require conversations with people who are already busy, documents that may disagree, and decisions about which source should take precedence.
By Friday morning, the designer has become the person holding up the launch. The system that produced the draft has demonstrated its efficiency. The person asking whether the draft is accurate now has to defend theirs.
This is the tension underneath an otherwise reasonable claim about the future of instructional design: as large language models produce more of our content, designers will need to become better at validating what those models produce. I agree. A designer should be able to question a claim, trace it to a credible source, recognize the limits of their own knowledge, and identify the person qualified to resolve uncertainty. But telling designers to develop those skills leaves a rather large question unanswered. Will the organizations employing them make room for those skills to be used?
It is easy to celebrate human judgment in a presentation about the future of work. It is harder to protect two hours for it when the project sponsor believes the work was completed yesterday.
When a draft becomes a deadline
Much of the appeal of AI in learning development rests on the promise of shorter production cycles. A first draft that once took days might arrive in minutes. There is real value in that possibility. Getting something concrete in front of a team sooner can expose disagreements, make an abstract request easier to discuss, and free a designer to spend more time on the decisions that shape the learning experience. I want those benefits. The difficulty begins when the existence of a draft becomes evidence that most of the work is over.
A draft establishes that words and images have been assembled. It does not establish that the instructions match current practice, that the examples represent the learner's working conditions, or that the practice activities prepare someone to make the decisions the job requires. Those questions existed before generative AI. A human could write an inaccurate course with enormous care and very attractive typography. What changes when production becomes faster is the expectation surrounding the next stage. If we can generate the course before lunch, why are we still discussing it on Friday?
The answer may be that the course contains questions nobody has answered yet. Generating a confident explanation does not resolve an ambiguous procedure. It gives the ambiguity a voice.
Consider a hypothetical restaurant onboarding lesson that instructs a new employee to resolve a customer complaint by offering a replacement meal. The sentence is clear. The intention sounds helpful. But does that employee have the authority to make the offer? Does the answer change depending on the complaint? Is there a point at which a manager must become involved? A designer could verify the grammar, simplify the language, and improve the visual hierarchy without discovering whether the advice fits the job. Even an accurate summary of a general customer service principle might become an inappropriate instruction in that particular restaurant.
Validation therefore involves more than checking whether a model invented a fact. It includes checking applicability, authority, and the relationship between what the course teaches and what someone will actually be allowed to do. A source can be authentic and still be outdated. A procedure can be current and still belong to a different location. A subject matter expert can approve the wording while overlooking what the scenario asks the learner to infer. Putting a human into the review process matters only if that human has a defined responsibility, enough context, and a workable way to raise an objection.
Responsibility needs room to act
This is where the argument for designer accountability needs some care. Designers have a professional responsibility to ask difficult questions. They also work within systems that determine who is available, which documents they can access, and whether an unresolved concern has the power to delay a release. Asking someone to own the quality of an output while denying them access to the people who can verify it creates accountability without the means to exercise it. If raising a concern repeatedly earns the response that there is no time, the organization is teaching its own lesson about what quality means in practice.
The lesson becomes especially clear when the launch date is treated as fixed and the review is treated as flexible. The project can absorb another requested feature or a late change to the introduction, but the remaining verification has to fit into whatever time survives. Under those conditions, calling validation a core future skill risks turning it into a convenient explanation after something goes wrong. The designer was supposed to catch that. The schedule that made catching it difficult can disappear from the conversation.
Deciding what needs checking
There is, however, a fair objection to making this argument too broadly. Teams cannot investigate every sentence indefinitely, and the answer to faster production cannot be an approval process so elaborate that nobody can finish anything. A minor wording preference does not deserve the same scrutiny as an instruction with serious consequences. Designers who want their judgment respected need to make useful distinctions about where attention belongs. Treating every uncertainty as equally urgent can make the important ones harder to see.
The practical skill is deciding what needs verification, what evidence would be sufficient, and what happens if that evidence cannot be obtained. An optional example in an introductory lesson might need a straightforward source check. An instruction that affects an employee's permissions or a customer's money may require confirmation from the person responsible for that procedure. A conflict between two internal documents may require an organizational decision before any wording can honestly be called correct. These are different kinds of work, with different owners and different consequences. A generic request to “review the course” hides those differences.
This judgment should begin before the draft becomes a polished object that everyone is reluctant to disturb. At the start of a project, the team can identify which claims depend on internal policy, which instructions carry meaningful consequences, who can approve them, and what evidence must exist before release. That will not eliminate surprises. It does make verification part of the work being planned, with an owner and a place in the schedule. It also gives the designer something more useful to say than “I need more time.” They can explain that a specific instruction remains unverified, identify who can resolve it, and offer a concrete choice about what can proceed.
Sometimes that choice will be to remove an unsupported section, narrow the scope, or release the parts that have been confirmed. Sometimes the uncertainty can be made explicit without misleading the learner. Other times, publication needs to wait. A caveat cannot make an unsafe instruction acceptable, and the designer should not be left to quietly absorb a release decision that belongs to the responsible leader. Someone needs to understand what remains unknown and have the authority to act on it.
Support for judgment, time to use it
There is a useful role for AI in this process, provided we are precise about what the assistance establishes. A model can help identify claims that warrant checking, organize questions for a subject matter expert, or compare a draft with a supplied reference. Those activities can make review more manageable. Asking the model whether its own answer is correct, however, does not provide independent confirmation. An explanation of why something sounds right is still an explanation to examine.
This is the role I want tools such as the Decision Workbench to support: helping a practitioner examine a request, surface assumptions, and prepare the questions that need answers before committing to a solution. The value depends on what the designer does with that support. A question identified by a tool still needs to reach someone who can answer it. A missing fact remains missing until there is adequate evidence. Software can help make the unresolved work visible; the team still has to decide how to resolve it.
For designers, that means developing a broader understanding of validation than a final accuracy check. It means learning to explain why one uncertainty matters more than another, recognizing when an expert's approval is too vague to be useful, and making the consequences of a decision understandable to the people paying for the work. It also means being willing to proceed when the evidence is sufficient. Professional judgment includes knowing when further checking would add little value, just as it includes recognizing when a deadline is asking the team to accept a risk it has not properly considered.
For leaders, the responsibility is equally concrete. If AI reduces the time needed to produce a draft, decide how much of that saving should improve verification, practice design, or testing before promising the entire saving as a shorter deadline. Give reviewers specific questions. Make qualified people available. Allow an unresolved issue to change the scope or release date when the consequences justify it. These are management decisions that determine whether a designer's expertise can affect the finished product.
I believe validation belongs among the core skills of future learning designers. But a skill becomes valuable through its use, and its use depends partly on what the organization permits and rewards. If we want designers to question plausible content, we have to make it possible for their questions to change what gets published. Otherwise, we are asking them to perform a ceremony whose outcome has already been decided.
Return to that Thursday afternoon course. By Friday, the designer has found the person who owns the procedure, confirmed the sequence, and rewritten the scenario so the employee practices recognizing when to involve a supervisor. Perhaps the course still launches Monday. Perhaps one section waits. Either way, the review has changed what a new employee will be taught to do. That is a contribution the team should be able to recognize when it asks where the time went.
We saved six hours generating the course. Asking for two hours to check it should not make the designer the problem.
Decision Workbench
Make the questions visible before you build.
Use Decision Workbench to surface assumptions, identify facts to check, and prepare a plan for your stakeholder conversation. Confirm important claims with authoritative sources and qualified people.
AI can help organize the review. Qualified people and authoritative sources still need to confirm the facts.
- Identify questions and assumptions
- Name the facts that need checking
- Bring questions to the right people
- Develop recommendations to discuss