A stakeholder review is a structured meeting or async process in which the instructional designer presents a storyboard or course draft to stakeholders and subject matter experts to gather feedback, validate decisions, and gain approval before proceeding to the next development stage.
Why it matters#
A reviewed and approved storyboard is the primary defence against late-stage changes and scope creep. Feedback collected before development begins costs almost nothing to act on. Feedback collected after a course is built can cost everything. The stakeholder review is where that early feedback is systematically gathered.
It also builds shared ownership. Stakeholders who have reviewed and approved a design are less likely to request fundamental changes later — they have already participated in shaping it.
Types of review meetings#
| Type | Purpose |
|---|---|
| Validation | Confirm that the design accurately reflects goals, audience, and content |
| Discovery | Surface new information or constraints not captured in initial scoping |
| Collaboration | Co-design specific elements — scenarios, feedback copy, assessments |
Define the purpose before the meeting. A validation meeting runs differently from a discovery session, and conflating them produces unfocused feedback.
Preparing for the review#
- Craft your story. Stakeholders respond to narrative, not documents. Open with the goal of the course and the audience it serves. Show how the design decisions connect to those before inviting critique.
- Lead with goals and objectives. Every design choice should be traceable to a learning objective. If you can explain why something is there, it is much harder to remove without a specific reason.
- Anticipate objections. Before the meeting, consider what stakeholders are likely to push back on — and why. Think through their motivations, interests, and constraints. Prepare a response that acknowledges their concern and redirects to the shared goal.
- Know what input you need. Come with specific questions, not just a request for general feedback. Vague invitations produce vague responses.
Running the meeting#
- Start with the big picture. Orient stakeholders to the overall course arc before drilling into slides. A reviewer who understands the structure gives better feedback on the details.
- Go beyond the how to the why. Don’t just describe what the learner will do — explain why the design works that way. Stakeholders who understand the reasoning are better equipped to suggest alternatives rather than just reject decisions.
- Be clear and concise. Long presentations invite disengagement. Prioritise the sections that need input and move quickly through the rest.
- Actively listen. When a stakeholder raises a concern, reflect it back before responding: “If I can summarise your position…” This confirms understanding and signals that the feedback has been heard.
Gathering useful feedback#
Ask specific questions that direct attention to what actually matters:
- What do you currently like and dislike?
- What information is missing that should be included?
- Which of these elements will directly address our shared learning goals?
- Is there anything else I should know that might affect the design?
Avoid open-ended requests like “what do you think?” — they invite subjective opinions about aesthetics rather than substantive input on whether the design will achieve the learning goals.
Key facts#
- Approval is the goal, not consensus. Stakeholders will not agree on everything. Your job is to gather input, make a defensible decision, and get sign-off — not to satisfy every preference.
- Feedback on a storyboard is cheap. Feedback on a built course is not. Every round of review at the storyboard stage saves multiple rounds of revision in the authoring tool. Create formal review checkpoints rather than ad hoc ones.
- Unanticipated objections are a preparation failure. If a stakeholder raises something you didn’t expect, file it for next time. Stakeholders follow predictable patterns — their motivations, interests, and constraints rarely change between projects.
When to use it#
- After completing a storyboard draft, before development begins
- At defined milestones in the development cycle — not continuously
- When a project involves multiple stakeholders with different approval authority — sequence reviews so final approvers see a version that has already been vetted by content experts