I understand the temptation to keep working on the portfolio site. I like the craft of it. I can convince myself that the next type change, the next homepage pass, the next cleaner case-study card will finally make the work feel senior. It feels productive because the changes are visible: the background settles down, the hover state gets nicer, and the grid starts behaving. Meanwhile the question a reviewer actually has may still be unanswered: can this person do the job I am hiring for?
That is the point of a portfolio. It is not a shrine to taste, though taste matters. It is not a playground for every interaction pattern I have wanted to try. It is a piece of evidence. Someone opens it because they need to decide whether I can understand a problem, work inside constraints, make good decisions, collaborate with other humans, and produce something that helped.
A beautiful site can help that decision when the beauty serves the work. It can earn trust in my eye, make the work easier to scan, and show that I care about details. My caveat is simple: beauty is much easier to borrow than it used to be. Framer sells free and paid portfolio templates. Webflow has cloneable portfolio sites by the thousands. Squarespace, Readymag, Cargo, Notion, and half the internet can get a person to “polished” faster than we like to admit. Visual craft still counts, especially for roles where the screen is the job, but a gorgeous wrapper is weaker proof than it used to be.
The stronger proof is the story of the work: what was broken, what I had to understand, what I tried, what trade-offs I made, what changed, and what I learned after the thing met reality. Nielsen Norman Group makes this point in a more UX-specific way when it warns that portfolios should show the process behind the work, not just finished screens. They also asked more than 200 UX hiring managers what they look for in portfolios and found that expectations change by role and seniority. That maps to my own view. The burden of proof is not the same at every stage of a career.
For junior and mid-level portfolios, case studies still matter a lot. Early in a career, the résumé usually cannot carry enough weight by itself. The portfolio has to show how the work happened: where the assignment was fuzzy, how feedback changed the direction, what constraints were real, and whether the final decision was connected to a user need or business outcome. The case study does not need to include every sticky note, research clip, and Figma branch. It does need to give enough of the path that someone can believe the final screen came from judgment rather than luck.
This is where I think many of us lose time. We try to make the portfolio feel impressive before we make it legible. We hide the plain story under polish because the plain story feels exposed: here was the problem, here was my role, here were the constraints, here is what I changed, here is what happened. That structure can feel almost embarrassingly simple, but hiring is full of strangers trying to separate claims from evidence. NACE’s 2026 employer research says employers looking at entry-level candidates do not just want skills listed; they want examples. A portfolio is one of the better places to give those examples without making the reader guess.
As a career gets longer, the portfolio can do a different job. If I have worked at a well-known company on a well-known product, the early question is often less “Is this person real?” and more “What exactly did he own, and do I believe his judgment fits our situation?” Recognition can get me into the conversation. It cannot finish the conversation. A senior IC or design executive still has to explain the work clearly, but the first artifact may not need to be a public, fully built case-study website. It might be a private deck. It might be a tighter set of project summaries. It might be a walkthrough prepared for later stages, where the discussion can handle more nuance than a public page can.
That is why I do not think the platform matters as much as we pretend. The container can be a custom-coded site, a Webflow build, a Framer template, a PDF, a deck, or a Google Doc with screenshots. If the story is strong, the reader will forgive a plain container. Some reviewers may even prefer it. A Google Doc that moves cleanly from problem to role to decision to result is easier to evaluate than a beautiful website that makes the reader hunt for the point.
There are limits, of course. If the job depends on visual judgment and the portfolio is careless, broken, unreadable on mobile, or weirdly indifferent to typography, that says something. If the site is slow, inaccessible, or confusing, the container has started to damage the message. Presentation has a job: help the work become easier to understand, then get out of the way.
The portfolio anxiety is understandable. The site feels like the one part of the hiring process I can control, so I keep controlling it. I keep sanding it down. I keep replacing one competent version with another competent version. At some point, though, the useful work shifts from design production to editorial honesty. I have to look at a project and say what actually happened. I have to admit what my contribution was and was not. I have to name the constraint that made the clean solution impossible. I have to say whether the work shipped, whether it moved a metric, whether it changed a team’s understanding, or whether it mostly taught me what I would do differently next time.
That is the part worth spending time on. The work did not happen inside a template. It happened in meetings, trade-offs, research sessions, stakeholder arguments, half-clear briefs, technical constraints, and decisions made with imperfect information. A good portfolio lets that reality show. It gives the work enough dignity to be understood.
Make the site decent, clear, and easy to move through. Then stop polishing the frame long enough to tell the truth about the work. The work is what matters. Honor the work.

Leave a Reply