Read the output behind the title
A UX research assignment may involve planning sessions, observing tasks, organizing evidence and explaining findings. A product-design assignment may involve information structure, interactions, interface states and a proposed solution. Teams often combine these tasks. CBRE’s technology internship, for example, lists a combined UX Design & Research track alongside other technical tracks.
Do not decide based only on whether the posting uses research or design in the title. Ask which outputs interns produce and which methods the team uses. A portfolio of polished screens may not demonstrate research planning, while a research report may not show how you resolve an interaction problem.
The project below lets you show both, with the boundary between observation and proposal made explicit. It uses a fictional study-room booking service and requires no real reservations or personal account access.
Sources[1]
Choose a question that a session can answer
Use this brief: students need to find and reserve an appropriate study room for a small group. Investigate whether they can find a room matching time, capacity and accessibility needs, understand whether it is available, and recognize when the reservation is confirmed.
Avoid a broad question such as whether users like the website. A user can like a design and still fail the task. Conversely, a participant may complete a task while finding the process frustrating. Decide which observations would change a product decision before collecting feedback.
GOV.UK’s moderated-testing guidance recommends tasks with clear, believable goals that do not reveal the solution. Apply that principle to an original task: “You need space for three people next Tuesday between 2 and 3 p.m. Find an appropriate room and show when you would consider it reserved.” Do not tell the participant which filter or button to use.
Sources[2]
Prepare a small protocol rather than improvising every session
Write an introduction explaining that you are testing the prototype, not the participant. Describe the fictional data and seek consent for any recording or notes. Let someone decline without needing to justify it. For a classroom project, follow the institution’s rules and use an approved, low-risk setup.
Prepare a few consistent prompts, the task, the success definition and follow-up questions. For this exercise, unassisted success requires finding a matching room and identifying a clear confirmation without facilitator instruction. Assisted completion is recorded separately. A screen that resembles a confirmation but has not committed the action should not count as success merely because the participant says done.
Pilot the task with a peer to find ambiguous wording. Then keep a record of any protocol change, because changing the instructions between participants can change what your observations mean.
Keep the observation separate from your interpretation
The following five records are fictional examples of how to write notes. They are not results of sessions conducted for this guide. Two show unassisted completion, one assisted completion and two noncompletions. You may report those counts for this exercise, but not a general success rate for all students.
| Participant | Observed behavior | Outcome | Question for the next iteration |
|---|---|---|---|
| P1 | Selected a matching room and read confirmation | Unassisted completion | Does the confirmation make cancellation clear? |
| P2 | Mistook a request screen for a completed reservation | Not completed | Would distinct pending and confirmed states help? |
| P3 | Needed the facilitator to explain the date control | Assisted completion | Which date labels were unclear? |
| P4 | Could not distinguish occupied from available slots | Not completed | Can availability be conveyed without color alone? |
| P5 | Completed the task using keyboard navigation | Unassisted completion | Does focus remain visible through every step? |
An observation should identify what happened. An interpretation proposes why. The next design question states what you would test. Keeping the three apart makes it easier to revise an explanation when later evidence conflicts with it.
Make a revision traceable to a problem
Choose one issue, such as confusing pending with confirmed, and propose a focused change. Show the original state, the revised state and the expected behavior. Explain the trade-off: an additional confirmation step might reduce mistakes but add effort. Your next test should examine whether the change resolves the actual confusion.
Do not claim a redesigned screen improved conversion before testing it. A recommendation, implemented prototype and observed outcome are different deliverables. Label an untested proposal as untested. If you later run another round, preserve the earlier tasks and explain any recruitment or protocol differences.
Include error, empty, loading and cancellation states when they matter to the task. A portfolio that only shows the happiest path leaves a reviewer unable to evaluate how the design handles ordinary uncertainty.
Present the chain from question to evidence to decision
A compact case study should contain the brief, task, participant approach, observation log, selected issue, revision and remaining questions. Keep participant information private and publish only material you have permission to share. Use fictional records where public disclosure would otherwise expose someone.
For a research-oriented application, explain why the task and sample address the question and what they cannot establish. For a design-oriented application, explain the interaction choice and the alternatives you rejected. Avoid a long research section that has no visible effect on the proposed design.
The strongest ending is an honest decision status: what was learned, what changed and what still needs testing. That gives an interviewer concrete decisions to ask about rather than a gallery of screens with an unsupported success claim.