Designing for Recruiters

Designing for Recruiters

Published on February 10, 2025

While I tend to lean toward bold, expressive design (just take a look at my personal site), not every project calls for that. Sometimes the goal is clarity, speed, and function.

I met Rebekah while she was pivoting into data analytics, and she mentioned she wasn’t particularly happy with her personal site. It had everything it needed – but like many first builds, it felt flat. That gave me an opportunity: design with subtlety and intention. The problem? I had never built for anyone that wasn’t a friend or family member.

Rebekah didn’t need a visual showstopper or a senior dev with years of experience. She needed a site that recruiters could visit, skim in 30-45 seconds, and walk away knowing exactly who she was and whether they wanted to reach out. She didn’t need a world-renowned developer for that, she could get by with just me. The mission, then, was simple:

  1. Condense the site from five pages into a single, focused scroll

  2. Add light and dark mode – automatically detecting system preferences with a manual toggle for control

  3. Use white space generously to give recruiters breathing room and visual clarity

  4. Keep it static since there’d be no need for any API calls or an admin panel – Rebekah knowing basic HTML and CSS meant she could maintain the site without needing an admin panel.

With that in mind, I got to work.

Designing for Recruiters

The biggest priority for a static site is UI/UX. There's nothing else to hide behind—no backend, no complex API calls, no security hurdles beyond the basics. If you're going static, the entire experience lives or dies on the design. And whether that design works comes down to one question: does it resonate with the intended audience?

In this case, the audience was clear – recruiters for data analyst roles.

So I did what I always do when I’m unsure: I listened. I dug through Reddit threads and recruiter forums, reading post after post about what hiring managers actually thought of portfolio sites.

I had assumed a super minimalist approach—one paragraph, a few bullet points, done—would be the way to go. Something completely stripped down. But recruiters didn’t want “bare bones.” They wanted simple without being bland. They wanted something clean, professional, and thoughtfully designed—but also something they could absorb in under a minute.

My original design gave too much. Too many details, too much information upfront. It was clear: we needed to scale it back, focus it down, and let the visuals do just enough to make the experience feel smooth, modern, and intentional.

Sales funneling your way to a job

The final design we landed on worked like a mini sales funnel, shaped directly by the recruiter feedback I’d gathered.

You hit the hero section first. Then a short About blurb. After that, a skills list that fits on one screen, followed by project cards, and finally, contact info. Aside from the projects, each section stays within 50vh and is vertically centered—so if you’re using a scroll button, it takes about four scrolls to get through the entire thing.

And despite that compression, it still looks good. There’s a slight gradient on the page and section headers, but no distracting visuals or heavy-handed effects. That was the whole point: create something attractive, even elegant, without pulling focus from the content.

Each section was also ordered to mirror a recruiter’s mental flow:

  1. Who are they? (Hero + About)

  2. What can they do? (Skills)

  3. Can they prove it? (Projects)

  4. How do I contact them? (Footer section)

Recruiters rarely click around. They make their decision based on the splash page—often within 10 to 30 seconds. For entry-level roles, they’re screening dozens if not hundreds of candidates. That means the burden is on the portfolio to earn that follow-up.

The easier it is for a recruiter to say yes to you, the more likely they are to actually say it.

The hiring process is more than recruiters

While the splash page is the main event, the site does have internal pages—and yes, it’s built in Next.js, so those pages load instantly without a full refresh. Why bother with separate pages at all? Because recruiters aren’t the only people checking out a portfolio.

Interviewers will almost always visit the site before the meeting. They won’t spend hours on it—but they will spend more time than a recruiter. Think 5 to 10 minutes, max. So each page was designed with that in mind: still light, still scannable, but with just enough depth to prepare them for the conversation ahead.

To make that even easier, every page includes a subtle "back to top" icon in the lower right corner—one click, and they’re back at the menu. Small UX touches like that can make a difference. The easier it is to navigate the site, the more energy the viewer can focus on the content—and that sets the tone for a better interview.

The About page gives a quick snapshot of Rebekah’s bio, including her professional background, education, and links to certifications when available. This helps interviewers skip the surface-level “tell me about yourself” stuff and dig into the meaningful questions.

The Skills page breaks her expertise down by category, with clickable tags from the splash page that jump you directly to the expanded skill details. This is especially helpful when a recruiter or hiring manager wants to know whether “SQL” means basic querying… or complex ETL pipelines. Each expanded skill set gives them that clarity.

Then there's the Projects page. On mobile and tablets, project cards have a slightly opaque dark background with overlay text. On desktops, you get hover effects—clean images that reveal the details when you mouse over them. Again, not trying to be flashy—just functional, responsive, and easy to explore. Most hiring managers don’t want long case studies; they want proof that you’ve done the work. This gives them that.

Finally, there’s the contact section—not a page. At the bottom of every page, users can find direct links to email or social media. No contact form. No extra barrier. The idea was: if someone’s ready to reach out, don’t slow them down. Just give them the info and let them act.

Overengineered for Success

The most controversial choice I made on this build was using Next.js.

The first version of the site was a basic vanilla HTML/CSS/JS build. Simpler. Lighter. Easier. But it lacked the structure and component patterns I had come to rely on at the time. As a self-taught dev who jumped into React a little early—before fully locking down the fundamentals of HTML—Next.js felt more natural to me than pure HTML ever did.

If I were building this today, I’d probably stick with vanilla. A year later, I’ve sharpened my core skills and would enjoy the challenge. But back then? Next.js was the faster, smarter move for me.

And honestly, even now there are reasons to still consider it:

  1. Instant page transitions. Could I achieve that with Node and some clever JavaScript? Sure. But just because I can doesn’t mean I should.

  2. Built-in preloading. Images, links, routes—Next.js does a lot of the heavy lifting out of the box. Doing that manually in vanilla would mean more time spent engineering and less time refining the actual design.

  3. Better dev experience overall. Next.js gave me the structure I needed to stay efficient and focused.

Could I have recreated most of this using a lighter stack? Definitely. But for a portfolio site, where performance isn’t mission-critical and deployment is straightforward, the slightly larger footprint of Next.js wasn’t a real issue. The gains in speed, polish, and flow were worth it.

So yes, it might’ve been technically overkill—but if overengineering results in a faster, cleaner, better experience with no real downsides… is it really overkill?

Let there be light (and dark)

As mentioned, I also threw in a light/dark mode toggle.

Ask around, and you’ll usually hear two things from developers:

  1. They love the option—and usually default to dark mode.

  2. They think it’s a luxury. Unnecessary. Overengineering.

I’m firmly in camp #1. But as someone who cares about accessibility, I completely disagree with #2.

Good UI/UX is about options. And offering a theme switch is one of the lowest-effort, highest-value accessibility features you can build. Thanks to Next.js, I was able to use NextThemes—a lightweight solution that gave me automatic system preference detection and manual toggling with just a few lines of code (plus some SCSS setup). Easy win.

But this isn’t just about dev preferences or visual aesthetics. It’s also about comfort, and sometimes even health:

Accessibility is personal. And something as seemingly trivial as a light/dark toggle can make a big difference for people navigating the web with visual, neurological, or cognitive differences.

If it’s easy to implement and improves the user experience for even a handful of people—why wouldn’t you build it?

Handing It All Off

With the design and development complete—roughly one month of design and research, followed by two weeks of building and iterating (though the initial layout came together in a day)—it was time to launch. Rebekah didn’t want to deploy through Vercel, so we went old-school and uploaded the files directly through her hosting provider.

Launch day, of course, came with hiccups. A few errors. A few frantic Googles. But two hours and several Stack Overflow tabs later, we had it live.

Since then, Rebekah’s made a handful of updates—swapped out her profile photo, tweaked some content—but the core site remains almost exactly as I built it over a year ago.

This wasn’t just a technical milestone. It was personal. It was the first project I shipped for someone who wasn’t a friend, family member, or myself. The first time I had to take a client’s goals, listen deeply, adapt my instincts, and build something that reflected them—not just my taste.

It taught me how to translate user intent into design strategy. How to balance accessibility with aesthetics. How to step back and let clarity lead the way.

Would I build it differently now? Absolutely. I’d be faster. More precise. I might add features I didn’t yet know how to create back then. Maybe even build an admin panel. But the outcome wouldn’t change: Rebekah got a site that works for her audience, fits her skill level, and reflects who she is.

Every developer has that one build—the moment you go from learning to doing. This was mine. And while it’s not flashy, it’s functional, intentional, and built to last.