Personal project · 2026 Live document
This
Portfolio.
Design decisions, process log, and honest annotations from building this site. Written and updated alongside the build, not after it.
Building a portfolio is a design problem. Most designers treat it as a production task: execute a layout, paste in case studies, ship. I treated it as a product.
The secondary thesis: AI tools have changed what "solo designer who can build" actually means. This portfolio is the proof of concept. Every HTML file, every CSS token, every accessibility decision was written with Claude as implementation partner. No Webflow, no template, no handoff. I owned the brief, the critique, and every directional call.
The question this project is trying to answer: Can a designer own the full product stack, from concept to shipped, accessible and production-grade, without being an engineer? The answer, turns out, is yes. With caveats.
This case study is written alongside the build, not after. The annotations are real-time, not reconstructed. The process log shows what actually happened, not a cleaned-up version of it. That's intentional.
Constraints first.
I started by defining what I wouldn't do, because constraints produce better decisions than open-ended briefs.
| Constraint | Decision | Why |
|---|---|---|
| No build tooling | Plain HTML/CSS, no Webpack, no framework | Zero deploy friction. Vercel serves static files. Simplest possible stack. |
| Protected work at previous employer | Anonymise all screens, brand names, logos | Can't show real product. Had to design around it. |
| Solo, no design team | AI as critique partner | Needed something to push back. Used Claude as a second opinion. |
| Must be accessible | WCAG AA throughout | Accessibility is in my case work. The portfolio had to prove I actually apply it. |
| No AI-generated look | Every visual decision owned manually | AI-generated portfolios look the same. Wanted to avoid the tell. |
The "protected work" constraint is the most interesting one. The cases can't show real screens, so they have to be good enough to be credible without visual proof. That forced a writing-first approach to the case studies. The argument carries the weight that screenshots usually do.
Editorial or neo-brutalist?
This was the first real design question. I started with a neo-brutalist direction: thick borders, hard shadows, high contrast, yellow/lime palette, partly because it felt strong and partly because the Sudokue project already uses it.
"I was thinking if Editorial style could be better, since the Sudokue project is the only one using this Neobrutalistic approach. The other ones are cases I've done in my work. With an Editorial approach I could showcase my work in different styles, varying from project to project."
This decision was made by pressure-testing the logic out loud with Claude, asking for a way to stress-test the one I was leaning toward. The AI's role was as a sparring partner, not a decision-maker. When I described the neo-brutalist direction, it flagged the risk (loud frame overwhelming measured healthcare work). When I described the per-case accent system as a solution, it confirmed the logic held.
That's a different use of AI than most people mean when they say "AI-assisted design."
Tokens with reasons.
Every colour was chosen for a reason. The token architecture is small: six primitives, three shadow steps. Each value was decided, not picked.
Per-case accent system.
Each case redefines --accent locally. The accent colours do emotional work, not decorative work.
Four patterns worth noting.
These are the interactions that required real decisions. Not UI widgets: UX calls where the wrong choice would have broken something.
.card-cta::after { content:''; position:absolute; inset:0; } One focusable element, fully tappable area.<abbr title="..."> with CSS ::before/::after tooltip. No JS, no library, consistent across every case file.pointer-events: none on children. "Case study coming" chip instead of CTA. Visually honest: WIP looks like WIP.Not "AI-generated." Directed.
The site was built over several sessions in Cowork (Claude desktop app), with Claude as implementation partner. Not "I described a portfolio and it appeared." More like pairing with a very fast developer who needs direction on everything that matters.
- Visual direction: colours, type, layout
- Copy: all case text, labels, taglines
- Design decisions: what to include, what to cut
- Critique: what's wrong, what to change
- Accessibility requirements
- QA verdicts: approve / reject / fix
- Writing all HTML/CSS
- Suggesting structure when asked
- Flagging implementation options
- Executing changes precisely
- Implementing semantic HTML and ARIA
- Running structured QA review
There were moments where I accepted something that wasn't quite right because iterating felt costly. That's a failure of direction, not a success of AI. The places where the portfolio is strongest are the places where I was most specific about what I wanted.
Vague direction produces generic output. Specific direction produces something that looks designed. This is the skill that transfers to any AI-assisted workflow, not "can you use the tools" but "can you specify clearly enough to get something worth using."
"Use the HTML abbr title element for any acronym or abbreviation in the page. Style it with a subtle dotted bottom border instead of the browser default underline. Add a custom CSS tooltip using ::after and ::before pseudo-elements that appears on hover. Don't use any JavaScript or third-party libraries. Create a list of the words based on what you already know inside the cases."
This prompt is about 60 words. It specifies the HTML element, the styling override, the implementation constraint (no JS), and asks the AI to do contextual work (build the word list from existing content). The result was applied globally across all four case files in one pass. That level of specificity is what makes the output usable without revision.
What actually happened.
The iteration log below is the working record: decisions made, why they were made, when. This is the raw material, not a cleaned-up version of it.
Early direction decision (~Apr 2026)
First real design question. Started with neo-brutalist direction. Then questioned it. The tension: neo-brutalism communicates energy and personality. But if all my case work is healthcare UX, measured, accessible, system-driven, a loud portfolio might feel mismatched.
What I decided: Keep neo-brutalism for the homepage and project cards. Per-case accent colours (teal, violet, navy, emerald) let each case have its own visual register without rebuilding the layout.
This is the kind of decision that's hard to make alone. I made it by pressure-testing the logic out loud with the AI, asking for a way to stress-test the one I was leaning toward.
Hero stripe colour (Apr 2026)
Hero stripe changed from yellow to lime. Used two separate accent colours in one section, looked unfocused. Resolved: pick one, use consistently.
Footer attribution (May 2026)
"Built in Cowork" attribution removed from footer. Self-promotion inside the product felt off. The AI build is a thesis of the portfolio, not a marketing claim on every page.
Nav logo: QA catch, May 2026
Nav logo changed from span to a. Users expect logos to navigate home. QA flagged it. This is a UX miss. The fact it had to be caught at QA means it should have been caught in design review.
Bio rewrite: 3 passes total
First version was generic. Needed to be more specific about the AI workflow angle. Pass 2: too much hedging ("I've been exploring..."). Pass 3: direct claims, evidence in the work, not in the bio.
Iterations log.
Built in, not bolted on.
Accessibility is in my case work. The portfolio had to prove I actually apply it, not just claim it. Every decision below was made before QA, not fixed after it (with one embarrassing exception).
#main, visible on focus. Keyboard users need to bypass nav.<nav>, <main>, <section aria-labelledby>, <footer>. Screen reader navigation works.role="listitem" in role="list" container. aria-label on CTA. One focusable element per card, not multiple links.3px solid var(--black), outline-offset: 3px. Visible, on-brand, not default browser blue.opacity: 0.4 on small text fails WCAG AA, replaced with explicit hex values at 4.5:1 minimum.@media (prefers-reduced-motion: reduce) on all transitions. Vestibular disorders, user preference.aria-labelledby pointing to h1 id, not aria-label overriding visible text.<dl> for hero meta (Role, Location, Focus, Status). Semantically correct for label/value pairs.The original meta-label CSS used opacity: 0.4 on black text. At small size and 800 weight, this produced approximately 2.5:1 contrast against white. That fails WCAG AA by a significant margin.
Caught during the QA pass, not during design. Replaced with color: #767270 (4.7:1). The embarrassment is worth logging: this is a portfolio where accessibility is a listed skill. The failure was basic. Catching it before publish matters. Catching it in design would have mattered more.
Eight things found before publish.
I ran a structured QA pass using the senior-qa-agent skill in Cowork, covering WCAG criteria, responsive layout, interaction states, and dead code in one pass. These are the findings.
The medium-severity contrast failures are embarrassing to ship on a portfolio where accessibility is a listed skill. They were caught before publish. They should have been caught in design. The QA pass surfaced them because it was structured: not "does this look OK" but "does this pass specific criteria."
Running a structured QA skill before every project ships is worth it. The output is specific enough to act on immediately.
What I'd do differently.
- Sessions with precise direction ("change this stripe from yellow to lime, text stays black") produced better results faster than "the colours feel off, what do you think?" Vague prompts produce hedged output.
- The best hours were the ones spent writing down exactly what something should do before any surface was touched. That spec becomes the prompt. That prompt produces something usable without revision.
- The contrast failures on the meta labels were basic. Catching them before the first share would have been better, not because they're hard to fix, but because they undermine the claim.
- QA is a skill, not a step. The structured approach (specific criteria, one pass covering all files) produced eight actionable findings in the time it would have taken to manually check two pages.
- Most of the iteration notes are reconstructed from memory, not from a live log. A running decision log from the start would make this case study stronger, surfacing contradictions earlier.
- The WIP notes document exists precisely because this lesson was learned mid-build. The first half of the build isn't well-documented. The second half is.
- Treating the portfolio as a product (brief, constraints, audience, then design) produced a more coherent result than "execute a layout."
- The per-case accent system was the right call. It solves the visual variety problem without requiring a different layout for each case.
- The AI collaboration model (direction from me, execution from Claude) is the right shape. Output quality correlates directly with direction quality.
A designer can own the full product stack, from concept to shipped, accessible and production-grade, without being an engineer. The answer is yes, with a caveat: the quality of the output is a direct function of the quality of the direction. AI lowers the floor on execution. It doesn't raise the ceiling on thinking. The ceiling is still yours.