1. One site can’t sell to clients and hiring managers at once
One designer this week wanted a single site to win freelance clients and land a job. Nate’s view was that it can’t do both well. A client is shopping, so they want something closer to a sales page: what you offer, what it costs and how to get in touch. A hiring manager is looking for a person to add to a team. Style the site like a studio and it serves the first group while quietly working against you with the second, because you read as an agency to contract with instead of a candidate to hire.
When the same question came up later in the session, Tim framed it as a question of what you’re selling. Freelancers get hired for the finished asset, so the work is the product. In a full-time role the product is you, and how you’ll sit on a team. You can go after both markets, but the people in each are trying to solve different problems. He compared it to a spork. It works, and hardly anyone reaches for one first.
So decide who each site is for, and if you really need both, build two. Then treat anyone’s opinion of the look as a guess, ours included. Nate was upfront that he isn’t the audience for a freelance site. The people who are will show you if you watch them — install a free session-replay tool like PostHog and look for where real visitors stall or hit a dead end.
2. A narrower target means fewer jobs and more interviews
A career switcher who’d just finished a UX program came in targeting several titles, with a long previous career and a part-time job in an unrelated field also on the site. Nate’s worry was that going after UX, UI and product roles at once makes you look decent at all of them and specialized in none, and someone who specializes will beat you to the job. Narrowing has a real cost, because fewer postings fit you. The ones that do turn into interviews more often, and getting the interview is the whole point of a portfolio.
Nate actually liked the earlier career as a niche, since a researcher aimed at one industry is a strong position. The part-time work was the problem. It widens the audience and weakens the pitch. Our guest host had recently run her own search the same way, applying mostly to roles close to work she’d already done. Reaching outside her lane got her screened out: at least one hiring lead told her they cut anyone without that industry’s experience. Nate added that a niche doesn’t have to be an industry. Technology, skill set, team formation, company size and audience all count.
Pick one title and rewrite your homepage line for it. If an earlier career matters, don’t bury it. Our guest suggested moving those old projects up onto the about page, where people will actually see them. Then find the thread that runs through that career and your design work, and carry it through your case studies. And as she put it, the smaller the pivot, the better.
3. Write the case study for someone who only reads the headings
Nobody reads your case study. Recruiters skim it for words that match the job description, so the block at the top should name your methods, tools, stakeholders and industry. Hiring managers skim it for three answers: what the problem was, how you solved it and how you know it worked. Nate’s test is to read only the headings. If the story still comes through, it’s working. Our guest built her own case studies around the same rule.
Labels like “How I got there” or “Key findings” tell a skimmer nothing, so put the finding or the problem in the heading itself. On one case study, a metric in the opening line made a better title than the product’s name. Nate doesn’t care what the product is called. He cares what you did and what it changed. Tim pushed further on another site: a heading that names the deliverable, like a billing page, says less than one that names the problem, like reducing cognitive load at checkout. Plenty of people can design a billing page, and a problem-first story adapts to whatever process the team runs, whether that’s agile, lean or waterfall.
Then check the middle. One case study we saw jumped from a persona straight to the final concept, and our guest asked what a hiring manager would: what in the research says this is the right answer for this person? If you made journey maps, flows or wireframes, show them. Nate also showed a trick on the call. Give NotebookLM your case study and ask it for a slide deck. Don’t trust the images it makes up. Reading someone else’s version of your story makes it much easier to see how to tell yours.
4. Referrals do most of the work, so write the about page for peers
Most of our guest’s callbacks came through referrals. She made a point of telling people around her, including people with nothing to do with design, that she was looking. Nate pointed out that big companies often pay employees a bonus for a successful referral, so asking is less of an imposition than it feels. Her view was simple: the worst case is that nothing happens and you’re right where you started.
Nate’s goal for the site is that a peer can look at it and feel comfortable referring you. That bar is real. Some people won’t refer you off a slide deck, and a simple web portfolio, even one built from a template, clears that bar. Peers also help narrow candidate lists, which is why Nate treats the about page as closer to a dating profile than a bio: hobbies, interests, what you’d be like to sit next to all day. She had interviewers bring up a hobby they’d seen on hers.
Rewrite your about page for a future teammate. Keep the words as real text instead of baking them into images. Text in an image can’t be highlighted or zoomed, and real text also helps search engines work out what the page is about. Then open your site on your phone. Our guest called a broken mobile view the biggest turnoff for a hiring manager.
5. If you’re getting interviews but not offers, practice the presentation
One designer was landing interviews but not offers, and two interviewers had said to work on presenting. Nate’s first point: if you’re getting interviews, the portfolio is doing its job. What’s left is the soft skills, and those are the hard part. Tim’s read is that designers tend to see twenty good answers to a problem, while the people across the table usually want one clear line with a beginning, a middle and an end, told with confidence. Talk about what you were sure of, not what you weren’t.
We don’t agree on format. Nate sees walking an interviewer through your website as a friction point and wants a dedicated slide deck. Tim would rather show the real thing, a live site or a working demo. He finds decks slow to make and dull to sit through, though he admits they’re more standard and some people may respond better to them. Either can work, depending on the role. Our guest kept each project to five slides (overview, problem, solution, results, impact) and fleshed them out for interviews.
Whatever you present from, rehearse it out loud. Tim’s advice is to know each section well enough that it doubles as a safety net. When a question drags you down a rabbit hole, scroll to the next part and pick the story back up. He’s had bad interviews for jobs he was qualified for, stuck in exactly that kind of hole.
We also covered resumes. Our guest writes bullets as “accomplished X, as measured by Y, by doing Z,” bolds the impact so it scans, tailors each one to the posting, and uploads a plain .docx to online applications. We’d add that Google Docs works too, as long as you skip columns and tables, and that PDFs exported from Figma often come out garbled in simpler parsers. Asked whether a master’s degree would help, the answer was that it can bring network and opportunity, but it won’t fix a portfolio or change the market. Expect to be asked how you use AI and how you check its output, so have your answers ready. And if you’re switching careers with only course projects so far, Tech Fleet and hackathons both put you on real teams with real constraints. Tim’s one caveat on hackathons: the team is only as strong as whoever’s on it.