The Scannable Project Description Recruiters Have Time For The 2,000-word UX case study sits in your portfolio. You spent eight hours writing it. The hiring manager spent eleven seconds on the page...
The Scannable Project Description Recruiters Have Time For
The 2,000-word UX case study sits in your portfolio. You spent eight hours writing it. The hiring manager spent eleven seconds on the page before clicking back to the search results.
This is the gap between portfolio guides that tell you to write long-form case studies and how recruiters actually consume them in 2026. Most guides push the long format because it works for senior-track UX placements at large companies. For everyone else (3D artists, illustrators, indie game developers, junior designers), the long case study is a write-only document. It impresses the author and gets ignored by everyone else.
This guide expands the "200-Word Context Block" approach from the Indie Creator Portfolio Playbook. The pillar names the format. This one teaches you how to write one well, with three annotated examples across disciplines.
There is no academic word count that works for every portfolio piece. Industry guides give a wide range, often recommending 600 to 1,500 words combined with visuals for UX case studies (uxfol.io case study template guide). The number that matters is whatever your reader actually reads, and reader behavior tells a clear story.
Hiring managers and recruiters scan portfolio pieces in seconds, not minutes. They do not read linearly. They jump to the hero image, glance at the description for the problem statement, look for your specific role, and decide in well under a minute whether to look deeper.
In that window, 200 words is the practical floor. Less than that and the reader cannot tell what they are looking at, what problem the piece solved, or what you specifically did. More than that and the reader skips the text entirely.
This is not a rule. It is a constraint that matches reader behavior. The 200-word format forces you to write the four things readers actually want to know. Everything else goes in tags, image captions, or a "more details" expansion for the small fraction of readers who want more.
Every 200-word case study breaks into four short paragraphs. Each does one job.
Paragraph 1: The Project in One Sentence Plus Context
Open with what the project is and where it was made. Not a tagline. A factual sentence the reader can use to orient themselves.
Example: "Three character models for a small indie fantasy RPG, shipped to the App Store on iOS and the Play Store on Android in Q3 2025."
Then add two or three sentences of context: what was the brief, what platform constraints applied, what audience the work targeted. The goal is for the reader to know enough by the end of paragraph one to evaluate whether your work is relevant to their needs.
Paragraph 2: The Constraint That Shaped the Work
Every project has a constraint that mattered. Budget. Timeline. Technical limit. Hardware target. Asset count. Lighting model. Memory budget. Pick the one that genuinely shaped your decisions.
This is the paragraph most creators skip, and it is the most valuable signal you can send. Anyone can show pretty work. Showing that you made decisions inside a real constraint demonstrates professional maturity.
If the project was for a mobile game, "optimized for sub-4MB total mesh budget per character" tells a recruiter you have shipped under real constraints. If it was a portfolio piece without constraints, say so honestly and describe the self-imposed scope.
Paragraph 3: What You Specifically Owned
The single most important paragraph for hired work, and the one most creators write poorly.
If you worked solo, say so plainly: "Solo project. Modeling, UV, texturing, rigging, animation, lighting."
If you worked on a team, name the team work and credit the parts you did not own. "Character base mesh by the lead artist. I owned retopology for game-ready optimization, UV layout, texture pass in Substance Painter, and rig hookup to the project's humanoid skeleton."
Vague phrases like "contributed to character art" read as evasion. Recruiters notice. Specific credit lines read as professionalism, even if the slice of work you owned is narrow.
Paragraph 4: The Outcome
Close with what the piece achieved. The strongest version is measurable: shipped to a specific platform, used in a launch trailer, included in a launch campaign, reached a specific download or sales threshold. If you have those numbers, use them.
If you do not have shipped metrics (portfolio piece, school project, unreleased project), describe the technical outcome instead: "Final asset hits the target polycount, validates in the engine's profiler, and matches the lighting reference within the agreed tolerance." This is still a professional outcome statement.
Avoid "I learned a lot from this project" closes. They read as junior, even when written by a senior.
The format adapts across disciplines. Three short examples of what it looks like in practice.
Example 1: 3D Character Art (Game-Ready)
Example 2: UX/UI Design (Web Product)
Example 3: Illustration (Editorial / Marketing)
Each example hits the same four-paragraph structure. None reads as filler. Each one tells a recruiter or potential client the exact information they need to evaluate the work.
A small fraction of portfolio pieces deserve longer treatment. Specifically:
For everything else (3D models, illustrations, animations, code projects, music tracks, small UX projects), the 200-word format outperforms the long case study because it gets read. A read 200 words always beats an unread 1,500.
If you want to add depth without losing scannability, use an expandable "more detail" section, supplemental linked PDFs, or a process video. Keep the main page short.
A few habits that make 200 words feel substantive.
Lead with concrete nouns. "Three character models" beats "character art assets." Specifics signal confidence.
Use active voice. "I owned the texture pass" beats "the texture pass was completed by the author."
Name the tools that mattered. Engine version, software, scope of automation. Recruiters use tags to filter; tags belong in the text too, in natural prose.
Avoid jargon that obscures rather than informs. "Optimized rendering pipeline" tells a recruiter nothing; "reduced draw calls from 800 to 220 using mesh instancing" tells them everything.
Cut your first draft by 25 percent. Most case study drafts include throat-clearing sentences ("This was a really exciting project that..." or "I want to walk you through..."). Cut them. The reader is already on the page.
Five patterns that weaken case studies.
Burying the role in the middle. Recruiters scan for "what did you do." Make it visible by paragraph three at the latest, ideally surfaced via a clear "Role:" label or stand-alone sentence.
Listing tasks instead of decisions. "User research, sketches, wireframes, prototype, testing" is a checklist. "I shifted from low-fidelity to high-fidelity wireframes early because the team's feedback was driven more by visual context than flow logic" is a decision. Show decisions.
Vague impact statements. "The project was successful" is empty. Either name the specific outcome or describe the technical achievement; do not split the difference with vague success language.
No team credit at all on team work. Reads as taking credit for collaborative work. Always credit the parts you did not own, even briefly.
Long descriptions paired with weak hero images. No amount of text recovers a portfolio piece if the hero shot does not sell the work. Spend more time on image selection than on writing.
A portfolio with 12 well-written 200-word case studies converts at a meaningfully higher rate than the same portfolio with 12 generic image dumps. The work to bring a piece from "image only" to "image plus 200 words" is roughly 20 to 30 minutes per piece. The payoff plays out across every recruiter scan, every cold outreach, every client referral for as long as the portfolio is online.
The 200-word format is not glamorous. It is the part of portfolio work that most creators skip because the visual is so much more fun to produce. The creators who do the writing consistently outperform the creators who do not, because the reader can actually evaluate the work without guessing.
Write the four paragraphs. Skip the 2,000-word essay. The portfolio will be stronger for it.
The 2,000-word UX case study sits in your portfolio. You spent eight hours writing it. The hiring manager spent eleven seconds on the page before clicking back to the search results.
This is the gap between portfolio guides that tell you to write long-form case studies and how recruiters actually consume them in 2026. Most guides push the long format because it works for senior-track UX placements at large companies. For everyone else (3D artists, illustrators, indie game developers, junior designers), the long case study is a write-only document. It impresses the author and gets ignored by everyone else.
This guide expands the "200-Word Context Block" approach from the Indie Creator Portfolio Playbook. The pillar names the format. This one teaches you how to write one well, with three annotated examples across disciplines.
Why 200 Words is the Right Floor
There is no academic word count that works for every portfolio piece. Industry guides give a wide range, often recommending 600 to 1,500 words combined with visuals for UX case studies (uxfol.io case study template guide). The number that matters is whatever your reader actually reads, and reader behavior tells a clear story.
Hiring managers and recruiters scan portfolio pieces in seconds, not minutes. They do not read linearly. They jump to the hero image, glance at the description for the problem statement, look for your specific role, and decide in well under a minute whether to look deeper.
In that window, 200 words is the practical floor. Less than that and the reader cannot tell what they are looking at, what problem the piece solved, or what you specifically did. More than that and the reader skips the text entirely.
This is not a rule. It is a constraint that matches reader behavior. The 200-word format forces you to write the four things readers actually want to know. Everything else goes in tags, image captions, or a "more details" expansion for the small fraction of readers who want more.
The 4-Paragraph Structure
Every 200-word case study breaks into four short paragraphs. Each does one job.
Paragraph 1: The Project in One Sentence Plus Context
Open with what the project is and where it was made. Not a tagline. A factual sentence the reader can use to orient themselves.
Example: "Three character models for a small indie fantasy RPG, shipped to the App Store on iOS and the Play Store on Android in Q3 2025."
Then add two or three sentences of context: what was the brief, what platform constraints applied, what audience the work targeted. The goal is for the reader to know enough by the end of paragraph one to evaluate whether your work is relevant to their needs.
Paragraph 2: The Constraint That Shaped the Work
Every project has a constraint that mattered. Budget. Timeline. Technical limit. Hardware target. Asset count. Lighting model. Memory budget. Pick the one that genuinely shaped your decisions.
This is the paragraph most creators skip, and it is the most valuable signal you can send. Anyone can show pretty work. Showing that you made decisions inside a real constraint demonstrates professional maturity.
If the project was for a mobile game, "optimized for sub-4MB total mesh budget per character" tells a recruiter you have shipped under real constraints. If it was a portfolio piece without constraints, say so honestly and describe the self-imposed scope.
Paragraph 3: What You Specifically Owned
The single most important paragraph for hired work, and the one most creators write poorly.
If you worked solo, say so plainly: "Solo project. Modeling, UV, texturing, rigging, animation, lighting."
If you worked on a team, name the team work and credit the parts you did not own. "Character base mesh by the lead artist. I owned retopology for game-ready optimization, UV layout, texture pass in Substance Painter, and rig hookup to the project's humanoid skeleton."
Vague phrases like "contributed to character art" read as evasion. Recruiters notice. Specific credit lines read as professionalism, even if the slice of work you owned is narrow.
Paragraph 4: The Outcome
Close with what the piece achieved. The strongest version is measurable: shipped to a specific platform, used in a launch trailer, included in a launch campaign, reached a specific download or sales threshold. If you have those numbers, use them.
If you do not have shipped metrics (portfolio piece, school project, unreleased project), describe the technical outcome instead: "Final asset hits the target polycount, validates in the engine's profiler, and matches the lighting reference within the agreed tolerance." This is still a professional outcome statement.
Avoid "I learned a lot from this project" closes. They read as junior, even when written by a senior.
Three Annotated Examples
The format adapts across disciplines. Three short examples of what it looks like in practice.
Example 1: 3D Character Art (Game-Ready)
Stylized fantasy warrior for an indie RPG. Character was the playable hero of a mobile fantasy game shipping in Q4 2025. Audience: 12 to 18 age range. Stylized low-poly aesthetic to match the established art direction.
Mobile budget constraints. Total polycount under 9,000 triangles. Single 2K diffuse texture, single 1K normal map, no separate roughness or metallic maps in the final mobile shader. Rig had to import cleanly into the project's existing humanoid Mecanim setup with zero added bones.
Solo project. I owned the full pipeline from concept reference selection through final delivery: high-poly sculpt in ZBrush, retopology in Maya, UV unwrapping, hand-painted texture pass in Substance Painter (no procedural materials), rigging with custom shoulder corrective shapes, and a 22-frame idle animation. Concept reference selected from public domain medieval armor reference; no AI tools used at any stage.
Shipped to the App Store and Play Store in October 2025. Character appears in the launch trailer and is the cover art on both store listings. Hits the optimization budget with zero overage. Asset has been downloaded as a free demo over 4,000 times in the first six weeks of release.
Example 2: UX/UI Design (Web Product)
Onboarding flow redesign for a B2B analytics SaaS. The existing flow had a 32 percent activation rate. Target: improve activation by reducing the time from signup to first useful action.
Live product, paying customers, limited downtime. Redesign had to ship without breaking the existing onboarding experiment data, and the rollout had to run alongside a marketing campaign that could not be paused. Worked inside the existing design system, so visual exploration was limited to flow and information hierarchy.
Lead designer on a team of three. I owned user research synthesis (10 interviews conducted by the PM, analyzed by me), wireframes, prototype, and final UI handoff. The PM owned the experiment design and metrics tracking. The engineer owned implementation and feature flag rollout. Visual design system was prebuilt by an earlier hire; I worked within it without modification.
Shipped to 100 percent of new signups in late 2024. Activation rate increased from 32 percent to 51 percent in the two months following rollout, exceeding the team target of 45 percent. The redesigned flow is still in production with no significant changes a year later.
Example 3: Illustration (Editorial / Marketing)
Cover illustration for an indie magazine's annual climate issue. Brief was a single hero illustration plus three supporting spot illustrations, all on the theme of urban climate adaptation. The magazine ships in print to roughly 8,000 subscribers and digitally to a larger online readership.
Two-week turnaround from brief to print-ready files. Pieces had to read clearly at both magazine cover size and as small thumbnails for social promotion. Style had to match the magazine's established editorial aesthetic (limited palette, painterly texture) without copying any specific past contributor.
Solo project. I owned concept exploration (three thumbnails per piece, reviewed with the art director), final illustration in Procreate and Photoshop, color correction for print, and delivery in both print-resolution CMYK and web-optimized RGB. The art director provided the brief, color reference, and feedback rounds but did not contribute to the artwork.
Cover ran on the print issue and the magazine's social channels in early 2025. The illustration was selected by the editorial team for the year-end retrospective issue's cover. The art director referred two additional clients to me in the six months following delivery, which I attribute partly to the smooth working relationship on this piece.
Each example hits the same four-paragraph structure. None reads as filler. Each one tells a recruiter or potential client the exact information they need to evaluate the work.
When Longer Works (and When It Doesn't)
A small fraction of portfolio pieces deserve longer treatment. Specifically:
•Senior UX or product design work targeting roles where decision-making detail is the differentiator. A 1,000 to 1,500 word case study with annotated research, iteration shots, and reflection can land. The audience expects depth.
•Process-heavy work where the journey itself is the value (research methodology, complex technical problem solving, novel pipeline development).
•Recovery or failure cases where the lesson is the point. Recruiters value honest documentation of projects that went wrong and what you did about it.
For everything else (3D models, illustrations, animations, code projects, music tracks, small UX projects), the 200-word format outperforms the long case study because it gets read. A read 200 words always beats an unread 1,500.
If you want to add depth without losing scannability, use an expandable "more detail" section, supplemental linked PDFs, or a process video. Keep the main page short.
Writing Tactics That Work
A few habits that make 200 words feel substantive.
Lead with concrete nouns. "Three character models" beats "character art assets." Specifics signal confidence.
Use active voice. "I owned the texture pass" beats "the texture pass was completed by the author."
Name the tools that mattered. Engine version, software, scope of automation. Recruiters use tags to filter; tags belong in the text too, in natural prose.
Avoid jargon that obscures rather than informs. "Optimized rendering pipeline" tells a recruiter nothing; "reduced draw calls from 800 to 220 using mesh instancing" tells them everything.
Cut your first draft by 25 percent. Most case study drafts include throat-clearing sentences ("This was a really exciting project that..." or "I want to walk you through..."). Cut them. The reader is already on the page.
Common Mistakes
Five patterns that weaken case studies.
Burying the role in the middle. Recruiters scan for "what did you do." Make it visible by paragraph three at the latest, ideally surfaced via a clear "Role:" label or stand-alone sentence.
Listing tasks instead of decisions. "User research, sketches, wireframes, prototype, testing" is a checklist. "I shifted from low-fidelity to high-fidelity wireframes early because the team's feedback was driven more by visual context than flow logic" is a decision. Show decisions.
Vague impact statements. "The project was successful" is empty. Either name the specific outcome or describe the technical achievement; do not split the difference with vague success language.
No team credit at all on team work. Reads as taking credit for collaborative work. Always credit the parts you did not own, even briefly.
Long descriptions paired with weak hero images. No amount of text recovers a portfolio piece if the hero shot does not sell the work. Spend more time on image selection than on writing.
The Compounding Effect
A portfolio with 12 well-written 200-word case studies converts at a meaningfully higher rate than the same portfolio with 12 generic image dumps. The work to bring a piece from "image only" to "image plus 200 words" is roughly 20 to 30 minutes per piece. The payoff plays out across every recruiter scan, every cold outreach, every client referral for as long as the portfolio is online.
The 200-word format is not glamorous. It is the part of portfolio work that most creators skip because the visual is so much more fun to produce. The creators who do the writing consistently outperform the creators who do not, because the reader can actually evaluate the work without guessing.
Write the four paragraphs. Skip the 2,000-word essay. The portfolio will be stronger for it.