Wyatt Spicer
Portfolio Site — Design,
Build, and Deployment

The most credible thing a web designer can do is build their own portfolio to the same standard they apply to client work. Wyatt Spicer's portfolio site does exactly that. The same accessibility practices demonstrated in the Adams Internal Medicine case study are present here — skip links, aria-current, focus-visible states, semantic landmarks. The same deployment readiness demonstrated in the Keyboard Board case study is here — canonical tags, OG metadata, CSP, Netlify Forms, robots.txt, sitemap. The same attention to content that characterizes every project in the portfolio is present in how the portfolio describes itself.

This isn't accidental. The portfolio was built and audited iteratively against the same checklists used for client projects. It passed the same security, accessibility, and SEO reviews. It would be embarrassing to showcase meticulous work on a medical practice website and then have your own portfolio missing a viewport meta tag or posting a form to nowhere.

The portfolio covers UX/UI design, web design, 3D fabrication, and art/audio/visual work. Each discipline has its own dedicated page with project content — case studies, embedded prototypes, slide decks, video work, and galleries — rather than everything compressed onto a single scrolling home page. The structure is honest about the breadth: this is not one thing, it's four things that share a designer.

The palette pairs a vivid electric blue accent (#315efb) with a warm coral secondary (#f27d42) against an off-white blue-tinted background. The combination reads as energetic and contemporary without tipping into aggressive — right for a creative technologist who works across UX, code, and fabrication, and needs a personal brand that signals range without noise.

Typography uses Space Grotesk for body and UI text and Oswald for the logo mark. Both are loaded from Google Fonts. The CSS is 178 lines — a deliberately minimal stylesheet that handles the full design system without accumulating technical debt. All interactive components use CSS transitions, and the `prefers-reduced-motion` media query disables transitions and scroll behavior for users who've requested it.

The portfolio's entire JavaScript is 45 lines in a single IIFE. It handles four things: mobile menu toggle with `aria-expanded` management, active nav state detection with `aria-current="page"` and `.active` class, copyright year auto-population via `[data-year]`, and scroll-triggered reveal animations via `IntersectionObserver` with a graceful fallback for browsers that don't support it.

That's the right amount of JavaScript for a portfolio site. No framework. No build step. No dependencies. No supply chain. The `defer` attribute on the script tag means it doesn't block rendering. The IIFE wrapping means nothing leaks to global scope. The IntersectionObserver fallback means content is still visible even when the animation system is unavailable.

The final build ships with a comprehensive Content Security Policy in `_headers`. It was the last gap between the portfolio's own security posture and the standard set by the AIM client project — and it required precision because the portfolio loads from more external sources than a typical static site:

The CSP was deliberately crafted rather than generated — every directive has a reason, every origin in frame-src corresponds to an actual embed on a specific page. Getting this right on a portfolio with five different embed types (Figma, Google Slides, Canva, YouTube, and local video) required auditing each page individually before writing the policy.

The contact form opening tag currently reads:

`netlify` (bare attribute) duplicates `data-netlify="true"`. `netlify-honeypot="bot-field"` duplicates `data-netlify-honeypot="bot-field"`. Netlify accepts both forms, so this works — but the clean version is just `data-netlify="true" data-netlify-honeypot="bot-field"`. One line to fix, zero functional impact either way.

Every project in this portfolio went through a rigorous audit process. The Adams Internal Medicine site was evaluated against 19 lenses. The Keyboard Board was QA'd across multiple builds. The VisitSPI rebuild was checked against accessibility, SEO, and technical standards before being documented as a case study. The portfolio itself went through the same process — iterative builds, specific issues identified, specific fixes applied, verified against source before closing.

The result is a portfolio site that can be sent to a UX hiring manager, a front-end engineering lead, and a creative director simultaneously and hold up to each of their different scrutiny axes. The UX people can read the GoCapital case study and see structured research process. The front-end people can view source and see semantic HTML, correct ARIA, a real CSP, and 45 lines of clean vanilla JavaScript. The creative directors can look at the visual design and see a coherent system with intention behind it.

That's the goal of a portfolio: not to impress everyone in the same way, but to survive the scrutiny of whoever looks at it most carefully.