Turning a developer portfolio into a design portfolio

A designer told me my portfolio read like an engineer’s, which is a problem when you’re applying for product and UI/UX roles. I built it when I was first starting out in software engineering, and as my work moved toward design, the site never did.

So I audited it, studied 265 designer job posts and 10 portfolios of new design hires, and redesigned it from a blank page to lead with design.

A portfolio is a product that’s never finished, which makes it the perfect medium for user feedback loops. Each round of testing shapes the next version, so it keeps getting better.

Timeline

September to October 2026

Tools

Figma, FigJam, Next.js, Tailwind CSS

Scope

Website redesign

Design teams look for craft, taste and shipped work. My portfolio led with code.
When I walked through the old site the way a design hiring manager would, the evidence was everywhere, starting with the first screen.

3

The visual language was a developer’s

Pixel display type, monospace body text, and saturated blue on every tile. A disco-ball button wore the same blue as my projects, so color did nothing to show what mattered.

5

The projects page was sorted for engineers

It promised “my growth as a developer,” opened with Git Racer and a 2-hour ASCII camera, and put my only design case study 4th of 13.

6

The details people check first were wrong

What people see when I paste erinkerr.me into an application or a message, rebuilt from the site’s own metadata. It introduces me as a software engineer before anyone visits. Also, the clock tile still said San Francisco, even though I’m applying for jobs in New York. Small, but they’re the kind of details a design reviewer notices.

erinkerr.me

Erin Kerr — Software Engineer & Developer Content Creator

Erin Kerr is a self-taught software engineer building in public. Explore projects like Git Racer, Carpoolio, and Group Sing Along, read the blog, or get in touch.

See all 6 problems in context on the archived 2025 site →

In pursuit of my own curiosity, I pulled 265 UI/UX and adjacent JDs from 98 companies, with 182 explicitly mentioning portfolios. Then I extracted portfolio-related lines, clustered them into themes, and built a map using a small local dataset.

I set filters on the map to show results based on job title, knowing the target “users” of my portfolio would be design leads, hiring managers, and fellow UX professionals. I wanted this section to be an opportunity for those reviewing my portfolio to learn something new or to spark some curiosity about what the research says about their role.

What the map showed

• A portfolio is judged on craft and taste.

  Curation was the single biggest portfolio ask. A few pieces with a clear point of view beat a long list of okay work, and my old site was a long list.

• Code is valued in the job, but it isn’t what the portfolio is judged on.

  88% of posts mention prototyping or code somewhere, but only 2% of portfolio asks do. My engineering is a real advantage, but it should support the design work, not lead.

• Shipped work outranks concepts.

  Live, used work came 2nd. I have shipped apps with real ratings and users, and my old site hid that behind tech-stack chips.

• Posts expect a clear story.

  92% of posts mention reasoning, rationale or storytelling. Case studies should run problem, exploration, decision, result, which is why this one is structured the way it is.

Landscape analysis

I looked at 10 portfolios from people hired into their first design or design engineering job at startups, mid-size companies and 1 apprenticeship. 7 are product designers, 5 of them career switchers like me, and 3 are design engineers. I coded all 10 on the same 20 features, measured 15 of their case studies, and checked each pattern against the 139 product and UI/UX posts from the job-post research that ask for a portfolio.

What the portfolios showed

• Product designers showed 3 to 5 case studies.

  All 7 did, and the median was 4. Taste and curation is also the top portfolio ask in the job posts.

• Every case study followed the same shape.

  A facts block, the problem, research and testing with real people, the design, and what they learned. Most ran 1,000 to 2,300 words with about 20 images. Only 1 reported shipped results.

• Real work went first.

  All 3 who had client, lab or internship work led with it. Concept projects didn’t hold anyone back, since 5 of the 7 product designers had at least 1.

• Designers named the role, engineers showed the work.

  6 of 7 product designers said “designer” on their first screen. The 3 design engineers had no case studies and were hired on live projects, small demos and short posts.

The job posts point the same way for junior roles. At entry and mid level, asks for a user-centered process rise from 15% to 21% of portfolio mentions, and asks for measurable impact fall from 14% to 8%. Junior designers are judged more on how they work than on numbers they moved.

What it suggests for my design

None of this is decided yet. These are the ideas I’m taking into reviewer sessions, each tied to the evidence above.

1. 3 to 5 design case studies on the main path, with real, shipped work first and side projects somewhere else.
2. Fewer, deeper case studies in the shape the hires used. My 2025 case studies ran about 700 to 850 words, and theirs mostly ran 1,000 to 2,300.
3. A first line that names the role, then a test of which angle reviewers remember: research and the brain, building end to end, or AI-native work.
4. A clear place for my psychology and neuroscience background, tested 3 ways: a line on the homepage, About only, or a case study that draws on it.
5. Engineering that supports the design work instead of leading it. Code is 2% of portfolio asks for design roles, but it was the whole case for the design engineers.

How I measured. I looked at each portfolio as it was when they were hired, using the Wayback Machine where a site has changed since, and counted words with a headless browser. 10 is a small sample, and all 10 got hired, so this shows what was typical and enough, not what caused the hire. 3 of the 5 career switchers came from 1 bootcamp’s success stories. Where an archived page lost its styles or images, the recording uses the closest version that still renders and says which one.

Talking to people

First direction: a design page beside the old site. I added a separate /design landing page with 4 case-study cards, a “how I work” section and my tools. It sat beside the 2025 site instead of replacing it, so anyone landing on the homepage still met “Full Stack Developer” first. I threw it out.

Starting over, and keeping the old site. On September 25 I froze the 2025 site at /archive/2025, unchanged, with its own copies of every component so future redesigns can’t break it. The idea came from Lynn Fisher’s archive, where every edition of her site stays online. It let me start from a blank page without deleting work I’m proud of, and anyone can compare the 2 versions.

References.

• Lynn Fisher’s archive: every past edition of a site, kept online.

I prototyped in code instead of static mockups. That’s how I work fastest, and it means reviewers see real type rendering, the real switch and the real mobile layout.

Versions so far

1. Sep 20A separate design page beside the old site (dropped)
2. Sep 25A blank homepage, with the 2025 site frozen at /archive/2025
3. Sep 26The archive index, pared back to a heading, a thumbnail and a year
4. Oct 1Work, Fun and About pages
5. Oct 1The designer/engineer switch under the headline
6. Oct 1The engineer side, which inverts the whole page
7. Oct 1Case studies with a design side and an engineering side

How I’ll test it: I run a first-click test on the homepage, then after 2 minutes ask reviewers which design project they remember.

Why 20 seconds fits: Nielsen Norman Group’s research on how long people stay on web pages found many leave within 10–20 seconds unless the page shows its value quickly. My new homepage puts case studies on the first screen, so 20 seconds is realistic.

None of these are final. Each one is in the prototype so reviewers can react to it, and each comes with the evidence behind it and what would tell me it works.

Design system

The prototype so far uses 5 color tokens and 3 typefaces, each with 1 job. The main components are SiteShell, SiteHeader, Tile, HeroHeadline and SideSwitch.

• Newsreader

  Headlines and project titles

  I’m Erin, a designer who engineers.

• Geist

  Body text

  My path into design wasn’t traditional.

• Geist Mono

  Navigation, labels and metadata, a small dose of the old site

  Work Fun About

Accessibility so far.

• The switch is announced as a switch (role="switch") with a label.
• Every interactive element has a visible focus ring.
• Motion respects reduced-motion settings.
• Every tile has alt text that describes what’s in it.

Counting changed how I saw the old site. I knew it leaned technical, but 13 mentions of code against 2 of design, and 1 tile in 10 about my work, made it concrete enough to act on.

The job posts changed what I think engineering is for in a portfolio. 88% of them mention prototyping or code somewhere, but only 2% of portfolio asks do. Building is still how I work, so the switch keeps it a click away, but it isn’t the headline anymore.

Next time I’d do the research first. I started building on September 20 and pulled the job posts on October 1. Curation turned out to be the top portfolio ask, and knowing that sooner might have saved me the design page I threw away.

Next: finish the reviewer sessions and write the design side of every case study.