Hur du skriver portfolio case studies som faktiskt ger dig jobbet, Del 2: Visa ditt tänkande

Del 2: hur du skriver case studies som visar ditt tänkande, inte bara slutskärmar. En mall du kan använda.

Det är här de flesta portfolios faller isär. Att skriva portfolio case studies som designer är färdigheten som skiljer ett galleri av skärmar från ett arbete som faktiskt ger dig jobbet.

Du kan ha vackra slutskärmar, en snygg portfoliosajt och en engagerande Om-sida, men om dina case studies inte visar hur du tänker lämnar du det viktigaste på bordet. Det här är Del 2 av portfolioserien. Om du inte har läst Del 1 om vad du bör inkludera och varför det spelar roll, börja där.

Varför case studies spelar ännu större roll i AI-åldern

Här är den obekväma sanningen: AI kan nu generera polerade UI-skärmar på sekunder. Vackra mockups, kompletta designsystem, pixelperfekta komponenter, det visuella resultatet blir allt svårare att skilja från mänskligt skapat arbete.

Vad AI inte kan göra är att förklara varför den fattade besluten den fattade. Den kan inte guida dig genom researchen som informerade ett färgpalettval. Den kan inte förklara användarinsikten som ledde till att ett navigationsflöde omstrukturerades. Den kan inte berätta om de tre riktningarna den utforskade och varför den dödade två av dem.

Dina case studies är beviset för att en tänkande människa står bakom arbetet. Ditt resonemang, din process, din beslutsprocess, det kan inte genereras. Det är det som ger dig jobbet. Starka portfolio case studies för designers visar resonemang, inte bara resultat.

Portfolio case studies: mallen som fungerar

Efter mycket iteration med mina egna projekt är det här strukturen jag använder. Inte varje avsnitt gäller för varje projekt, anpassa den till vad som är relevant.

1. Kroken

En mening eller fråga som fångar vad som gör det här projektet intressant. Inte ”Jag designade en app för X.” Mer som ”Hur gör man ekonomisk uppföljning motiverande istället för stressande?” Det här är det första någon läser. Gör det värt att stanna.

2. Översikt

Två till tre meningar som täcker vad projektet är, vem det är för och vad målet var. Snabb kontext så att läsaren vet vad de tittar på innan de dyker ner i detaljer.

3. Utmaningen

Vad gjorde det här projektet svårt eller intressant? Vilka begränsningar fanns? Vilken spänning behövde lösas? Det är här läsaren börjar förstå problemområdet, och det är vad som gör att de bryr sig om din lösning.

4. Research och discovery

Vad lärde du dig innan du designade något? Det kan inkludera användarinsikter, konkurrensanalys, branschkonventioner du studerade eller samtal med intressenter. Visa att dina designbeslut var informerade, inte godtyckliga.

För karriärbytare: om din research var informell (du observerade användare, du studerade konkurrentappar på egen hand, du använde din tekniska bakgrund för att förstå begränsningar) räknas det fortfarande. Rama in det ärligt.

5. Designprocess

Det här är kärnan i din case study. Inte varje steg, bara de intressanta besluten. Var pivotade projektet? Vad provade du som inte fungerade? Vilken feedback ändrade din riktning?

Ett kraftfullt angreppssätt: visa separationen mellan visuell riktning och strukturell design. Förklara att du utforskade utseende och känsla som en separat fas från användarflöden och informationsarkitektur. Det här visar en mogen designprocess och demonstrerar att du förstår att UI och UX är olika discipliner som kräver olika tänkande, även om de möts i slutprodukten.

Inkludera artefakter från processen: moodboards, wireframes, tidiga utforskningar, riktningsalternativ du presenterade. De är mer intressanta än slutskärmar för de visar ditt tänkande i action.

6. Nyckeldesignbeslut

Välj två eller tre specifika val och förklara varför bakom vart och ett. Det är här din expertis syns mest.

Bra exempel på designbeslut värda att förklara:

• Varför du valde en specifik färgpalett och vilken psykologisk respons den skapar hos målgruppen
• Varför du strukturerade navigationen på ett visst sätt baserat på användarbeteendemönster
• Varför du bröt mot branschkonventioner på ett ställe men följde dem på ett annat
• Hur en teknisk begränsning (något du förstod från din utvecklarbakgrund, kanske) påverkade ett designval
• Varför du minskade antalet steg i ett flöde och vad det innebar för konverteringen

Varje beslut du förklarar är bevis på att du tänker medvetet, inte bara estetiskt.

7. Slutlig design

De polerade skärmarna och det visuella resultatet. Presentera dem väl, mockups i hög kvalitet, konsekvent inramning, tillräckligt med kontext för att förstå vad du tittar på. Men motstå frestelsen att göra den här sektionen längst. Tänkandet som föregick skärmarna är mer värdefullt än skärmarna själva.

8. Resultat och reflektion

För riktiga projekt: mätbara resultat, klientfeedback, vad du skulle göra annorlunda. För konceptprojekt: vad du lärde dig, vad du skulle testa med riktiga användare, vilka antaganden du skulle vilja validera.

Ärlig reflektion läser som mognad. ”Om jag gjorde det här igen skulle jag ägna mer tid åt onboardingflödet” är mer imponerande än att låtsas att allt var perfekt, eftersom det visar att du kan bedöma ditt eget arbete.

Mallen ovan är åtta delar i en ordning. Men en rekryterare läser inte en case study som ett dokument uppifrån och ner, utan fattar en rad små beslut på vägen och hoppar av vid det första som inte håller. Så här ser den vägen ut, ritad som ett riktigt flöde.

Läsarens väg

Var ett case tappar sin läsare

Tre av fyra vägar genom ett case slutar utan att någon hör av sig. Det är sällan för att arbetet är dåligt, utan för att beslutet fattas innan läsaren kommit fram till det.

Öppnar ditt case

start

–

Läser de första raderna

krok

start

Förstår hen problemet på tio sekunder?

d1

krok

Stänger fliken

stang

d1

Nej

Letar efter research och metod

metod

d1

Ja

Finns belägg, eller bara påståenden?

d2

metod

Läser resten som en snygg bild

bild

d2

Påståenden

Läser besluten, och vad du valde bort

beslut

d2

Belägg

Ser hen hur du tänker?

d3

beslut

Sparar länken, hör aldrig av sig

arkiv

d3

Nej

Hör av sig

kontakt

d3

Ja

Ritat i samma komponent som jag använder i mina case. Dra i diagrammet för att panorera.

Hur lång bör en case study vara?

Tillräckligt lång för att visa ditt tänkande. Tillräckligt kort för att någon faktiskt läser den. Det är inte en undanflykt, det beror genuint på projektets komplexitet.

Några praktiska riktlinjer:

• Sikta på 5 till 10 minuters lästid. Mycket kortare och du visar förmodligen inte tillräckligt med tänkande. Mycket längre och du tappar läsare.
• Använd visuell hierarki aggressivt. Sektionsrubriker, citat, bildavbrott. Ingen läser en case study linjärt, de scannar, stannar vid intressanta delar och fördjupar sig selektivt.
• En flytande innehållsförteckning hjälper. För längre case studies, att låta läsare hoppa till sektioner minskar skrämselfaktorn av en lång sida.
• Inte varje sektion behöver samma djup. Gå djupt på de delar som var mest intressanta eller utmanande. Sammanfatta de raka partierna.

Brain dump-metoden

Brain dumpen är sällan snygg. Den ska vara fullständig, inte presentabel.

Att skriva case studies kan kännas överväldigande, särskilt när du stirrar på en blank sida. Här är metoden som fungerar för mig:

Steg 1: Dumpa allt. Öppna ett dokument och skriv ner varje enskild sak du minns om projektet. Organisera inte, filtrera inte, bara få ut allt. Beslut, utmaningar, feedback, pivotar, saker som fungerade, saker som misslyckades.

Steg 2: Sortera i sektioner. Ta brain dumpen och börja lägga saker i mallens sektioner. Du ser snabbt vilka sektioner som är rika på material och vilka som är tunna.

Steg 3: Skriv berättelsen. Nu förvandla de sorterade anteckningarna till faktisk text. Fokusera på ”varför” bakom allt. För varje faktum eller beslut, fråga dig själv: varför hände det här? Varför valde jag det här? Vad var alternativet?

Steg 4: Samla det visuella. När det skrivna innehållet är solitt, lista ut vilka bilder, mockups, wireframes och processartefakter som ska inkluderas. Skrivandet bör driva det visuella, inte tvärtom.

Den här metoden fungerar för den separerar att minnas från att skriva från att presentera. Var och en är en annorlunda kognitiv uppgift, och att försöka göra alla tre samtidigt är varför case study-skrivande känns så dränerande.

För karriärbytare: rama in tekniskt arbete som design

Om du kom från utveckling eller ett annat tekniskt fält behöver dina case studies överbrygga språkgapet. Du fattade designbeslut, du kanske bara beskrev dem i tekniska termer.

Några översättningar:

• ”Jag byggde en responsiv dashboard” → ”Jag designade och implementerade ett informationstätt gränssnitt som prioriterar den viktigaste datan samtidigt som det förblir scanningsbart på alla enheter”
• ”Jag refaktoriserade navigationen” → ”Jag omstrukturerade informationsarkitekturen för att minska antalet steg användare behövde för att nå kärnfunktioner”
• ”Jag skapade komponentbiblioteket” → ”Jag etablerade ett designsystem som säkerställer visuell konsistens och minskar kognitiv belastning i hela produkten”

Du överdriver inte, du beskriver samma arbete genom en designlins. Besluten var alltid designbeslut. Du namnger dem bara korrekt nu.

Innan du publicerar: tre av de åtta delarna avgör nästan alltid om någon hör av sig, och alla tre har varsitt återkommande misstag. Vänd på korten.

Del 3

Utmaningen

Problemet, för vem, och varför det var svårt. Det är här läsaren avgör om resten är värt att läsa.

Vanligaste misstaget

rotate-ccw

Misstaget: uppdraget i stället för problemet

"Kunden ville ha en ny sajt" är en beställning, inte en utmaning. Skriv vad som inte fungerade för någon.

Tillbaka

rotate-cw

Del 6

Nyckeldesignbeslut

Tre till fem beslut, med alternativen du vägde mot varandra och vad som fällde avgörandet.

Vanligaste misstaget

rotate-ccw

Misstaget: bara det du valde

Ett beslut utan bortvalt alternativ ser ut som en tillfällighet. Det är valet mellan två rimliga vägar som visar hur du tänker.

Tillbaka

rotate-cw

Del 8

Resultat och reflektion

Vad som hände, vad du lärde dig, och vad du skulle göra annorlunda nästa gång.

Vanligaste misstaget

rotate-ccw

Misstaget: bara siffror som ser bra ut

Har du inga mätvärden, skriv det. En ärlig reflektion om vad du skulle testa nästa gång väger tyngre än en procentsats utan ursprung.

Tillbaka

rotate-cw

Nästa del

I Del 3 tar vi upp den sista sträckan, att ta allt från Figma till en live portfoliosajt. Plattformsval, responsiva överväganden och den ärliga sanningen om att leverera ofärdigt arbete.