The project looks excellent inside a laptop mockup.
So excellent, in fact, that the laptop is sitting beside a plant, a notebook and what appears to be a carefully selected artisanal rock.
I enjoy good presentation. A prospective client still needs to understand what the team did and why it mattered.
NN/g’s research on UX portfolios concerns hiring rather than agency purchasing. I think its emphasis on showing the reasoning behind finished work also offers a useful lens for a service business’s case-study pages.
Consider a hypothetical portfolio entry for a custom commerce project. Here is how I would make that page more informative without turning it into a project archive.
Give the reader something to recognize
The opening should identify the type of business problem and the team’s contribution. A visitor looking for help with a similar issue can then decide whether to read further.
Suppose the project involved customer-specific purchasing rules and a connection to an existing back-office system. Say that plainly. “A complete digital transformation” leaves the reader with rather a lot of imaginative labor.
Keep the explanation brief enough to understand before the first detailed screenshot. Include the team’s actual role and credit other contributors where relevant.
Use a constraint to explain a decision
A useful case study can show why the chosen approach suited the situation. Perhaps the business needed to preserve a familiar staff workflow or continue using an established system.
Explain the relevant constraint and the decision it shaped. That gives the reader evidence of judgment.
Do not invent a dramatic obstacle because every case study seems to require one. An ordinary requirement handled thoughtfully can be more useful than a heroic narrative in which the previous website is cast as a minor weather disaster.
Image-led sites live or die on how the photography is handled. See the digital showroom we built for Cavastone.
Let each image demonstrate something
A screenshot should have a job. It might show how an account-specific price is presented, how staff inspect an exception or how the mobile navigation organizes a large catalog.
Add a caption connecting the image to that decision. If the relevant detail is tiny, use a suitable crop or a clearer view.
Show only information approved for public use, with private records and credentials removed. A real project does not require real customer details to make its point.
A short sequence can explain a workflow better than several nearly identical full-page images. Choose the views that help the reader understand the change.
Pairs well with Interactive articles should let the reader learn something, not earn a badge for clicking.
Describe the outcome at the level the evidence supports
If the project has measured results that can be shared, explain what was measured, over which period and under what conditions.
If those measurements are unavailable, describe the verified deliverable or observed behavior instead. An implemented integration, an editable content structure or a working approval flow can be meaningful outcomes without an invented percentage.
Separate those facts from intentions. “Designed to reduce repeated data entry” and “reduced data entry by a measured amount” make different claims.
| How to word it | |
|---|---|
| A measured result | Say what was measured, over which period and under what conditions |
| A verified deliverable | An implemented integration, an editable content structure, a working approval flow |
| An intention | “Designed to reduce repeated data entry”, not “reduced data entry” |
| Work in progress | Label previews and planned features apart from what has launched |
Also keep work in progress identifiable. A preview, a planned feature and a launched workflow belong to different stages of the story.
The next step should relate to what the reader has just seen. A link to the relevant service or a clear invitation to discuss a similar requirement is enough. They do not need to emerge from the case study into an unrelated wall of every capability the business has ever considered.
For a final review, ask someone unfamiliar with the project to explain the problem, the team’s role and one important decision after reading the page.
If they can do that, the case study is beginning to show how the team thinks. The rock beside the laptop can remain. It just should not be carrying the explanation.