So you need a UX writing portfolio
You probably got here because someone told you to "build a portfolio" and now you're staring at a blank Figma file wondering what actually counts. I've reviewed dozens of these over the years, and the ones that actually get results have one thing in common: they don't look like design portfolios with words slapped on them. A UX writing portfolio is not a collection of pretty copy samples. It's evidence that you understand how language functions within a product system. That distinction matters because most people conflate the two and then wonder why hiring managers bounce them after the first minute.
Best Ux Writing Portfolios Share These Patterns
When I look at strong UX writing portfolios, I'm scanning for three things immediately: problem context, decision rationale, and measurable outcomes. Not necessarily in that order. Sometimes the outcome comes first and the problem gets explained second. The structure is flexible as long as all three pieces exist. The worst portfolios I see are just screenshots of interfaces with captions like "I wrote error messages for a banking app." That tells me nothing about your thinking process. A decent one shows the before and after, explains why the original failed, and briefly notes how you validated the new version. Here's what most beginners miss: a case study does not need to be long. A one-page case study with a clear narrative arc beats a five-page document where you describe every microcopy decision you ever made. I once spent 45 minutes reviewing a portfolio that was essentially a novel. The writer had three solid projects but buried them under 2,000 words of self-congratulation. I didn't get past the first page.
How to actually build one that works
Start with the projects you actually have. Real work, class projects, spec redesigns, even volunteer work all count. The trick is picking projects where you can show your process, not just the final output. If a project doesn't have a solvable problem attached to it, skip it. A pretty interface with generic placeholder text isn't a portfolio piece, it's a decoration. I recommend structuring each case study around a single user problem, your approach to solving it, and what happened after you shipped. That's it. Don't include every tool you used, every meeting you attended, or the entire content strategy document you drafted. Pick the moment where your writing changed the user's experience and focus on that. One practical thing that saves time: write your case studies in plain text first, then format them. I used to try to design the layout while writing and it took forever. Now I write the draft in Google Docs, strip it down to the essential points, and then move it into a simple page template. The whole process for a solid case study takes me about 90 minutes from start to finish.
Get the Full Details
Where to host it
You don't need a custom domain or a complicated website. Most hiring managers don't care about your tech stack. They care about whether you can write clearly and think critically. A clean Carrd, Notion page, or Framer site works fine. I've seen excellent portfolios on free WordPress themes and terrible ones on custom-coded personal sites with animated backgrounds that slow the page load to twelve seconds. The only real requirement is that the portfolio loads quickly on mobile and the case studies are easy to navigate. If someone has to click through four different pages to read one project, they're probably going to close the tab. Keep it simple. Include a one-page summary at the top that lists your skills, tools, and links to full case studies. A hiring manager should be able to get the gist of your experience in under 60 seconds without scrolling through anything.
What to absolutely avoid
Don't include work you don't have permission to share. I've seen this happen more than I want to admit. Redact client names, blur sensitive data, or describe the project without showing the actual interface if NDAs apply. Nothing kills credibility faster than a candidate who can't respect confidentiality. Don't claim ownership of work you didn't actually do. If you contributed to a larger team project, be honest about what you owned. Saying "I redesigned the entire onboarding flow" when you only wrote three screens of copy will come back to haunt you in an interview. And don't use AI-generated case study content without disclosure. The writing itself might be fine, but if someone reads through and notices the voice is flat and generic, they'll assume the whole thing was produced by a model and move on. Your personality should come through. Even a little dry humor helps.
A specific problem I ran into
Recently I reviewed a portfolio from someone who had genuinely strong work but presented it in a way that made it nearly impossible to evaluate. They had nine case studies, all formatted identically with the same header structure, same image sizes, same paragraph lengths. It was technically proficient and completely forgettable. The uniformity made everything blur together. My workaround for this kind of situation when I'm on the hiring side is to bookmark individual case study URLs rather than browsing the portfolio homepage. But I shouldn't have to do that. The fix is simple: vary your presentation. Use different layouts for different projects. Let some cases lean heavy on screenshots, others on quoted user feedback, others on before-and-after copy comparisons. Variation signals that you think about your work differently depending on what each project needs.
Common pitfalls that kill portfolios
The biggest mistake I see is treating the portfolio like a resume. A resume lists what you did. A portfolio shows how you think. These are different things. Your portfolio should answer the question "what would it be like to work with you?" not "what jobs have I held?" Another pitfall is including too much UI design work. If your portfolio looks like a product designer's portfolio with a section labeled "writing," you're setting the wrong expectation. Make it clear from the landing page that you're a writer. Your samples should center the language, not the visual design. Finally, don't neglect the about page. I know that sounds obvious, but I've rejected strong portfolios because the about section was either nonexistent or just a list of tools. A short paragraph about who you are, what you care about, and what kind of problems you enjoy solving goes a long way. It's the part that makes you rememberable.
