Begin with the work someone cannot yet perform
A team keeps receiving service requests with missing information. Before building a training course, ask what is causing the problem. Staff might not know which information to provide; the request form might be unclear; or the required information might be unavailable. Training can address a knowledge or skill gap, but it cannot automatically fix a broken workflow.
BLS describes training-and-development work that includes assessing needs and developing learning materials. CDC's design resources also focus on defining learning objectives that can be assessed. Use those ideas to frame a practical sample: identify a learner, a task and an observable standard, then design the smallest learning experience that addresses the problem.
Search instructional design intern, learning experience design intern, learning and development intern and customer education intern. Inspect whether the role emphasizes analysis, storyboarding, e-learning production, facilitation or administration. A job mainly scheduling sessions differs from one building interactive lessons. Both can be useful, but your portfolio should demonstrate the work the specific team needs.
Write an objective that changes the design
For this fictional module, the learner is a new employee submitting a maintenance request. The target is not to understand the request process. A more useful objective is to produce a request containing the location, observed issue, time noticed and appropriate contact details, using the approved fictional form. The learner should also know which situations require the organization's separate urgent-reporting route.
That objective tells you what to include and what to remove. A history of the facilities department is unlikely to help the learner complete the task. A worked example, a missing-information scenario and feedback on a practice request are more directly useful. A short reference card may support later performance better than forcing the learner to replay a long module.
Use an approved brief in real work. Do not invent an employer's reporting policy or safety instructions and present them as authoritative training. In the portfolio, identify the policy and scenarios as fictional. The sample demonstrates your design decisions, not your authority to determine how actual employees should respond to a real incident.
Build a storyboard around decisions and feedback
Create a seven-screen storyboard. The first screen introduces the task and its context. The second shows a complete request. The third asks the learner to identify missing information in a weak request. The fourth gives specific feedback. The fifth asks the learner to construct a request from a new scenario. The sixth provides a job aid. The seventh explains where to seek approved help and how the learning will be assessed.
On each screen, record the learner action, visible content, feedback and the reason the screen exists. A storyboard is not just a list of slide titles. It should make clear what happens when the learner chooses an incomplete answer and why the correction matters to the task. Avoid generic feedback such as incorrect; explain which missing field would prevent someone from locating or understanding the issue.
For example, a weak request says, 'The equipment is not working. Please fix it.' Feedback can point out that a technician cannot identify the location or the observed behavior. The revised version should report observable details rather than an unsupported diagnosis. This connects the lesson to an actual communication task without requiring the learner to become a maintenance expert.
Make the sample usable before making it elaborate
A simple HTML lesson or clearly linked slide prototype can demonstrate good instructional design. Use readable text, descriptive controls and meaningful feedback. Provide text alternatives for essential visual information and captions or transcripts when audio carries the lesson. Do not make an animation or a timed interaction the only route to understanding the task.
Test whether a person can navigate the sample, recover after a wrong answer and find the reference card. Record where they hesitate and what you change. If you test with three volunteers, describe it as a small usability check, not proof that the training is effective for every employee. Repeated attempts by the same person also need to be distinguished from new-user performance.
Keep the authoring tool secondary to the reasoning. A reviewer should understand your task analysis and feedback choices even without access to the original tool. Export a readable storyboard and a working view of the sample where possible. Screenshots of a course can show appearance, but they do not demonstrate that its interactions or assessment actually work.
Distinguish completion, learning and later performance
CDC's evaluation guidance distinguishes learning from transfer to the work setting and cautions against using participant reactions as a substitute for effectiveness. Apply that distinction to the fictional request module. Finishing the lesson, answering an assessment correctly and later submitting a complete real request are different observations. A satisfaction rating answers yet another question.
Suppose 60 employees are assigned the fictional training. Fifty-four complete it, 48 take the assessment and 36 meet its stated passing standard. Completion is 90% of assigned learners. Assessment participation is 80% of assigned learners. The pass rate among assessed learners is 75%, while 60% of assigned learners have demonstrated the passing result. Each number is correct when its denominator is stated.
Do not report only the 75% result as though it covers all 60 employees. Nor does it prove a 75% improvement caused by training. To investigate change, you need a relevant baseline and an evaluation design suited to the question. Missing assessment data remain missing; assigning nonparticipants a zero score may answer a different question from measuring demonstrated proficiency.
Sources[3]
Add a transfer check with a practical measurement rule
For a proposed follow-up, define a complete request using the same observable fields as the learning objective. Then describe how authorized staff would review a bounded set of later requests. Specify the period and whether you are counting requests, employees or first attempts. An employee who submits five requests should not quietly count as five independent people in a person-level claim.
Suppose a fictional voluntary follow-up includes 40 employees and 28 meet the criterion. That is 70% of the follow-up group. It is not necessarily the rate for all assigned learners because the volunteers may differ from those who did not participate. Keep the assessment and follow-up populations separate until you can legitimately link them through the evaluation design.
Your recommendation can still be actionable: investigate the most commonly missing field, revise the job aid and test whether the form itself needs a change. Training evaluation is useful when it identifies what should happen next, not only when it produces a favorable completion statistic. A small honest result can support a targeted improvement while leaving the larger causal question unresolved.
Submit the design rationale alongside the finished lesson
A strong internship portfolio contains the fictional brief, a task analysis, learning objective, storyboard, usable prototype and evaluation plan. Add a revision note explaining one design change after a usability check. Keep the final work easy to inspect; a reviewer should not need to create an account merely to read the rationale or see the sample's basic flow.
In your résumé, describe the deliverable you built and the test you actually ran. Do not convert planned evaluation into a measured performance improvement. If the assessment data are synthetic, say so. Your explanation of why you replaced a generic quiz with a realistic task can be more persuasive than a claim that you made training engaging without defining what that means.
Ask which audiences the internship serves, how subject-matter experts review content and how the team evaluates success. Customer education, employee onboarding and technical training can have different constraints. Bring a sample that demonstrates you can turn those constraints into clear objectives, practice and feedback, rather than treating every learning problem as an invitation to add more slides.