# Designing This Portfolio > The site itself, documented as a case study: one codebase for screen, print, and two languages — every claim measured or marked pending. - **Case study:** https://yazdanjoo.de/projects/designing-this-site - **Author:** Sanaz Yazdanjoo (UX Engineer) - **Role:** Researcher, Designer, Frontend Engineer & QA (solo) - **Timeline:** Ongoing · continuously iterated - **Status:** published A Case Study in Designing Under Constraint — One Person as Researcher, Designer, Engineer, and QA ## About A case study on the site you are reading. I built it alone: research, design, frontend, QA. It is React and Tailwind, and it has to work for three readers at once — a recruiter with thirty seconds, an engineer who opens the source, and a hiring manager holding the printed A4 CV. What follows are the trade-offs that came out of that. ## Wireframes Every case study here uses one layout. Above the xl breakpoint it runs in three tracks: a sticky numbered section rail on the left that collapses to a 56-pixel number strip, the prose column in the middle at a 68ch measure (88ch once the rail is collapsed), and a pull-quote rail on the right. Below md the rail becomes a plain section index under the header — a wrapped list of numbered links that scrolls away with the page, because a pinned bar inside a phone's scroll container was the one part of the layout that kept misbehaving on iOS. Below xl the pull-quote is dropped: it only repeats a sentence from the paragraph next to it. The order is not just convention. Every case study renders through the same ProjectTemplate({ meta, children }), and a fixed SECTIONS array decides what can appear and when — a data key that is not in it cannot render. One caveat on the figures below: I wireframed this site in the browser, so they are drawn from the shipped layout code, not from sketches that came first. ## Design System Ink & Bloom, in short: a warm paper-and-ink palette, one loud coral accent, and a gold highlighter used at most once per page. Bricolage Grotesque for display type, DM Sans for body, Caveat for handwritten notes, and Framer Motion draw-ins that all share one easing curve. The table below reads its values from theme.css at render time instead of copying them, so it updates with the site rather than drifting from it. Two rules the numbers don't state on their own: each accent has a -500 step for large text and shapes and a -600 step for anything small enough that WCAG AA bites, and the gold sits outside that split — it is a background wash, never a text colour. Every icon in the interface, from arrows and chevrons to the ? and ! marks, is drawn with the same ~1.6–1.8px nib in one component file, so no icon font or library ships in the bundle. The full specimen sheet is the living style guide linked under Prototype. The same system is also published as a Figma Make kit — tokens, styles, components and the drawn-line rules, linked below. ## Results Lighthouse 13.4.0 against production (emulated desktop, 24 August 2026): Performance 99, Accessibility 100, Best Practices 100, SEO 100. Mobile emulation the same day: 77, held down by a 4.4-second Largest Contentful Paint. Ten days earlier performance was 66, with a 0.261 layout shift, 340 ms blocking time and roughly 733 KiB of unused JavaScript. What closed the gap: a route-skeleton fix for the layout shift, lazy loading on every case-study figure, dead chunks removed, and a card/data split that took all five case studies' prose off the shared path (aggregator chunk 57 KB → 3.9 KB gzipped). Two optimisations I looked at and dropped: LazyMotion would save an estimated 20–25 KB gzipped but touch 35 files in the hand-drawn animation system, and splitting the profile data would break the local editor that writes it. Neither is worth it at these scores. The honest gap left is mobile LCP — a client-rendered hero can't paint before the JavaScript lands. Still open: the manual WCAG 2.1 AA contrast pass across every token pair (the automated audit found no failing pair, which is not the same thing), the keyboard-only run through the primary path, confirmation the CV prints to exactly one A4 page, and the two planned tests — time to answer 'what does she do?' and first-click success on the navigation. ## Limitations - Sole author and sole evaluator. Every judgement here — structure, wording, visual system — is mine and unreviewed; there is no second designer on record who disagreed with any of it. - No user research has run on the site itself. The 5-second test and the first-click test are defined and pending, so every usability claim here describes a mechanism in the source, not an observed effect on a reader. - The Lighthouse numbers are single lab runs under emulation, from one machine and one network. There is no field data from real visitors, and mobile LCP in particular is the metric emulation flatters least. - An automated accessibility score of 100 is not conformance. The manual contrast pass across every token pair and the keyboard-only walkthrough are still open, and nobody has run the site with a screen reader or with assistive technology in an actual user's hands. ## Key Numbers - **99** — Lighthouse — Performance - **100** — Lighthouse — Accessibility - **100** — Lighthouse — Best Practices - **100** — Lighthouse — SEO ### Pending ### Label WCAG 2.1 AA contrast, all token pairs ### Pending ### Label Keyboard-only + first-click task success ### Pending ### Label CV print length (target: 1 A4 page) ### Pending ### Label 5-second test — time to answer ‘what does she do?’ ## Outcome No outcome yet. Once the sessions run, whatever actually changed goes here: a shipped fix, a reprioritised backlog item, or a finding that changed nothing. ## Methods - Component Architecture & Design Systems Engineering - Bilingual Content Architecture (EN/DE) - Print-CSS Engineering (screen-to-A4) - Invariant / Contract Testing (Vitest) ## Tech Stack - React - Vite - Tailwind CSS - Framer Motion - React Router - Vitest - Testing Library - ESLint ## Skills & Topics React · Vite · Tailwind CSS · Framer Motion · React Router · OpenAI API · Prompt Engineering · Design Systems · Component Architecture · Information Architecture · Responsive Design · Accessibility · Performance Optimization · SEO · Internationalization (i18n) · Print CSS · Automated Testing (Vitest)