For designers and front-end developers, the portfolio often matters more than the resume. It's the evidence. A resume claims you can do the work; a portfolio shows the work and, more importantly, how you think about it.
Most portfolios fail in one of two ways: too many mediocre projects, or beautiful screenshots with no explanation of the problem, your role, or the outcome. This guide fixes both.
Key takeaways
- Three to five strong projects beat a dozen average ones — reviewers spend two to three minutes total.
- Every project needs the same spine: problem, your role, process, solution, impact.
- Show the messy middle — sketches, iterations, trade-offs — not just the polished final screen.
- Developers: a live link plus a clean README plus readable code outweighs a fancy site.
Choosing what goes in
- 1List every project you could show — work, freelance, side projects, coursework, hackathons, open source.
- 2Score each on: relevance to the jobs you want, how much of the outcome you can claim, and whether you can explain your specific contribution.
- 3Keep the top 3–5. Cut anything you'd have to caveat heavily or can't talk about because of an NDA.
- 4Make sure the set shows range — different problem types, not five versions of the same screen.
A self-directed project you can talk about in depth beats a real project you barely touched. Redesign a product you use, build a tool you needed, or contribute to an open-source repo.
The case study structure
A case study is a short story with a fixed shape. Aim for something a reader can skim in two minutes and read fully in five.
1. Overview (2–3 sentences) What the product is, who it's for, what the project was. 2. My role Your title, the team, the timeframe, what you owned vs. contributed to. 3. The problem The user or business problem, and how you knew it was real (data, research, complaints). 4. Process The 3–4 key moves you made. Show artifacts: sketches, flows, prototypes, experiments, PRs. Include at least one trade-off or dead end and why you changed direction. 5. The solution The final result, with visuals or a live link. Annotate the decisions that matter. 6. Impact Numbers if you have them (conversion, load time, task success, adoption). If not, qualitative outcomes and what you'd measure next. 7. What I learned One or two honest reflections.
Instead of
"Redesigned the checkout flow to improve the user experience." + 4 polished screenshots.
Write
"Checkout abandonment was 68% on mobile. I ran 5 user sessions, found the address form was the drop-off point, tested a 2-field autocomplete against the 9-field original, and shipped the winner. Abandonment fell to 51% over 6 weeks." + before/after + the two prototypes tested.
If you're a developer
- Every project: a live demo link and a repo link, both working. A broken demo is worse than no demo.
- Write a real README: what it does, screenshot or GIF, tech stack, how to run it locally, what you'd do next.
- Pin your best 4–6 repos on your GitHub profile and add a profile README.
- Highlight code quality signals: tests, CI, clear commits, sensible structure. Reviewers do open the code.
- Open-source contributions count — link the merged PRs and briefly say what each one did.
- For back-end or data roles where there's nothing visual, a clear architecture diagram and a written walkthrough replace the screenshots.
# Project name One sentence on what it does and who it's for.  ## Why I built it 2–3 sentences. ## Stack Languages, frameworks, notable libraries, hosting. ## Run it locally Steps. ## Notable decisions - Decision and the reason - A trade-off you made ## What's next Short list.
If you're a designer
- Show process artifacts, not just final comps: research notes, user flows, wireframes, iterations.
- Include the versions that didn't ship and say why — it demonstrates judgement.
- Keep visual craft high on the portfolio site itself; it's a work sample whether you intend it or not.
- Tie every decision back to a user need or a business goal, not personal taste.
- For UX roles, lead with thinking; for visual or brand roles, lead with the craft — but both need both.
Where to host it
- A personal site on your own domain is the strongest option — full control, looks committed.
- Fast to ship: a template on a site builder, or a simple static site on GitHub Pages, Vercel or Netlify.
- Designers can supplement with Behance or Dribbble for reach, but keep the real case studies on your own site.
- Developers: GitHub is non-negotiable; a portfolio site is a plus.
- Always have a PDF or slide version of one or two case studies for when someone asks over email.
A custom-animated portfolio that takes weeks and still has one project on it helps nobody. Ship a plain, fast site with three real case studies first, then improve it.
Common mistakes
- Too many projects, none explained in depth.
- Screenshots with no problem statement, role, or outcome.
- Claiming team results without saying what you personally did.
- No contact information or an obvious way to get in touch.
- Password-protected or broken links on the version you send to recruiters.
- Burying the best project on page three.
Put it into practice
Build an ATS-ready resume for free — AI writing help, unlimited downloads, no watermark.
Start my resumeFrequently asked questions
How many projects should a portfolio have?
Three to five. Reviewers rarely get past the third. Depth on a few beats breadth across many.
Can I include work under NDA?
Talk to your employer first. Often you can show the process and outcomes at a high level without exposing confidential specifics or unreleased screens. If in doubt, describe it in words rather than showing it.
Do I need a portfolio if I'm a back-end developer?
A portfolio site is optional, but a strong GitHub profile with pinned repos, good READMEs and visible contributions does the same job.
Should the portfolio or the resume come first?
Put the portfolio link at the top of your resume and LinkedIn. For design and front-end roles, expect the portfolio to be reviewed before anyone reads the resume closely.