What a reviewer does with your portfolio
The person who opens your portfolio is rarely settling in to admire it. They are screening, usually between other tasks, and they are trying to answer one question fast: can this person run the workflow our job description implies, or can they only produce artifacts that look like the ones made by people who can?
That distinction decides everything about how the portfolio should be built. A gallery of polished screenshots answers the wrong question. Screenshots show that you can operate an authoring tool, which is worth something: employer job-posting data aggregated by O*NET’s in-demand technology skills for instructional designers shows tools like learning management systems, PowerPoint, Camtasia, and Storyline appearing across real postings. But tools are the cheapest thing on that list to demonstrate and the easiest to fake. What screening actually filters on is judgment: whether you can diagnose a performance problem, design against it, defend a decision, and say honestly what the result was.
So the unit of the portfolio is not the artifact. It is the case study: a short, skimmable account of one project that carries its artifacts as evidence. An artifact without a case around it is decoration. A case without artifacts inside it is an unsupported claim.
This is also the right lens for the instructional design portfolio examples and samples that circulate in link roundups: study them for how their case studies argue, not for layouts to copy. An example shows you a finished surface, never the analysis behind it, and the analysis is what a reviewer is hunting for. The same standard applies whether a job posting calls the file an eLearning portfolio or a learning and development portfolio; the label varies, the checks below do not.
Three cases cover the whole workflow
You do not need ten projects. You need the smallest set of cases that, together, prove the full workflow. For workplace learning and development roles, three cover it:
| Case | What it proves | The artifacts that prove it |
|---|---|---|
| Performance consulting case | You can diagnose before you build, and you can conclude that training is only part of the fix | Needs analysis document, cause breakdown, recommendation with non-training responses |
| eLearning production case | You can carry a design through storyboard, build, and quality review without losing the objectives | Design brief, storyboard excerpt, working module or narrated walkthrough, accessibility test record |
| Facilitated session case | You can design for a live room, not just a screen | Session plan, facilitator guide excerpt, participant materials, evaluation plan |
Each case should be scoped to one performance problem. A useful test: if you removed the project’s deliverable entirely, would the case still describe a problem worth solving? If not, the case is organized around the artifact instead of the problem, and it will read as a tool demo.
The three cases can come from one scenario. A single workplace problem, followed from training needs analysis through a storyboarded build to a facilitated rollout, produces all three cases with more coherence than three unrelated projects, because the reviewer watches the same evidence move through every stage. It also means that creating an instructional design portfolio starts with choosing a scenario worth diagnosing, not with opening a website builder.
The anatomy of one case study
A case study that survives skimming has six parts, in this order, under headings a reader can navigate by:
- The problem. Who could not do what, to what standard, and what it cost. One paragraph. No tools mentioned yet.
- Your role and the constraints. What you specifically did, and the real limits: timeline, budget, tooling, stakeholder availability. Constraints are not excuses; they are the conditions under which your decisions make sense.
- The analysis. What evidence you collected and what it showed, including the causes training could not fix.
- The decisions. At least one design decision explained with the alternative you rejected and why. This is the paragraph reviewers quote back in interviews.
- The artifacts. Each one captioned with what it proves, not just what it is. “Storyboard, screens 1 to 3, showing the branching feedback for the first decision point” beats “Storyboard sample.”
- Results and limits. What was observed, stated separately from what was hoped. If the project was a practice build with no deployment, say exactly that and report what your quality review and pilot testing found instead.
Worked example
A problem statement that carries a case, from a fictional practice scenario
Northstar Systems is a fictional mid-size software company used here as a practice case. A problem statement built from it reads: “Tier-1 support agents resolved 61 percent of refund tickets correctly on first response against a 90 percent standard, producing 31 escalations a quarter. The analysis found three causes: newer agents could not locate the two-step policy check, the correct lookup took five clicks from the ticket screen, and handle-time scoring penalized the agents who did it right. The training response below addresses the first cause; the tooling and scorecard recommendations that address the other two are included in the analysis document.” Two sentences of evidence, one sentence of honest scope. A reviewer who reads nothing else now knows this candidate diagnoses before building.
No client work is not the obstacle it looks like
Career changers stall on a false premise: that a portfolio requires employer-sanctioned projects, and that everything else is pretend. Reviewers do not actually hold that standard, and the alternative to practice work is usually worse: real client work you cannot legally show. Which practice project to build first depends on where you are coming from; the career path guide maps each starting profession to the evidence reviewers will doubt and the project that answers it.
Real workplace experience still belongs in the portfolio when you can use it. Teachers, trainers, HR practitioners, and subject-matter specialists usually have more raw material than they think: a process you documented, an onboarding you redesigned, a session you ran repeatedly and improved. The rule is permission and de-identification. Get written permission for anything produced for an employer, strip names and figures that are not yours to publish, and when permission is not available, rebuild the case as an explicitly labeled reconstruction with the sensitive material replaced.
The 30-check screening list
These are the checks a screening reviewer applies, mostly without naming them, grouped by the order in which failures actually eliminate candidates. Five checks on identity and access, eight on case-study structure, seven on artifacts, five on writing, and five on accessibility and polish. The full list with pass conditions ships in the CSV below; the categories and the checks most portfolios fail:
| Category | The checks most portfolios fail |
|---|---|
| Identity and access | The portfolio link is broken, password-walled, or unreadable on a phone; confidential material appears without permission |
| Case-study structure | Cases open with the tool instead of the problem; no decision is ever explained with its rejected alternative; results claim outcomes nothing measured |
| Artifacts | No analysis document exists anywhere; artifacts have no captions saying what they prove; nothing interactive can actually be clicked |
| Writing | Objectives use verbs nobody can observe; the file that proves communication skill contains typos |
| Accessibility and polish | Informative images have no text alternatives; body text fails WCAG 2.2 AA contrast; the strongest case is buried last |
The accessibility rows are not garnish. A portfolio is a work sample, and accessible practice is part of the work being sampled; a candidate whose own portfolio fails basic contrast and alt-text checks is making a claim about their build standards whether they intend to or not. The same discipline shows up inside artifacts: an eLearning storyboard whose columns include alt text and accessibility notes signals the habit better than a paragraph asserting it.
Portfolio screening checklistAll 30 checks with the reviewer’s question and a concrete pass condition for each, grouped by category. Score your portfolio against it before sending it anywhere; every check is written so a friend outside the field can run it for you.
CSV, 30 checksScoring yourself honestly
Run the checklist as a gate, not a tally. The identity and access checks are pass or fail: a single broken link can end a screening, so fix every one before weighing anything else. In the remaining categories, treat any failed check as a task with a named fix, and re-run the whole list after changes, because portfolio edits have a habit of breaking links and reshuffling order.
Then have one person outside the field run the same list. If they cannot find your strongest case, tell what you did on a team project, or read your objectives as concrete actions, a hiring reviewer will not either, and the reviewer will not email you about it. They will just move on.
A portfolio cannot produce an interview, an offer, or any hiring decision, and this page will not pretend otherwise; hiring runs on more variables than any document controls. What a portfolio built this way can do is narrower and worth the work: it stops being the reason you are screened out, and it gives every later conversation concrete evidence to stand on.