A case study is a claim. It says: this problem existed, I did something about it, and here is what changed. Most portfolio pages make that claim with confident typography and a tidy before-and-after. Credibility is a different thing entirely. It comes from the small, unglamorous evidence a reader can check — the brief you were handed, the notes you scribbled in week one, the option you rejected, the number that only moved a little. The good news is that credibility is a set of habits rather than a secret. Show enough of the working and a reader stops suspending disbelief and starts trusting you.

Begin With a Problem You Didn't Invent

The strongest opening line in a case study is usually borrowed. Paste in the sentence a client actually wrote: the checkout drops off on mobile and we can't work out why. Or the ticket title, or the line from the handover document. Suddenly the project has a source outside your own imagination, and the reader knows you were responding to something real.

If the work was self-initiated, say so in the first paragraph. "Self-initiated concept, no client involved" costs you nothing. Implying client work that didn't happen costs you everything the moment someone asks a follow-up question. Readers forgive ambition; they don't forgive fog.

Name the other people in the room, too. A developer who pushed back on the layout, a copywriter who rewrote your headings, the stakeholder who signed off. Claiming solo credit for team work reads badly, not because collaboration is shameful but because anyone who has shipped anything recognises the omission.

Artifacts Beat Adjectives

"I conducted user research" is a sentence. A photograph of forty stickies on a wall, with the three that changed your mind circled in marker, is evidence. The gap between those two things is where most case studies lose their reader.

You do not need a documentary. Three or four well-chosen artifacts are enough to make the process feel inhabited:

• A photo or export of raw notes, with a visible date
• Two sketches from before the polished version existed
• A screenshot of the working file with version history showing
• A redacted message thread where a decision was genuinely argued out
• The test script, the QA checklist, the accessibility notes
• The content inventory — especially when it is ugly

Redact what you must. Client names, revenue figures, anything under an NDA. But be aware that redaction has a cost: strip out too much and the page reads like a template with the nouns changed. Keep the texture even if you have to change the specifics.

Constraints Make the Story Believable

A case study with no constraints reads like fiction, because every real project has them. Three weeks instead of three months. A legacy CMS that couldn't do the layout you wanted. A brand guideline last updated in 2014. A legal review that killed the animation you loved. A stakeholder who simply did not want the navigation moved.

Naming those pressures does two things. It shows you worked inside reality rather than a mood board, and it gives the reader a way to measure your decisions against the conditions you faced. Designing a clean dashboard with unlimited scope is a different achievement from designing one in a fortnight with a fixed component library. Only one of those stories is interesting, and it is the constrained one.

Be specific about the cost. "Limited budget" means nothing; "the client had budget for one round of testing, so I combined the usability sessions with the stakeholder review" tells me how you think.

Decisions Are the Real Content

Screenshots show what you made. Decisions show how you think, and that is what someone hiring is actually trying to assess.

Find the fork in the road

Every project has two or three moments where the work could have gone another way. Lay them out plainly: here were the options, here is what I picked, here is why. Two alternatives is usually enough. Three is plenty. If you can show a rough wireframe of the path you didn't take, better still — it proves the choice was a choice and not the only thing you knew how to build.

Say what it cost

Honest trade-offs are persuasive. "We shipped the simpler flow because the development team had three weeks before a trade show" tells the reader you understand that shipping is a negotiation, not a purity test. "I chose the more conventional pattern here because the audience was older and the client's support team had no capacity for a new interaction model" is the kind of sentence that makes a senior reader nod.

Then include one line of self-critique. What would you do differently, and why? A single paragraph of genuine reflection buys more trust than another page of mockups, largely because it is the thing a dishonest portfolio cannot fake.

Results That Survive a Follow-Up Question

Any number can be printed. A number that holds up under questioning needs three things attached: a baseline, a time window, and an honest caveat.

Mobile checkout completion moved from 2.1% to 3.4% over the six weeks after launch. Traffic mix stayed steady, but a pricing test ran during weeks three and four, so treat the size of the lift as approximate.

That sentence is more convincing than a headline percentage, because it volunteers its own weaknesses before anyone asks. If other things changed at the same time — a campaign, a seasonal spike, a new support policy — say so. Readers who work in the field will assume it anyway, and the ones who don't will trust you more for mentioning it.

When you cannot publish figures, describe the shape of the change and explain the silence. "The client asked me not to share numbers; what I can say is that the support team stopped escalating the same three questions within a month." That is still a result. So is shipping on time, or handing over a component library the in-house team actually used six months later.

Red Flags Readers Notice Immediately

Some signals do damage faster than any amount of good writing can repair:

• False precision — a figure like 37.4% with no source, baseline or date
• Results described as a lift with nothing to lift from
• Stock photography standing in for user research
• No mention of other people, as if the work appeared fully formed
• Dates that contradict the timeline on your CV or profile
• Perfect outcomes with no friction, delay or compromise anywhere

None of these are fatal on their own. Together they suggest a story assembled after the fact rather than documented during it.

A Short Audit Before You Publish

Keep an evidence file while you work, not afterwards. A folder per project with the brief, the dated notes, the rejected versions and the final measurements will make writing the case study a matter of selection rather than reconstruction.

1. Hand the draft to someone outside your field and ask them to repeat back the problem, the main decision and the result.
2. For every claim, check whether an artifact on the page supports it. Where it doesn't, either add the artifact or soften the claim.
3. Confirm every number has a baseline and a window, and that at least one caveat appears near it.
4. Read the self-critique paragraph aloud. If it sounds like humblebragging, rewrite it until it sounds like a person thinking.
5. Check the dates against your CV one more time.

Credibility is not a tone you adopt. It is the accumulated weight of things a reader could verify if they asked — and the visible sense that you would answer honestly if they did.

Photo: Jakub Zerdzicki / Pexels