Consent, Portfolios, and the Project That Never Shipped
A designer spent five months volunteering with a refugee-settlement NGO, building a resource finder covering housing, language classes, and legal aid. During interviews, participants described their immigration status, and one showed a court letter on camera. The project was never formally launched - the NGO ran out of funding - but the research produced strong findings. The designer is applying to a health-tech company and has four projects to draw on: the refugee project; a six-month accessibility overhaul of a hospital booking system that shipped, with measured results; a two-week design sprint that was cancelled; and a speculative AR concept with polished visuals but no users. The NGO's agreement with participants said data would be used "for the project" and did not mention public sharing.
1. What do you do with the research artifacts, and how do you reason about it?
Read the worked answer
Start from the consent, not from the portfolio. The agreement covers use "for the project" and says nothing about public sharing, which means public sharing is not covered - silence is not permission. The participants are also in a situation with a real power asymmetry: a newly arrived person may not feel able to refuse a volunteer who has been helping them, so a casual "is it okay if I show this?" is not meaningful consent.
The artifacts split into two categories:
- Never publishable under any circumstances: the court letter, faces, names, case numbers, addresses, and anything describing immigration status. The harm is not hypothetical - status information can create legal jeopardy for the person who shared it.
- Publishable with fresh, specific consent: de-identified quotes and findings. This requires re-contact through the NGO, a plain-language explanation of exactly where the material will appear, and a genuine option to decline without consequences. If re-contact is impossible, the answer is no.
What remains fully usable: the process and the findings. The designer can describe the research question, the method, the number of interviews, the themes, and the design decisions - illustrated with recreated mockups using fictional content. Consent governs the artifacts, not the learning. Describing the ethical reasoning itself is also strong portfolio material: it demonstrates judgement, which is what a hiring manager is actually assessing.
2. Which project should lead the application for a health-tech role, and how would you structure the case study?
Read the worked answer
Lead with the accessibility overhaul of the hospital booking system. It wins on three axes simultaneously: it shipped (so the work survived contact with engineering), it has measured results (so impact is demonstrable rather than asserted), and it is directly adjacent to the employer's domain - clinical settings, accessibility, and regulated environments. Hiring managers are risk-averse; a shipped project in their sector reduces their risk.
Structure, roughly six to eight screens:
- Context and constraints - team, timeline, the regulatory or contractual requirement, what could not change.
- Problem - evidence, with the specific failures found, not "the experience was poor".
- Your role - precise about what you did and what others did. Overclaiming is the most common portfolio failure.
- Process, selectively - one or two artifacts per stage, not a process dump. Show the research that changed your mind.
- Key decisions and trade-offs - ideally one where you chose depth over coverage and can explain why.
- Outcome - the numbers, plus what you would do next.
- Reflection - one thing you would do differently, with a reason.
Order the rest: the refugee project second, framed around research depth and ethical practice; the cancelled sprint behind it as evidence of facilitation under ambiguity; the AR concept last or on a separate visual page, clearly labelled as exploratory. A polished render with no users is a liability if it leads.
3. How would you answer "tell me about a time you had to make a difficult trade-off" using one of these projects?
Read the worked answer
Use the accessibility overhaul, and tell it as a story about scope reasoning rather than about heroism. Structure it in situation, task, action, result - but spend most of the time on the decision, because that is what the question is testing.
Situation: A hospital booking system failed accessibility audits; 40 screens had issues, and the team had one quarter and two engineers.
The trade-off: fixing all 40 screens shallowly, or fixing the highest-risk journeys properly and leaving the rest on a documented, funded plan. The temptation was to spread effort to make the audit list look shorter.
Action: Used task frequency and clinical risk to rank the flows, found that three journeys carried most of the bookings, and proposed fixing those to completion while logging the remainder with owners and dates. Socialised it with the accessibility lead and the engineering manager before committing, so the decision was shared rather than the designer's alone. Wrote down what was deliberately deferred and why.
Result: The three journeys passed audit, and task completion for the primary booking flow improved measurably; the remaining screens had a funded backlog instead of an unfunded problem.
Reflection: Would have instrumented the flows earlier, because the baseline had to be reconstructed after the fact - a lesson that has changed how the next project starts.
Two traps to avoid: saying "we" throughout, which hides your contribution, and presenting a trade-off with no cost - if nothing was given up, it was not a trade-off.