By the end of the lesson, you can turn the course project into a portfolio case in which the process, your own role, the evidence, and the lessons are all visible. You understand that reflection is not self-justification or self-criticism, but an analysis that helps the next professional decision.
Why is a portfolio case different from a presentation?
A presentation is live, aimed at a given audience, and you are there to explain. A portfolio case is readable on its own: a future employer or client skims it in a few minutes, and you are not there to be asked. So it needs more context, a more precise description of your role, and a clearer structure. The portfolio case is the written, standalone version of the design story, supplemented with your own role.
What makes a good portfolio case?
A portfolio case is a professional case study presenting the problem, process, decisions, and result of a project. Be precise about your own role. Even in an individual project there can be external rules, sources, or participants; in teamwork it is especially important not to attribute to yourself a decision that someone else made. Also describe the time, technical, and research constraints, because these give the real context of the decisions.
Suggested structure of a case description
Context, role, and project constraint: what kind of project it was, how much time, what your role was.
User problem and goal: the problem statement and the success criterion.
Research and insights: method, number of participants, the main insights.
Design process, key decisions, and prototype: the most important ones from the decision log.
Test, iteration, and result: observations, changes, the result with the limitations.
Lesson, open question, and next step.
In each section, give one or two strong, checkable examples rather than a general claim. Anonymize the participants, and do not publish sensitive data or screenshots without permission.
Length and tone
A good portfolio case can be read through in 3–5 minutes. Short sentences, headings that state the claim ("The card answers three insights"), images with captions. The tone is factual, in the first person ("I made this decision"), but not boastful.
Reflecting on the basis of evidence
Professional reflection is a concrete, evidence-tied interpretation of decisions and the learning process. Good reflection is concrete: "In the research I asked about a surface solution too early, so the first insights were weak. In the later interviews I asked about past examples, so I understood the decision situation better." This is interesting not for the sake of admitting a mistake, but because it shows how the way of working changed.
A simple frame for reflection:
What happened? (facts, evidence)
What did I learn from it? (a concrete lesson)
What would I do differently, and how? (a practical next step)
Do not write "next time I would do everything better". Choose one or two high-impact lessons, and name the next practical step. It can be earlier testing, more targeted participant recruiting, an accessibility check, or earlier consultation about a technical constraint.
Worked example: the portfolio case of Mai program
A student designed Mai program. In the first version the focus was on the map, but the research showed that the registration requirement and the missing price caused the greater uncertainty. The portfolio case does not claim that they "redesigned the map", but shows the insight, the change of the card, the test observation (1/4 → 3/3, on a small sample), and that error handling requires further examination. This is more credible than a final product presented as flawless.
Reflection: "In the first interviews I asked about the map too early; because of that, little usable data came from the first two interviews. Next time I will prepare the interview guide in advance and run a pilot interview."
Common misconceptions
Claim
Clarification
"In a portfolio only the beautiful final result counts."
The employer is looking for your thinking and your decisions.
"Reflection is self-criticism or praise."
It is a concrete, evidence-tied interpretation that helps the next decision.
"I can call teamwork my own."
Always mark your own role precisely.
In brief
A portfolio case is a standalone case study: problem, process, decision, result, own role.
A few strong, checkable examples are worth more than many general claims.
Reflection is concrete: facts, lesson, next step.
Anonymize, and do not publish sensitive data.
Review questions
What can a reader learn about you beyond the final screens?
Which constraint influenced your most important decision?
Which concrete lesson would change the first week of your next project?
Portfolio case and reflective closing
Objectives
By the end of the lesson, you can turn the course project into a portfolio case in which the process, your own role, the evidence, and the lessons are all visible. You understand that reflection is not self-justification or self-criticism, but an analysis that helps the next professional decision.
Why is a portfolio case different from a presentation?
A presentation is live, aimed at a given audience, and you are there to explain. A portfolio case is readable on its own: a future employer or client skims it in a few minutes, and you are not there to be asked. So it needs more context, a more precise description of your role, and a clearer structure. The portfolio case is the written, standalone version of the design story, supplemented with your own role.
What makes a good portfolio case?
A portfolio case is a professional case study presenting the problem, process, decisions, and result of a project. Be precise about your own role. Even in an individual project there can be external rules, sources, or participants; in teamwork it is especially important not to attribute to yourself a decision that someone else made. Also describe the time, technical, and research constraints, because these give the real context of the decisions.
Suggested structure of a case description
In each section, give one or two strong, checkable examples rather than a general claim. Anonymize the participants, and do not publish sensitive data or screenshots without permission.
Length and tone
A good portfolio case can be read through in 3–5 minutes. Short sentences, headings that state the claim ("The card answers three insights"), images with captions. The tone is factual, in the first person ("I made this decision"), but not boastful.
Reflecting on the basis of evidence
Professional reflection is a concrete, evidence-tied interpretation of decisions and the learning process. Good reflection is concrete: "In the research I asked about a surface solution too early, so the first insights were weak. In the later interviews I asked about past examples, so I understood the decision situation better." This is interesting not for the sake of admitting a mistake, but because it shows how the way of working changed.
A simple frame for reflection:
Do not write "next time I would do everything better". Choose one or two high-impact lessons, and name the next practical step. It can be earlier testing, more targeted participant recruiting, an accessibility check, or earlier consultation about a technical constraint.
Worked example: the portfolio case of Mai program
A student designed Mai program. In the first version the focus was on the map, but the research showed that the registration requirement and the missing price caused the greater uncertainty. The portfolio case does not claim that they "redesigned the map", but shows the insight, the change of the card, the test observation (1/4 → 3/3, on a small sample), and that error handling requires further examination. This is more credible than a final product presented as flawless.
Reflection: "In the first interviews I asked about the map too early; because of that, little usable data came from the first two interviews. Next time I will prepare the interview guide in advance and run a pilot interview."
Common misconceptions
In brief
Review questions