How NOT to Write a UX Case Study
Learn from my fail(s)
While some folks feel like the end of the year is a good time to party, resolve the get healthy, or just relax, I decided this was the year I would finally update my portfolio. A girl’s got unlimited PTO, what else am I supposed to do?
Updating the visual design was easy enough, with some helpful critiques (thanks, /r/userexperience/!), although you can rip my whimsical and juvenile emojis from my cold dead hands. The harder feedback to hear, but mostly act on, was my case studies. They didn’t reflect my recent work, and they were spare and lacking detail. So I set to work evaluating what I had, including reading other peoples’ case studies. I recognized some mistakes I’ve made, as well as those others have. Hence, my not-at-all comprehensive list of how to write a crappy UX case study:
Write it a year after the project is completed
I can’t remember what I had for breakfast, much less the rationale behind design decisions I made a year ago. While you may be a copious note taker or have a sharp memory, waiting to write a case study also risks losing access to your design files if you switch platforms (RIP to my Sketch files that never quite imported into Figma correctly). You also risk losing your work if you switch jobs — while I’ve had bosses kind enough to share files with me after a layoff, there’s no guarantee.
Use “we” instead of “I”
Assuming you’re using case studies to find a new job, it’s important to clearly identify the work you did versus that of others on your team. While it’s appealing to apply the royal “we” — it does make our work sound more important than it usually is — take credit and make sure a recruiter and hiring manager knows what you did and what you’re capable of.
Write lots of text
This one is controversial, and probably deserves more nuance than I’m giving it. No one wants to read a wall of text, even if you’re using it to explain something important. I fall victim to this flaw, and have learned that interspersing my wordiness with screenshots, images, and bulleted lists will keep readers from skimming or just tuning out.
Focus on process over results
Another controversial one, but it’s based on actual feedback I’ve heard from a hiring manager via a recruiter. While we want to believe that how we do what we do matters the most, what hiring managers and recruiters are looking for are results. How did you impact feature usage? Did you contribute to increased revenue? No one cares how you recruit usability test participants if you’re not also showing how your work impacts the business.
Make it hard to read on a phone
Guess who uses their phones to review portfolios? Recruiters! Honestly, this is one I still haven’t gotten around to. Good thing I still have three more days until I have to go back to work!
