Perspective
Your Instructional Design Portfolio Needs a Chain of Evidence
A finished sample shows what you built. A chain of evidence shows how you investigated the problem, chose a response, tested it, and understood its limits.
Your portfolio says you solve performance problems. Where can I see you doing that?
A polished sample can show your production skills. It can also leave the biggest claim on the page unsupported. I can open the course, admire the layout, and still have no idea why the course needed to exist.
If you want a portfolio to show learning design judgment, give the reader a way to follow a decision. What did you notice? What evidence changed your interpretation? Why did you choose this response? What happened when someone tried it?
I think of that as a chain of evidence. Each link lets another person inspect the reasoning instead of accepting the headline.
Start with a claim someone can inspect
The sample is one piece of the case. It is not the whole case.
This does not mean writing a long essay beside every project. It means choosing the few details that make your most consequential decisions understandable.
Connect four links
For a useful first pass, I would connect four things: the problem, the evidence, the decision, and the test.
The problem: describe the gap in the work. “Employees need onboarding” names a program. “New coordinators cannot independently complete an accurate handoff” describes something you can examine.
The evidence: show what informed your interpretation. That might be an observation, an interview finding, an approved process, or a sample of work. Explain what the material supports and what it cannot establish.
The decision: identify a choice that affected the experience. Perhaps you replaced a process overview with handoff practice. Explain the alternative you considered and the reason you chose differently.
The test: show how you checked the choice. A prototype review can reveal confusing instructions. A practice task can reveal missing information. Neither automatically proves a business outcome.
When one of these links is missing, label the gap. An honest next step is more useful than an invented result.
Show the chain in one small project
Here is a hypothetical portfolio project: helping project coordinators hand off work to another team.
The initial request is an onboarding module. In this example, sample handoffs suggest the recurring issue is that coordinators list completed activities but omit unresolved decisions. A process owner confirms which information the receiving team needs.
The designer proposes a handoff template and a short practice activity. The template supports the real task. The practice asks the coordinator to decide what the receiving team must know before accepting the work.
A concise case-study excerpt
“I focused the prototype on unresolved decisions because the sample handoffs showed those were often missing. I paired a reusable template with practice rather than creating a broad onboarding module. The first test would examine whether users can identify the missing decision, record its owner, and explain what remains blocked.”
Notice what this excerpt does not claim. It does not say the prototype reduced rework, improved productivity, or saved money. Those are possible outcomes to investigate, not results to attach to a demonstration.
The portfolio could show the anonymized observation summary, one annotated design decision, the working prototype, and the test plan. That is enough to make the reasoning visible without uploading every meeting note.
Separate a real result from a planned result
A self-initiated project can demonstrate judgment. It cannot provide evidence you never collected.
If your audience is hypothetical, say so. If you interviewed two people, explain that narrow basis. If you have not tested the prototype, write “planned test” rather than “validated solution.”
I would distinguish three levels of evidence in a case study:
- Design evidence: what supports the response you chose?
- Use evidence: what happened when people tried the experience?
- Performance evidence: what happened later in the work, and what else might have influenced it?
You may only have the first level. That is a legitimate starting point. Explain the next observation you would need before making a stronger claim.
For the handoff example, a successful prototype test might show that participants identify missing decision owners. It would still leave open whether the template is used during actual handoffs and whether the receiving team finds it helpful.
Keeping those boundaries clear makes the case more credible. It also gives an interviewer something concrete to discuss with you.
Edit for decisions, not project chronology
A case study does not need to recount everything in the order it happened.
“First I analyzed, then I designed, then I developed” tells the reader you followed a process. It does not tell them what the process helped you discover.
Lead with the decision that changed the project. Maybe you narrowed the audience, removed content, changed the delivery format, or found that the requested activity practiced the wrong behavior.
Then show the evidence behind that decision. Include one artifact that makes it easy to inspect: an annotated before-and-after, a short excerpt from a task analysis, or a test observation linked to a revision.
Give your contribution a clear boundary too. If someone else conducted the research, write that. If you designed the practice but did not own the rollout, write that. Collaboration belongs in a credible case study.
AI use needs the same clarity. Explain what it helped produce, how you reviewed the output, and one material decision you made about using or rejecting it. A list of tools explains the stack; it does not explain your contribution.
Audit one sample before adding another
Open your strongest portfolio sample and ask whether someone unfamiliar with the project can answer these questions:
- What specific problem were you addressing?
- What evidence supported your interpretation?
- Which design choice required judgment?
- What did you test, observe, or plan to test?
- What remains uncertain?
If the answers are missing, improve the case before building another sample. A second polished artifact will not repair an unsupported claim on the first.
Keep the live experience easy to reach and the explanation easy to scan. Show enough reasoning for a reader to understand the work, then let them explore the sample.
For me, that is the standard worth aiming for: a portfolio that lets someone examine how you think and how you check your thinking.
Give the reader evidence they can follow, not just a result they have to admire.
Related reading
Devlin Peck’s guide to AI portfolio projects. Related reading on possible project formats. This Perspective focuses on how to substantiate the decisions and claims within a case study.
Learning Rewired Lab™
Build a defensible case before you write the case study.
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.
- One connected project record
- Request and performance diagnosis
- Product-minded learning tools
- AI-assisted design workflows
- Practical workplace application