A portfolio page has one job: to convince a stranger that you can be trusted with their problem. Images hint at that. Words prove it.

The project page, the case study, is where that proof lives, and it is usually the most neglected piece of a designer's site. Most read like a caption competition: a hero shot, a client name, a line about "clean, modern design". The structure below fixes that. It works for a brand identity, an app flow, a printed annual report or a single piece of packaging.

Start with the brief, not the reveal

Open with context, not the finished artwork. Two or three sentences is enough: who the client is, what they needed, and what made it awkward. "A six-person bakery in Leeds wanted to sell celebration cakes online without hiring a developer" tells a reader more than any mockup. It also sets up everything that follows.

Then add the constraint that shaped the work: a fixed launch date, a legacy system nobody was allowed to touch, a print budget that ruled out special inks. Constraints are where your judgement becomes visible. If there was genuinely no constraint, say what success looked like instead.

Aim for 80–120 words. If you are still describing the client's company history, cut.

Show your thinking — the part that gets you hired

Clients and hiring managers are looking for judgement, not software skills. The thinking section is where you show it, and it is almost always the shortest section on a real portfolio. Give it room.

Describe the routes you considered. Not every one, just the ones that mattered. Say what tipped the decision:

Two options were on the table: enlarge the type across the range, or cut the copy by a third. We cut the copy, because shoppers were reading labels at arm's length on a busy shelf.

Name the trade-offs out loud. Every decision costs something, and saying what you gave up reads as confidence rather than weakness. A warmer palette put the brand closer to its competitors; that was acceptable, because the photography was doing the differentiating.

Show one place where you changed your mind. Early sketches, feedback from a shop worker, a prototype that failed a simple test. A page with no wrong turns in it does not read as talent. It reads as fiction.

If you are staring at a blank page, work through these prompts:

• What were the two or three realistic options?
• What did you choose, and what tipped it?
• What did you give up to get it?
• What would you do differently now?

This section earns 250–350 words. If you cannot fill it, the project may not deserve a full case study. Give it a short entry in a grid instead.

Land the outcome without inventing numbers

Say what shipped and what changed. "The site launched in March with fourteen product pages" is a fact. "Engagement skyrocketed" is not.

If you have real figures, use them and say where they came from, for example the client's own order data. If you do not, qualitative outcomes still count: the team reused the template for three subsequent collections; the client stopped commissioning one-off illustrations; the report went to print two weeks earlier than the year before. Concrete beats impressive every time.

Be honest when a project was never built. Student work, pitches and personal projects are legitimate entries. Label them clearly and the reader will judge them on the right terms. Passing a concept off as live work is the one mistake that can cost you an interview.

Budget 150–250 words here.

Back it up with evidence

Every claim on the page needs something behind it. You do not need all of these, but pick the ones you genuinely have:

• A sentence from the client, in their words, about the work or the process.
• Before-and-after images shown honestly: same scale, same device, same lighting.
• Process artefacts, such as early sketches, wireframes, the rejected route or a type test.
• Figures with a source attached.
• Your role, named plainly, if the project was a team effort.
• Context on the constraints: timeline, budget band, number of stakeholders.

Keep this to 100–150 words of prose. Evidence sections should be the lightest writing on the page; captions do most of the work.

A word count that keeps you honest

These are guides, not rules, but they hold up across most projects:

• Brief and constraints: 80–120 words
• Your role: 40–60 words
• Thinking and decisions: 250–350 words
• Outcome: 150–250 words
• Evidence and captions: 100–150 words
• Reflection: 40–60 words

That lands somewhere between 700 and 950 words for a full case study, which is a comfortable ten-minute read with images. A small project can be done well in 400. What you must not do is pad a thin project to hit a number.

Mistakes that make a case study feel hollow

Most weak project pages fall into the same few traps, and each one has a quick fix.

• Opening with a mood board. Start with the problem instead; the visuals will land harder once the reader knows why they exist.
• "The client wanted something clean and modern." Everyone says that. Describe their customers, their shelf, their competitors.
• Listing tools. Naming your software is not the same as explaining your thinking.
• Hiding your part in a team project. State what you owned and what you contributed to.
• Forty images and no words, or a wall of text and no images. Alternate between them, and caption everything.
• Ending on "the client was very happy". Close with what changed, or with what you would do next time.

Before you publish

Read the page aloud. Anywhere you stumble, the reader will too. Then hand it to someone who knows nothing about the project and ask them to tell you what you did. If they cannot, the brief or the outcome is still too vague.

Check that every image has a caption, that the first sentence of each paragraph carries real weight, and that your role appears plainly near the top. Date the page, and revisit it once a year; a project you were proud of three years ago may need a line of context now. Then leave it alone, and go and make the next piece of work worth writing about.

Photo: JessBaileyDesign / Pixabay