The Service Design Portfolio Checklist

Most portfolio advice is written for product and UX roles, and a surprising amount of it transfers badly. A service design portfolio is read by people looking for different evidence, and an elegant set of screens can leave a panel with no idea whether the person in front of them can handle an organisation. What follows is what the portfolio has to do, where strong work usually gets presented badly, and how to check your own before an interview rather than afterwards.

What a service design portfolio has to do that a UX one does not

A UX portfolio can succeed on craft. A coherent flow, a defensible interface decision, a before and after that a reader can see the sense of: the unit of work is the interface, and the interface can be shown. Service design's unit is the arrangement around the interface. The letters, the phone queue, the staff tool nobody outside the organisation ever sees, the eligibility rule, the handover between two teams who have never met. Very little of that photographs well.

The second difference is consequence. Changing a screen has a mostly contained effect. Changing a service moves work around: effort taken off the person applying often lands on somebody backstage, and a step removed from one team reappears as an exception another team now has to handle. Panels are listening for whether the candidate noticed where the work went.

The reader is not asking whether the work looks good. They are asking whether you understood the organisation you were working inside.

What a reader is trying to work out in the first five minutes

Three questions, roughly in this order. Did this person understand the organisation. Did they make a decision, and can they evidence why it was that decision rather than the obvious alternative. And did anything actually happen afterwards.

Understanding the organisation shows up as naming constraints honestly: who funds the service, who absorbs the extra work, which rule is legislated and which is merely habit, which of the three teams involved was never in the room. A case study that describes an organisation as a neutral backdrop reads as untested, because organisations are not neutral backdrops and everyone on the panel knows it.

The third question is the one most portfolios never answer. They stop at the deliverable, as though the blueprint were the outcome. Say what was adopted, what was quietly dropped, what broke, and what you would do differently. If you left before finding out, say that plainly. An honest "I do not know what happened to it after I rolled off" is stronger than an implied success nobody can verify.

Three ways strong work gets presented badly

The first is the wall of maps. A beautiful blueprint, a journey map, an ecosystem map, all clearly the product of real effort, and no decision attached to any of them. A map is a working artefact, not a result, and on its own it evidences competence with a template rather than judgement. Every artefact in a portfolio should be followed by a sentence in the shape of "because of this, we did X instead of Y". If no such sentence exists, the map is decoration.

The second is the case study with no constraint in it. It reads as if the team had unlimited time, complete access and the authority to change anything, which is not what the job is and not what the panel is hiring for. Name the constraint and what you did inside it: three weeks, no access to frontline staff, a legacy system that could not be touched this year, legislation that was not going to change. Working well inside a constraint is the skill being assessed.

The third is work that cannot be shown at all, because it sat under an NDA. This is common and it is solvable, though not by ignoring it. You can almost always describe the shape of a problem without the identity attached to it: characterise the organisation by type and scale, redraw artefacts yourself in a neutral style with invented content, label them clearly as reconstructions, and spend the space on your reasoning rather than on the deliverable. What you must not do is show real client data, or let a redrawn artefact pass as the original.

If most of your work is restricted, build one thing that is not. A study of a public service you can use from the outside, a piece of volunteer work, or a properly researched teardown with a real recommendation will carry an interview further than a redacted case study.

What is in the checklist, and what it will not tell you

The checklist runs in five sections that follow the way a case study is read rather than the way it was made. Framing covers the organisation, the problem and the constraint. Evidence covers what you did and who you spoke to. Decision covers what you chose, what you rejected and why. Consequence covers what changed, for whom, and what you know about what happened next. Presentation covers structure, length and what an interviewer can find in the first two minutes without your narration.

Each item is a question you answer with yes, no, or not honestly enough. The last of those three is the useful one, and it is where most experienced practitioners land on at least a few items.

There is a limit worth being clear about. The checklist cannot tell you whether the work was good. It tests whether the work is legible, which is a different property, and a genuinely excellent project described badly will fail items that a modest project described well will pass. It is also written with mid-level and senior hiring in mind. Graduate and career-change portfolios are read with different expectations, weighted towards reasoning and appetite rather than delivered consequence.

How to use a checklist properly

Use it as a diagnostic a fortnight before an interview, not as a scorecard the night before. The output is not a score. It is two or three specific things to fix, chosen because they are the gaps most likely to be probed by someone who reads portfolios for a living.

Scorecards produce a particular kind of failure. Optimising to satisfy every item gives you a portfolio where each case study carries an obligatory constraints paragraph and an obligatory outcomes paragraph, none of which is quite true, and panels recognise that pattern quickly. Failing an item is information rather than a verdict. Sometimes the right response is not to change the portfolio at all, but to prepare an honest sentence to say out loud when the question comes.

Run it first against the project you would choose to talk about if the panel let you choose. That is where the gaps are least expected and cost the most.

Where to start

Take that one project and rewrite its framing and its decision before you touch anything visual. Say what the organisation was, what constrained it, what you chose, and what you turned down. Most portfolios are lost in the first paragraph of the first case study rather than in the quality of the maps that follow.

A portfolio in this field is not a gallery of what you produced. It is an argument that you can be trusted with a complicated organisation, and the evidence for that argument is mostly in the reasoning you show, not the artefacts you attach.

Download: ✅ The Service Design Portfolio Checklist