Krushna Palwe

Open to senior roles & select freelance

Let’s talkHelp & contact

KRUSHNA PALWE

Website guide

Automated help, with a human next step.

A GOOD PLACE TO START

A little clarity.
Your next move.

Find the right service, explore the work, or plan your next project.

Or ask about

Answers from this website. Quotes come from Krushna.

How to Structure a Design Portfolio Case Study Recruiters Can Scan

A case study structure for designers that recruiters and clients can scan: problem, role, thinking, system, execution, outcome, with honest labelling of mockups.

Editorial diagram of six scannable case-study chapters from summary and role through system and outcome

A recruiter or hiring manager opening a portfolio is rarely reading. They are scanning for three things: what you did, how you think, and whether the work is real. Most case studies hide those answers under long process narratives and beautiful mockups. A clear design portfolio case study structure puts them where a scanning eye lands.

I rebuilt my own portfolio around one structure that works for very different projects: a SaaS brand system, packaging, an Amazon listing set, a motion library. These are the parts, and why each exists.

The summary block comes first

Before any chapter, give the reader a block they can understand in ten seconds:

  • One sentence describing the project and the result in plain words.
  • Two headline counts of what you produced, such as "1 token system, 3 product identities" or "400+ base templates, 10,000+ educational graphics".
  • Role, scope, timeline and tools as short labelled facts.
  • A live link if the work is public.

Counts of your own deliverables are useful and verifiable. Performance claims are different. If you cannot source a percentage, a time saving or a revenue figure, leave it out. A recruiter who doubts one number will doubt the rest.

The six chapters

My longer case studies follow the same chapter order: problem, role, thinking, system, execution, outcome. Shorter ones drop chapters, but the order stays the same, so a reader who has seen one case study knows where to look in the next.

Problem

Describe the situation in the client's terms. What was wrong, and why did it matter? At Datamotive the problem was one company reading as three: different type weights, decks on incompatible grids, diagrams with arbitrary colour. For a buyer evaluating disaster recovery, inconsistency reads as risk. Keep it to a short paragraph and one or two before images.

Role

State exactly what you did and what you did not do. "Sole designer" means something different from "led a team of four". If you directed implementation rather than writing code, say that. On BLANKSY I describe directing the implementation using AI-assisted development workflows while defining the system and reviewing the build. Precise role statements protect you in interviews, because every claim on the page is one you can defend.

Thinking

Show the key decision, not the whole process. One insight that changed the direction is worth more than ten sticky-note photos. At iSequalTo the reframe was that a curriculum outpacing its illustrators was not a creativity problem but a systems problem.

System

Show the rules behind the work: tokens, grids, type ramps, templates, pack structure. This is the part that separates a designer who makes assets from one who makes systems, and it is the part many portfolios skip.

Execution

Now show the work itself, ideally in the context where it lives. Group pieces by type and caption each one with what it is.

Outcome

Close with what changed, using only facts you can support, and add a short "what I would do differently". Reflection signals seniority. My Datamotive case ends with the lesson that brand language should have started in week one. The CITTA packaging case ends with the lesson that the system should have been locked at the start, not six months in.

Label mockups and originals

Presentation mockups flatter work. A photographed carton or a phone in a hand adds polish that the real artwork may not have. Show the original artwork beside every mockup and label which is which. In my packaging case studies, every presentation mockup sits next to its print artwork, and a note states that the artwork is the reference for exact copy and dimensions.

If imagery was produced with AI, say so where it appears. Labelling AI-generated imagery covers how I handle that.

Handle confidential work honestly

Some of your best experience may be under NDA. Do not invent samples to fill the gap. List the role, the kind of work, the sectors and what it taught you, and state that samples are confidential. My AffinityX entry does exactly that: brochures, posters and social creatives for client accounts, with no artwork shown.

Make it scannable on a phone

Recruiters often open portfolios between meetings, on a phone. Check that:

  • The summary block fits on the first screen.
  • Chapter labels are visible as the reader scrolls.
  • Images can be opened large without pinching.
  • Text is readable at body size. See readable body text on the web.

Link the work to your thinking

Case studies show what you did. Writing shows how you think about the problems behind it. Linking each case study to one or two related notes, such as a note on template systems beside a template-heavy project, gives a reader a second route into your judgement.

A checklist before publishing

  • Can someone tell what you did within ten seconds?
  • Is your role stated precisely?
  • Are all numbers either counts of your own work or sourced?
  • Is every mockup labelled, with the original nearby?
  • Is there one clear insight in the thinking chapter?
  • Does the case end with an honest reflection?

You can see the structure applied to a full SaaS system in Datamotive, a template pipeline in iSequalTo, and print artwork beside mockups in CITTA Packaging.