A game design portfolio is a small set of projects that prove you can design a system, build it, and explain why it works. Each entry pairs playable or video evidence with the reasoning behind it: the design intent, the systems and levels you shaped, the changes you made after playtests, and the result. Studios read for judgement, not for volume, so three sharp projects beat a dozen concept dumps.
The short answer
What a game design portfolio actually has to prove
Most aspiring designers build the wrong artifact. They collect ideas: a mood board of mechanics, a document of clever systems, a folder of concept sketches. All of that shows imagination, and imagination is the cheapest thing in the industry. Every studio is buried in ideas. What is scarce, and what a portfolio has to demonstrate, is the ability to take one idea and carry it all the way to something a stranger can pick up and play without you standing over their shoulder.
So the real subject of a game design portfolio is judgement under constraint. A hiring lead is reading for a specific chain of evidence: you had an intent, you built a version of it, you watched real people bounce off it, you understood why, and you changed the design in response. That loop is the job. A concept that never met a playtester tells the reader nothing about whether you can close it.
This is why a shorter portfolio almost always wins. A reader gives each project a couple of minutes at most, and a wall of thumbnails forces them to guess which one is your best. Choose for them. Lead with the project that best proves the loop above, and treat every later entry as supporting evidence rather than a fresh audition.
What to include
The five kinds of evidence a studio trusts
Not every project needs all five, but the strongest entries usually carry three or four. Each one lets the reader verify a claim you are making without taking your word for it.
Play
A playable build or a video
The single most persuasive artifact is something the reader can play in a browser, or failing that, a short captured video of the moment your design works. If a system only exists on paper, the reader has to imagine it functioning, and imagination favours the doubter. Show the thing running.
Docs
A focused design document
Not the fifty-page bible. A tight one- or two-page document that states the design goal, the core loop, the systems that serve it, and the tradeoffs you accepted. A lead reads this to see whether you can think in systems and communicate them to a team that has to build them.
Systems
A systems breakdown
Show the economy, the progression curve, the combat math, or the rule set that makes the game tick. A diagram or a tuned spreadsheet with a short explanation proves you designed the machine deliberately rather than tuning by feel until it stopped feeling wrong.
Levels
Annotated level or encounter work
If you touch level or encounter design, annotate a map: sightlines, pacing beats, where you teach a mechanic, where you test it. The annotation is the point. It converts a screenshot into an argument about how you guide a player through a space.
Iteration
Playtest notes and what changed
The rarest and most convincing evidence. Show a before and an after: this is what players did, this is what it told me, this is what I changed. A designer who documents iteration is signalling the exact behaviour a studio needs on a shipping team.
Structure
How to write a single project so it earns the read
Treat each project as a short case study with a fixed shape. Consistency lets a reader move fast, and moving fast is what keeps them in your portfolio instead of the next tab.
Open with the intent in one sentence.
Say what the project was trying to be before you say what it is. A reader who knows your goal can judge whether the result meets it. Without the intent, every design choice looks arbitrary and the reader cannot tell a deliberate decision from an accident.
Show the evidence immediately.
Put the playable build or the clearest video near the top, before the paragraphs. People decide whether to keep reading based on what they can see working. Bury the proof under three scrolls of text and most readers leave before they reach it.
Explain the two or three decisions that mattered.
Do not narrate the whole development. Pick the design decisions a lead would argue about: a system you cut, a mechanic you reworked, a constraint you designed around. Explain the reasoning and the alternative you rejected. That is where your judgement becomes visible.
Close with what playtesting changed.
End each project on the iteration loop. State one thing players did that you did not expect, and what you did about it. This is the sentence that separates a designer who ships from a designer who only dreams, and it is the one a hiring lead remembers.
State your exact role.
On team projects, name what you owned. Studios have seen too many portfolios that borrow credit for a whole game. Being specific about your slice reads as honesty, and honesty about a small contribution beats a vague claim on a big one.
The evidence question
Playable builds versus video, and when each one wins
The strongest possible proof is a build the reader can play in a browser, because it removes every layer of interpretation. There is no editing, no camera choosing what to show, no chance you hid the broken part. The reader feels the game respond to their own input, and that feeling does more work than any paragraph you could write about game feel. When a project can ship as a web build, make that the front door.
But playable is not always practical. A complex build, a console prototype, or a system that takes twenty minutes to reach its interesting state does not survive a cold two-minute visit. In those cases a short, tightly edited video is the honest choice, as long as it shows real play rather than a cinematic. Capture the actual moment your design pays off, keep it under a minute or two, and let the reader see a real session rather than a trailer.
Whichever you choose, host it so it loads fast and plays without friction. A build that takes thirty seconds to boot, or a video gated behind a login, loses the reader you spent months earning. The medium is only as good as the moment it takes to start, so treat load time and playback as part of the design work, not an afterthought once the project is done.
The portfolio itself
Shipped work, personal projects, and where to keep them
A complete portfolio usually balances two kinds of project, because they prove different things. Shipped work, even a small game jam entry or a modest release, proves you can finish inside real constraints: a deadline, a team, a scope you did not fully control. Personal projects prove the opposite and equally important thing, that you can hold a vision and drive it yourself when nobody is assigning the work. A designer who shows only one kind leaves an obvious question unanswered.
Where all of this lives matters more than designers expect. A profile on a social platform or a games marketplace is rented ground: the layout, the ordering and the reach belong to someone else, and a feed change can bury work you spent a year making. A portfolio you control is the one version of your career that keeps working when a platform pivots, and it is the link you can put on a resume without an asterisk.
Folio is one straightforward way to host that portfolio, and being honest about the free plan matters here. The free tier puts you on portfolio.wrxstack.com/yourname rather than a custom domain, it carries a small Made with Folio badge, and the full theme gallery sits on the paid tier. What is not gated is the resume export, which downloads as PDF and DOCX at no cost and with no watermark. Whatever you build it with, own the address, keep the projects tight, and let the playable evidence carry the argument.
Frequently asked questions
How many projects should a game design portfolio have?
Three to five strong projects is the right range for almost everyone. A reader spends only a minute or two per entry, so a longer list forces them to guess which work is your best. Lead with your single strongest project, make each later one earn its place, and cut anything you would feel the need to apologise for.
Do I need shipped games to get a game design job?
No, but you need finished projects. A game jam entry, a small released prototype, or a mod that real people played all count as evidence that you can close a loop rather than only start one. Studios care far more about whether your ideas reach a playable state than about whether they earned money.
What if my best work was on a team project?
Show it, and state exactly what you owned. Name the systems, levels, or features that were yours, and be specific about the parts that were not. Studios have read many portfolios that quietly claim a whole game, so a precise, modest description of your real slice reads as credibility rather than as a smaller contribution.
Should I include a design document in my portfolio?
Yes, but a focused one. A one- or two-page document that states the design goal, the core loop, and the tradeoffs you accepted proves you can think in systems and hand that thinking to a team. Avoid dumping a fifty-page bible, which signals length rather than clarity and rarely gets read past the first section.
Playable build or video: which should I use?
Use a playable build whenever the project can ship to a browser and reach its interesting moment quickly, because nothing is more convincing than the reader feeling the game respond. When a project is too large or too slow to survive a cold visit, use a short video of real play under a minute or two. Either way, make it load and start fast.