2learn

Portfolio Building

What it is

A portfolio is a small number of case studies showing how you think: the problem, the constraints, the options you considered, what you decided and what happened. Screenshots are evidence of output; a case study is evidence of judgement.

Why it matters

The reader is trying to answer one question: would this person make good decisions on my team? A gallery of finished screens answers a different question — whether you can produce polished work — and says nothing about whether you can choose what to build, handle constraints or notice when you were wrong. The second question is the one that gets someone hired, promoted or referred, and it is the one most portfolios leave unanswered.

Core ideas

One case study, five parts

Context and goal, constraints, options considered, decisions and why, outcome with the numbers you have. A page each; three is a portfolio.

Café order app — repeat orders
Goal        cut repeat-order time; 22% of repeat orders abandoned
Constraint  one developer, 6 weeks, no changes to the payments provider
Options     saved cards, remember details without storage, reorder shortcut
Decision    reorder shortcut only: no storage question, 3 weeks
Outcome     abandonment 22% -> 14%; the storage option stayed on the list

The constraint and the option not taken are the parts that show judgement.

Show the thinking, not only the result

Include the rejected option and one thing you would do differently. A case study where everything worked reads as marketing and tells the reader nothing about how you behave when something does not.

Quantify with whatever you honestly have

If you have no analytics, say what you observed and how. “Three of five test users missed the button” is a number; “it went well” is not.

Write for the reader’s thirty seconds

Lead each case study with one sentence naming the problem and the outcome, so a skimming reader gets the shape before deciding to read on.

Keep it current and small

Three recent case studies beat fifteen old ones. Delete anything you would not want to be asked about in an interview.

Practice

Write one case study

Take a project you worked on and write the five parts in one page, including the option you rejected and one thing you would do differently.

Done when: someone who was not involved can say what you decided and why, and what you would change today.

Have someone skim three and report back

Ask a colleague to spend thirty seconds per case study and tell you what they think you are good at.

Done when: their answer matches the judgement you wanted to demonstrate, or you have rewritten the case study that missed.

Common mistakes

  • A gallery of screenshots — it shows output, not judgement; fix: write case studies with the decisions in them.
  • Only successes — the reader cannot see how you handle a wrong call; fix: include what you would do differently.
  • No constraints stated — the work reads as unconstrained and therefore unimpressive; fix: name the time, budget or technical limits.
  • Unquantified outcomes — “it went well” carries no information; fix: use whatever honest measure you have and say what it was.
  • Fifteen outdated projects — the reader cannot find the good ones; fix: keep three recent ones and delete the rest.

Go deeper

Worked examples

Analytics cookies are set only if you allow them. Nothing is loaded, and nothing is sent, until you choose.