Voor designers en frontend-developers telt het portfolio vaak zwaarder dan het cv. Het is het bewijs. Een cv beweert dat je het werk kunt; een portfolio toont het werk en, belangrijker, hoe je erover nadenkt.
De meeste portfolio's mislukken op een van twee manieren: te veel middelmatige projecten, of mooie screenshots zonder uitleg over het probleem, je rol of het resultaat. Deze gids lost beide op.
Belangrijkste punten
- Drie tot vijf sterke projecten verslaan een dozijn gemiddelde — beoordelaars besteden er in totaal twee tot drie minuten aan.
- Elk project heeft dezelfde ruggengraat nodig: probleem, jouw rol, proces, oplossing, impact.
- Toon het rommelige middendeel — schetsen, iteraties, afwegingen — niet alleen het afgewerkte eindscherm.
- Developers: een live link plus een nette README plus leesbare code wegen zwaarder dan een chique site.
Kiezen wat erin gaat
- 1Maak een lijst van elk project dat je zou kunnen tonen — werk, freelance, hobbyprojecten, studieopdrachten, hackathons, open source.
- 2Scoor elk op: relevantie voor de banen die je wilt, hoeveel van het resultaat je kunt claimen, en of je je specifieke bijdrage kunt uitleggen.
- 3Houd de beste 3-5 over. Schrap alles waar je veel bij zou moeten nuanceren of waar je vanwege een geheimhoudingsverklaring niet over kunt praten.
- 4Zorg dat de set variatie toont — verschillende soorten problemen, niet vijf versies van hetzelfde scherm.
Een eigen project waar je diepgaand over kunt praten verslaat een echt project dat je nauwelijks hebt aangeraakt. Herontwerp een product dat je gebruikt, bouw een tool die je nodig had, of draag bij aan een open-source repo.
De structuur van de casestudy
Een casestudy is een kort verhaal met een vaste vorm. Mik op iets dat een lezer in twee minuten kan scannen en in vijf minuten helemaal kan lezen.
1. Overzicht (2-3 zinnen) Wat het product is, voor wie het is, wat het project was. 2. Mijn rol Je titel, het team, de tijdlijn, waar je verantwoordelijk voor was versus waar je aan bijdroeg. 3. Het probleem Het gebruikers- of businessprobleem, en hoe je wist dat het echt was (data, onderzoek, klachten). 4. Proces De 3-4 belangrijke stappen die je zette. Toon artefacten: schetsen, flows, prototypes, experimenten, PR's. Neem minstens één afweging of doodlopende weg op en waarom je van koers veranderde. 5. De oplossing Het eindresultaat, met visuals of een live link. Annoteer de beslissingen die ertoe doen. 6. Impact Cijfers als je die hebt (conversie, laadtijd, taaksucces, adoptie). Zo niet, kwalitatieve resultaten en wat je vervolgens zou meten. 7. Wat ik heb geleerd Een of twee eerlijke reflecties.
In plaats van
'Het checkout-proces herontworpen om de gebruikerservaring te verbeteren.' + 4 afgewerkte screenshots.
Schrijf
'Winkelwagenverlating was 68% op mobiel. Ik deed 5 gebruikerssessies, ontdekte dat het adresformulier het afhaakpunt was, testte een autocomplete met 2 velden tegen het origineel met 9 velden en bracht de winnaar uit. Verlating daalde in 6 weken naar 51%.' + voor/na + de twee geteste prototypes.
Als je developer bent
- Elk project: een live demo-link en een repo-link, beide werkend. Een kapotte demo is erger dan geen demo.
- Schrijf een echte README: wat het doet, screenshot of GIF, tech-stack, hoe je het lokaal draait, wat je vervolgens zou doen.
- Zet je 4-6 beste repo's vast op je GitHub-profiel en voeg een profiel-README toe.
- Licht signalen van codekwaliteit uit: tests, CI, duidelijke commits, verstandige structuur. Beoordelaars openen de code echt.
- Open-source bijdragen tellen — link de gemergde PR's en zeg kort wat elke deed.
- Voor backend- of datarollen waar niets visueel is, vervangen een duidelijk architectuurdiagram en een geschreven toelichting de screenshots.
# Projectnaam Eén zin over wat het doet en voor wie het is.  ## Waarom ik het bouwde 2-3 zinnen. ## Stack Talen, frameworks, noemenswaardige libraries, hosting. ## Lokaal draaien Stappen. ## Noemenswaardige beslissingen - Beslissing en de reden - Een afweging die je maakte ## Wat volgt Korte lijst.
Als je designer bent
- Toon procesartefacten, niet alleen de eindcomps: onderzoeksnotities, gebruikersflows, wireframes, iteraties.
- Neem de versies op die niet zijn uitgebracht en zeg waarom — het toont oordeelsvermogen.
- Houd het visuele vakmanschap hoog op de portfoliosite zelf; het is een werkvoorbeeld of je het nu bedoelt of niet.
- Koppel elke beslissing terug aan een gebruikersbehoefte of een businessdoel, niet aan persoonlijke smaak.
- Voor UX-rollen begin je met het denken; voor visuele of merkrollen begin je met het vakmanschap — maar beide hebben beide nodig.
Waar je het host
- Een persoonlijke site op je eigen domein is de sterkste optie — volledige controle, oogt toegewijd.
- Snel te lanceren: een template op een sitebuilder, of een eenvoudige statische site op GitHub Pages, Vercel of Netlify.
- Designers kunnen aanvullen met Behance of Dribbble voor bereik, maar houd de echte casestudy's op je eigen site.
- Developers: GitHub is niet onderhandelbaar; een portfoliosite is een plus.
- Zorg altijd voor een PDF- of slideversie van een of twee casestudy's voor als iemand er via e-mail om vraagt.
Een portfolio met maatwerkanimaties dat weken kost en nog steeds één project bevat, helpt niemand. Lanceer eerst een simpele, snelle site met drie echte casestudy's en verbeter hem daarna.
Veelgemaakte fouten
- Te veel projecten, geen enkele diepgaand uitgelegd.
- Screenshots zonder probleemstelling, rol of resultaat.
- Teamresultaten claimen zonder te zeggen wat je persoonlijk deed.
- Geen contactinformatie of een duidelijke manier om contact op te nemen.
- Met wachtwoord beveiligde of kapotte links in de versie die je naar recruiters stuurt.
- Het beste project op pagina drie begraven.
Breng het in praktijk
Maak gratis een ATS-vriendelijk cv — AI-schrijfhulp, onbeperkt downloaden, geen watermerk.
Mijn cv beginnenVeelgestelde vragen
Hoeveel projecten moet een portfolio hebben?
Drie tot vijf. Beoordelaars komen zelden voorbij de derde. Diepgang op een paar verslaat breedte over veel.
Mag ik werk onder geheimhoudingsverklaring opnemen?
Overleg eerst met je werkgever. Vaak kun je het proces en de resultaten op hoofdlijnen tonen zonder vertrouwelijke details of onuitgebrachte schermen te onthullen. Bij twijfel: beschrijf het in woorden in plaats van het te tonen.
Heb ik een portfolio nodig als ik backend-developer ben?
Een portfoliosite is optioneel, maar een sterk GitHub-profiel met vastgezette repo's, goede README's en zichtbare bijdragen doet hetzelfde werk.
Wat komt eerst, het portfolio of het cv?
Zet de portfoliolink bovenaan je cv en LinkedIn. Voor design- en frontend-rollen mag je verwachten dat het portfolio wordt bekeken voordat iemand het cv goed leest.