1. Your projects count as experience
The first review was a resume from someone early in their career who was still building case studies before applying anywhere. There was no work experience section. Instead there were “Team projects” and “Individual projects”, and that label does damage before anyone reads a bullet. It reads as student work, and the reviewer’s eyes start to glaze over.
If you planned it and did the work, it’s experience. Put all of it, paid and unpaid, in one section called Experience or Work. We’d avoid “Projects” as the heading. A resume isn’t a background check, but don’t be deceptive either. We’ll never tell you to say you were paid for something you weren’t. If you led a team on a project, though, you led a team, and you can say so.
So rename the section, fold the projects into it and keep a date on every entry. Tim’s test for dates is whether they raise a question. Odd overlaps pull attention off the work, so make the sequence read cleanly. While you’re at it, spell out the month. Systems abbreviate months differently, and it’s an easy fix even if it’s a small one.
2. Spend the space on content
Start with the header. Tim was looking at a screenshot of this resume, and you can’t click the word “LinkedIn” in a screenshot. Write out the full links, and set a short custom LinkedIn URL in your settings (it’s free). If they don’t fit on one line, use two. Location is low on our list of strong opinions. Some employers can only legally hire in certain places, so listing yours saves both of you time. Others shortlist local candidates when a role gets flooded, and leaving it off can drop you from that list. Nate leans toward including it in the US. Elsewhere, we’re less sure.
Experience goes first, under a summary if you keep one. Almost every AI tool will tell you to add a summary, but we often get more out of adding to the experience section. A summary takes up space without saying anything new, and it helps human reviewers more than the AI screeners that now read a lot of resumes. If you keep it, keep it short and objective: discipline, years, specialty, tools, an award if you have one. Education and certifications share a section, and skills go last. Leave years off your education unless the date is still ahead of you, because some reviewers use graduation years to guess your age.
If that frees up room, don’t spend it on bigger type. Tim wouldn’t go above 12 point, and your first reader is often software. Two pages is fine as long as it’s real content and not noise. Then go back through every bullet and move the benefit into the first few words.
3. A freelance site has to sell
Next was a freelance graphic designer’s Behance gallery, with a self-hosted site on the way. Our Behance speech is short: Behance is selling Behance. Its name is bigger than yours, and anyone who wants to message or hire you has to make an account first. Your own site fixes most of that. The harder part is that clients aren’t the hiring managers we usually review for. A freelance site is a sales funnel, so work out who the client is, position yourself for them, and add analytics so you can count the leads. Questions like whether each service gets its own page depend on that audience, and the numbers will answer them better than we can.
A few changes hold either way. Tim would open with the portrait and warm intro instead of the current landing section. Visitors arrive with a problem in mind, and meeting the person behind the work builds a connection. The lists of software, education and skills read more like a resume, so they could move to an about page. People come to a website to look at the work. Keep the client logos as social proof, put the work you most want to be hired for first, and end with a real way to reach you, like a button or an email link. A QR code asks someone on a laptop to pick up their phone.
On process we split a little. Tim likes showing how you think, the way a restaurant cooks in front of you because it’s confident in how it works. Nate used to work at a web design agency, and for one client there, showing process would have been a real mistake. He’d keep it to the high-level steps of working together and lead with what the client gets. Whichever way you go, write down who the client is before you build, and what you want them to do when they reach the bottom of the page.
4. Pick one title, then one mountain
One portfolio called its owner an experience designer, a full stack designer and a product designer, all in the first few lines. Nate read that as three different jobs. Full stack reads as engineering depth, and shipping with AI help is a different claim, so we’d drop it. Between product and UX, Tim’s test is what you focus on. Product designers look at the whole product and talk about metrics and what people actually do. UX work tends to be more formal about artifacts and tighter in scope. In his words, it’s all soup. Pick one and use it everywhere.
Later, a junior designer’s one-line pitch described product design in general. When a thousand other people apply for the same role, a line like that can’t set you apart. We pulled up the graph from our niching tool. “I’m a designer” sits at the far left. Add a discipline, then a craft, then an industry (“a product designer who builds design systems for healthcare teams”) and interviews peak. You qualify for fewer jobs, and your odds on each one go up.
That trade feels backwards, and real life won’t always be as steep as the chart. Tim’s version is a mountain: plant flags on two peaks and you end up standing in the valley between them. Rewrite your line with a discipline, a craft and an industry in it, and accept that it rules some jobs out.
5. Write the case study for someone skimming
Nate put it bluntly: nobody reads case studies. People skim the headings and the images, so your story has to work in those two places. Recruiters are matching keywords to a job description, so give them a short block at the top with the timeline, industry, tools and your role. Reviewers look for a case study from their own industry first and click your first one if they can’t find it. Make the first one your best.
Lead the title with the business result and how you got it. One title opened with a metric a step removed from the business, and Nate asked what action you’re trying to get people to take. In another case study, a projected engagement lift sat farther down the page. Nate wanted it in the title, because a number like that tells a reviewer why they’d hire you and why the case study is worth reading. Near the top, state the problem in one sentence, because without it everything after reads as abstract. Tim wants the solution up front too, so the process steps make sense at a glance.
At the end, show the resolution. That could be metrics, a change in behavior or an estimated change. Then give the reader somewhere to go. A bare “let’s chat” doesn’t do much, so predict the question they’d still have and answer it, the way a good product page answers whatever a visitor is still wondering. Last, read only your headings and see if the story holds. If big “Problem” and “Solution” labels sit over small gray text, the eye catches the labels and skips the words that matter, so make the real sentences stand out.
We also covered work under NDA. Find out what you actually signed, since terms and time limits vary. If you can’t show the real screens, rebuild rough approximations and explain the decisions around them. In Q&A we talked about getting into an agency without agency experience (pick a specialty, or look for agencies that serve an industry or technology you already know). We also took on whether refusing AI helps a designer: it depends on the team, but skipping new features in the tools you already use tends to leave you behind. And recruiting tools search your LinkedIn about section, so if you want recruiters to find you, put your keywords there.
