Case study
jblp.me: A Resume Site That Doesn’t Read Like a Resume
jblp.me is my personal resume site — the version of my career history that exists as a place, not a document. Most resume sites are a PDF with a website wrapped around it: a static page, a download link, done. This one treats the resume itself as the content to design, not just the thing to link to — a full, scrollable career timeline built into the page, with a genuine cinematic entrance in front of it and a PDF offered as a secondary option, not the main event.
The real design problem wasn’t the animation, and it wasn’t the timeline. It was making sure neither one got in the way of the actual job the site has to do: let someone evaluate 15+ years of experience quickly, on any device, even if a script fails to load.
Key design decisions
01
A resume you can read in place, not just download
The full career history — eight positions from 2004 to present — lives in a scrollable modal on the page itself, with a PDF download offered as a secondary option underneath it, not the primary way to see it. That ordering is the core content decision of the whole site: someone evaluating whether to reach out shouldn’t have to open a separate file just to check whether the background is relevant. The resume isn’t a download this site points to — it’s content the site is built around.
02
An entrance that earns its place in front of the resume
On load, the logo flies in, orbits twice with a pulsing depth effect, spirals its radius out and back in, then breaks away, spins 720°, and shrinks directly into the hamburger menu button — at which point the intro overlay fades and the resume‑driven site underneath is revealed, with a small “impact” pulse on the menu icon marking the handoff. It’s built as one continuous GSAP timeline, not a series of disconnected effects, because the entrance is meant to read as a single gesture: a moment of craft in front of what is, underneath it, a document about 15+ years of unglamorous, careful work. The animation and the resume are making the same argument in two different registers.
03
Designing for the version where the animation never happens
This is the decision I’d actually walk an interviewer through. If the GSAP script fails to load, the animation is skipped and the page reveals immediately — no one gets stuck staring at a blank overlay because a CDN request timed out, unable to reach the resume underneath. If JavaScript is disabled entirely, a <noscript> fallback does the same job: hide the overlay, show the menu, let the site function. The showpiece feature of the site is, by design, the one thing a visitor is never required to see to get to the resume itself. That’s a content and experience decision as much as an engineering one — the “ideal path” can never be the only path to the thing someone actually came for.
04
Contact info that puts the reader in control
Email and phone are shown as plain text, not clickable mailto/tel links, laid out side by side. That’s a deliberate choice to present the information and let the visitor decide how they want to act on it, rather than assuming a tap‑to‑call or open‑a‑mail‑client action on their behalf.
05
Navigation that closes after it’s done its job
The off‑canvas sidebar menu slides in from a hamburger toggle and swaps its icon between bars and an X — and, as a recent fix, auto‑closes as soon as a nav link is clicked, instead of leaving an open panel sitting over the page the visitor just navigated to.
What I’d highlight for a hiring manager or client
Treating a resume as content to design, not a file to link to. Building the career history into the page as a readable, scrollable experience — PDF as backup, not the primary path — is a small structural choice that says something about how I think about content generally.
Motion designed as narrative, with a real off-ramp. The instinct to build a genuinely ambitious entrance animation andtreat its complete failure as a first‑class, tested state is the same instinct that matters in content design: the fallback experience deserves as much care as the ideal one, especially when the ideal one is standing in front of the actual point of the site.
Small interaction decisions made on purpose. Plain‑text contact info instead of auto‑linked mailto/tel, a nav that closes itself — none of these are default framework behavior; each one was a deliberate choice about what should happen next for the visitor.
Built and shipped, not just planned. Every fallback described above (the CDN failure guard, the noscript state) exists because it was tested against a real failure, not assumed away.
Tech stack