The argument
Why a portfolio needs a system, not just a style
A portfolio collects artifacts from different years, products, and moods. Without a system, the work reads as a series of mood boards. With one, it reads as a body of work.
The izaias design system is small on purpose. It documents the tokens, components, patterns, voice, and accessibility decisions behind three production sites — the design portfolio, the engineering portfolio, and the system documentation itself. Every page on every site is built from the same primitives.
Most of the system is hand-rolled. That is deliberate, not a failure of taste. Hand-rolling keeps constraints visible, tradeoffs arguable, and the boundary between my decisions and the next contributor's clear.
Foundations
Warm-neutral palette, serif-sans pair, one motion curve
Six warm neutrals and one accent. Foreground is near-black ink; background is paper cream. The contrast pair reads as paper and ink in any light. Every other color in the system derives from those two.
Typography pairs Instrument Serif for display with DM Sans for body. Both are humanist: the serif is a 19th-century reading face with modern discipline, the sans is neutral without becoming corporate. They sit well together on a single line.
Motion is a single easing curve used everywhere. No "marketing easing" or "product easing." One opinionated curve across every surface.


Components
Production artifacts, not Figma frames
Buttons, inputs, callouts, figures, navigation, dialogs, sheets, toasts. Every component ships in production. The documentation renders the actual code, and the token values in the docs are the same values in the CSS.
Variants, states, sizes, and accessibility notes are documented for every component. The doc primitives are React components — the same ones that render this portfolio render the case study you are reading.
Live code, not screenshots
Every demo runs the real component. The copy button copies current production code. The spec is the implementation.
Doc primitives as components
Callouts, tables, code blocks, swatches, type ramps, spacing strips, radius grids. Built once, used everywhere. No Markdown.
Accessibility is a section, not a footnote
A dedicated page documents focus order, keyboard behavior, ARIA usage, reduced motion, and contrast. The same notes ship in the case studies.
Voice & tone
Written like an essay, by design
The voice & tone page is not a style guide. It is a set of principles and do/don't examples, written in the same voice it documents. A voice guide that reads like a brand deck is a failure of taste. One that reads like a friend explaining a decision is the work itself.
One voice across every page: home, case studies, long-form articles, documentation. That consistency is not accidental. The system picks one voice per page and writes accordingly.
Accessibility
WCAG AA decisions that hold under inspection
Contrast pairs tested at WCAG AA across every foreground/background combination. Focus rings visible, soft, and on-brand. Reduced motion honored at the CSS level. Touch targets meet the 44px minimum. Dialogs trap focus. Toasts are polite by default.
None of this is novel. All of it is documented with the exact token, the exact CSS, and the exact behavior. The accessibility page is the receipt.
Accessibility checklist
- 1Contrast: every foreground/background pair documented and tested at AA.
- 2Focus: visible, 2px outline, 2px offset, on-brand. Never removed, never replaced with color alone.
- 3Keyboard: every interactive element reachable and operable. Tab order matches reading order.
- 4Reduced motion: all animation gated behind a media query. Full motion plays only when the user opts in.
- 5ARIA: used to clarify, never to replace semantics. Roles, names, and states before attributes.
What is public
The whole system, live in production
The codebase is the source of truth: tokens, components, doc primitives, writing. The doc site and the portfolio are the same code, deployed separately, sharing the same primitives.
The system is small. Not a Figma library. Not a component marketplace. A small set of decisions, made once, written down, and shipped.