Portfolio Site
See for yourself. This site explained
UX Design
- Time table 4 months
- Role UX Design / Web Developer
- PlatformWeb
Introduction
Yes, I know it is very meta to make a UX case study about my own UX portfolio, but this project of mine has been a great learning opportunity for myself. There are several techniques used across this website that could be put to good use in other UX and web projects, so I believe it deserves a deeper dive.
Most everything you see on this site was made by me with just code, and every detail has been mulled over to great lengths. I believe this to be my most wide-ranging project to date and great testament to my cross-functional skillset across UX, UI, and graphic design, and general comprehension of development.
Purpose and Intent
This project possibly serves the greatest purpose of any of my projects: that is to present my work, skills, and professional capabilities to a wide range of prospective eyes–ranging from employers to peers to potential industry connections. Therefor, it was vital that this form of self branding and promotion be true to my aesthetics, passions, and never-ending pursuit towards personal and professional growth.
Previously, my portfolio was hosted and built through Wix, but site builders always felt half-hearted in self expression; always somewhere between prefab templates and one-size-fits-some designs. We are designers working alongside very talented developers, shouldn't we at least know how the sausage is made?
Research and Learning
As I previously alluded to, I was not opting for a site builder this time around. However, this presented me with quite the hurdle to overcome. I had some knowledge of simple HTML and CSS from college, but I was not confident in my ability to realize my vision for this portfolio website with what I already knew. This meant I had to refresh myself on these languages and their recent changes, then meticulously solve for the logistics of every design element. This meant interaction, responsiveness, accessibility, and more.
Learning from the Other Side
Despite how closely the roles of designers and developers intertwine, there doesn't seem to be much of an importance placed of understanding one another. It would benefit designers to understand how UI components are crafted, how layouts are made responsive, or the ins and outs of accessibility guidelines. At the very least, knowing what a rem is wouldn't hurt.
Designers who master this relationship become known as DX designers, or developer experience designer (everything needs an X, it's much cooler that way). But a little bit of DX can go a long way in making me a better designer.
Design System
A design system for a portfolio of one might sound like overkill, but it forced me to make deliberate, documented decisions about every visual element before writing a single line of page-level code. Every color, size, and spacing value lives as a CSS custom property in a single variables file, creating a single source of truth that cascades through the entire site. This approach means I can make sweeping visual changes by editing a handful of tokens rather than hunting through dozens of stylesheets.
Typography
Three typefaces carry the site's personality, each chosen for a specific role. Radley, a classic serif, handles headings—it brings a literary warmth that feels appropriate for a portfolio built around storytelling and case studies. Atkinson Hyperlegible serves as the body typeface, and the name says it all: it was designed by the Braille Institute specifically to maximize character distinction and readability, making it an accessibility-first choice that also happens to look great. Space Mono rounds out the trio for metadata, tags, and small UI text, lending a technical edge that hints at the code running under the hood.
A five-step type scale (ranging from 0.875rem to 3rem) keeps sizing consistent across every page. Headings use text-wrap: balance to prevent awkward line breaks—a small CSS detail that makes a real difference in how polished a page feels. Line heights are tuned per context: tight for display headings, generous for body copy where sustained reading demands breathing room.
Layout
The layout system is where the development side of this project taught me the most. Rather than reaching for a CSS framework, I built a custom grid using CSS Grid's named grid lines. The content column maxes out at 700 pixels for comfortable reading, but named areas like breakout, full-bleed, left-half, and right-half let content break free of that column when it needs to breathe. An image can span edge-to-edge across the viewport, a comparison can sit side by side in two halves, or a figure can push into the margins—all by simply applying a class name.
This named-line approach also means the grid degrades gracefully. On mobile, the breakout gutters collapse and the page gutter shrinks from 2rem to 1rem, but nothing breaks because the sizing is handled with minmax() and viewport-relative math rather than fixed pixel values.
Projecting Personality
A portfolio is inherently a branding exercise. Every decision—from the easing curve on a transition to the shade of grey on a card border—communicates something about who you are as a designer. I wanted this site to feel considered but not sterile, technical but not cold. The personality lives in the details.
Homepage
The homepage is a single bento grid—a layout style I was drawn to for how naturally it accommodates content of varying importance and proportion. Each project occupies a card whose size is defined by its own content data, so the grid is not a fixed template but a responsive expression of the portfolio itself. A two-column-wide text card introduces me with a brief welcome, and the remaining cards are project entries with cover images that morph seamlessly into their case study pages when clicked.
The grid scales from five columns on wide displays down to a single-column stack on mobile, with intermediate breakpoints at three and two columns. On the smallest screens, the text card hides entirely in favor of letting the project imagery lead—because at that size, the work should speak first.
Images
Images are optimized aggressively but presented generously. Astro's Picture component delivers every image in AVIF and WebP with three density variants (1x, 2x, 3x), meaning the browser always loads the smallest file that looks sharp on the user's display. All images receive a consistent 2rem border radius for visual cohesion.
Clicking any image opens a PhotoSwipe lightbox for full-resolution viewing. This felt important for a design portfolio—readers should be able to inspect the work at real scale, not just see a thumbnail embedded in a paragraph. Video and YouTube embeds integrate into the same gallery system, so motion work and static imagery live side by side.
Page Transitions
This site uses the View Transitions API, one of the more exciting recent additions to the web platform. When navigating between pages, shared elements—like a project card's cover image, title, and description—morph smoothly from their homepage position into their case study placement. The effect is not just decorative; it preserves spatial context and makes the site feel like a continuous space rather than a series of disconnected pages.
The transitions use a custom cubic-bezier easing with a slight overshoot, giving movements a subtle physicality. A half-second duration keeps things brisk without feeling abrupt. I spent a surprising amount of time tuning these curves—the difference between a transition that feels satisfying and one that feels sluggish often comes down to a few hundredths of a second and a single control point.
Case Study Hero Sections
Each case study opens with a bento-style hero built from two or three cover images, sized according to dimensions defined in the project's content data. This means the hero layout adapts to the proportions of the imagery rather than forcing every project into the same template. A tall portrait, a wide landscape, and a square detail shot can coexist in the same grid without any of them being awkwardly cropped or padded.
The images are wrapped in gallery links, so they double as the first entries in the lightbox. Below the hero grid, the project title, description, tags, and software icons are laid out in a two-column detail section. A blurred, scaled-down version of the cover image fades in behind the hero as a subtle atmospheric backdrop—a small touch that gives each case study its own sense of place.
Color Themes
Every project is assigned a color from a small palette: grey, blue, green, or red. When you navigate to a case study, the entire page's color system shifts to match. This is not a simple background-color swap—every semantic color token (surfaces, text, accents, links, hover states) is remapped through a set of palette overrides applied via a class on the body element.
The palette system uses a two-tier token architecture. Primitive tokens define the raw color ramps (twelve shades of grey, ten shades each of blue, green, and red). Semantic tokens then alias into those primitives based on context: --surface-primary, --content-secondary, --surface-accent, and so on. When the palette class changes, only the semantic layer is remapped, so every component on the page responds automatically without any component-level overrides. The result is that each case study feels like it has its own identity while remaining part of a cohesive whole.
Accessibility
Accessibility was not a final checklist item—it informed decisions from the start. A portfolio that claims design competence but neglects accessibility is a contradiction, and I wanted this site to prove that inclusive design and expressive design are not at odds with one another.
Semantic HTML
Every page uses proper landmark elements: <main>, <nav>, <section>, and <footer> create a navigable document outline for assistive technologies. Heading levels follow a strict hierarchy—no skipping from h1 to h4 for styling convenience. Sections are tied to their headings with aria-labelledby, so screen reader users can orient themselves by section title. Decorative SVGs carry role="presentation" to keep them out of the accessibility tree, and every meaningful image has descriptive alt text.
A .visually-hidden utility class hides content visually while keeping it available to screen readers—used for supplementary labels and context that sighted users can infer from layout but non-sighted users cannot.
Color
The default dark theme was designed to meet WCAG AAA contrast ratios. The semantic color system helps enforce this: because text colors are defined as tokens like --content-primary and --content-tertiary rather than raw hex values, contrast relationships are baked into the system rather than left to per-component judgment calls. When the palette shifts for a case study, the contrast hierarchy is preserved because the semantic mappings were designed with that constraint in mind.
Testing with a Screen Reader
Building with semantic markup is a start, but it does not replace actually using the site the way assistive technology users would. I tested navigation flows with VoiceOver on macOS, stepping through every page to confirm that heading order made sense, interactive elements were properly labeled, and the reading sequence matched the intended content flow. This process caught a handful of issues that looked fine visually but created confusion when read aloud—a reminder that accessibility testing is not something you can fully automate or assume from clean markup alone.
The site also respects prefers-reduced-motion, prefers-reduced-transparency, and pointer capability media queries. On devices that report a preference for reduced motion, all view transitions and hover spotlight effects are disabled entirely. On touch devices without fine pointer support, the mouse-tracking effects are suppressed—because a feature designed for a cursor should not degrade the experience for someone without one.
