Turning a Live Site Into a Documented, Accessible System
Most personal sites do not have a design system.
They have a look.
They have recurring patterns.
They have preferences, instincts, and habits that get repeated often enough to feel coherent.
But that is not the same thing.
A real design system is a set of decisions that can be explained, defended, reused, and evolved without the whole thing collapsing into vibes.
That was the goal here.
I wanted the AI-Created site to feel deliberate at every level: color, typography, layout, motion, interaction, accessibility, and page structure.
And I wanted to make those decisions visible.
Not hidden in my head.
Not trapped inside utility classes.
Not implied by a few good-looking screenshots.
Visible.
Public.
Reviewable.
The Initial Spark
One of the early inspirations for this project was Grace Guo's public design system.
What I liked was not just the visual quality.
It was the decision to treat the design system itself as a first-class artifact.
That mattered to me.
It made the system feel like part of the product rather than private documentation sitting off to the side.
That idea stuck with me.
If I was going to build a site that claimed to be intentional, then the system behind it should also be visible and intentional.
I did not want a generic component gallery.
I wanted a page that explained the logic of the site:
- why the palette works the way it does
- why serif is used sparingly
- why dark mode leads but light mode still feels real
- why motion stays restrained
- why route structure matters just as much as button styling
In other words, I wanted the design system to explain the how and the why, not just display a few UI fragments.
Why I Built It
The public site had already gone through multiple iterations.
Different pages were getting stronger.
The brand language was getting clearer.
The product work, stories, and editorial writing were starting to feel like they belonged to the same world.
But I could also feel the risk.
Without a documented system, even a coherent site starts drifting.
One route adds a slightly different card pattern.
Another introduces a new spacing rhythm.
A button starts behaving differently.
Light mode quietly becomes an afterthought.
Accessibility gets handled inconsistently.
Nothing looks obviously broken at first.
It just becomes less solid over time.
I wanted to stop that drift before it became real debt.
So the design system became a way to do three things at once:
- Document the logic behind the current site
- Make future design decisions easier and more consistent
- Demonstrate that AI-assisted design can be rigorous rather than sloppy
That third point mattered a lot to me.
There is a widespread assumption that AI-generated design work is inherently shallow, derivative, and structurally weak.
A lot of it is.
But that is not because the tools make rigor impossible.
It is because most people stop too early.
They let the model suggest aesthetics, but they do not impose enough intent, enough editing, enough systems thinking, or enough quality control.
This project was partly a response to that.
I wanted to show that with the right level of human supervision, AI can help build something that is genuinely disciplined.
Accessibility Could Not Be Optional
One of the most important pushes came from my Kohl's manager, Leverett Alcott.
He suggested that if I was going to do this seriously, I should include strong accessibility rules and guidance as part of the system itself.
He was absolutely right.
That advice sharpened the project.
It is too easy to treat accessibility as a secondary checklist that happens after the visual work is done.
But that approach breaks down quickly.
If the system itself does not encode accessible decisions, then every new page and every new component becomes another opportunity to get it wrong.
So accessibility became part of the design system contract:
- one shared skip-link target
- visible focus rules
- reduced-motion support
- text hierarchy rules that protect readability
- proper ARIA usage patterns
- guidance around semantic naming and feedback states
- explicit rules for keyboard behavior and modal interactions
That changed the character of the project.
It stopped being just a visual language exercise.
It became a product quality system.
And honestly, that is what a serious design system should be.
The Hard Part Was Not the Page
Building the /design-system page was not the hardest part.
The harder part was deciding what the actual system should be.
That required taking a lot of fuzzy instincts and turning them into rules.
For example:
The site uses two distinct reds, not one.
That was not arbitrary.
The brighter red works well as an accent, a signal, and an editorial emphasis color.
But it is not the right red for filled controls carrying white text.
So the system explicitly separates accent red from action red.
The same thing happened across the rest of the system.
Typography needed rules.
Spacing needed rules.
Hero treatments needed rules.
Layout archetypes needed rules.
Motion needed rules.
Light mode needed rules.
And because this was a live production site, the rules also had to survive contact with reality.
They could not just sound good in documentation.
They had to hold up in actual components, actual routes, and actual interactions.
AI Helped Me Move Faster, But Not Looser
AI was involved throughout the process, but not in the way people often imagine.
It did not magically invent a coherent system.
It did not replace taste.
It did not decide what should matter.
What it did do was accelerate a lot of the heavy lifting around exploration, drafting, and implementation.
I used AI to help:
- explore alternative framings for the system
- draft documentation structures
- scaffold components and code paths
- compare naming options
- compress repetitive implementation work
- pressure-test whether the system language was internally consistent
That speed was useful.
But speed is only helpful if you know what you are protecting.
The real work was still human:
- choosing what deserved to become a rule
- rejecting ideas that were attractive but off-system
- deciding what belonged in the public language of the site
- reviewing the output again and again until it felt intentional
That distinction matters.
AI made the work faster.
Human supervision made it coherent.
If anything, a design system makes the human role even more important, because systems punish lazy decisions more than one-off pages do.
It Went Through Multiple Iterations for a Reason
This was not a one-pass project.
The design system evolved through multiple rounds of iteration and review.
Some sections became clearer.
Some rules got sharper.
Some implementation details turned out to be too loosely defined and needed to be turned into actual shared primitives.
That was an important lesson.
A design system is not just documentation about design.
It is also documentation about where your implementation is still too manual.
If the page says you have a system but the codebase is full of slightly different buttons, cards, and field styles, then the page is telling on you.
So part of the work became operational:
- extracting reusable UI primitives
- tightening token usage
- standardizing interaction patterns
- cleaning up focus behavior
- making the documentation consume real production components where possible
That made the system stronger.
It also made the story more honest.
I was not interested in shipping a design-system page that merely described discipline.
I wanted one that reflected discipline in the underlying code.
Why Make the Design System Public at All?
Because public artifacts create a different standard.
When a system is visible, it invites scrutiny.
That is good.
It forces clarity.
It forces consistency.
It forces you to explain your decisions in a way that other people can understand and evaluate.
And in my case, it also serves as proof of a broader point:
AI-assisted design does not have to result in generic interfaces or fragile design-by-prompt.
With enough intent, enough review, and enough product discipline, it can support the creation of something much stronger:
- a real visual language
- a real system of constraints
- a real accessibility contract
- a real implementation strategy
That is the story I wanted this page to tell.
Not that AI can generate pretty screens.
But that AI can help a skilled builder create a solid system when the human in the loop is doing the harder job of judgment.
What This Project Represents
For me, this design system is not just a documentation page.
It is a statement about standards.
It says that even on a small independent site, the work can be systematic.
It says accessibility belongs inside the core design language, not outside it.
It says light mode deserves the same level of care as dark mode.
It says motion should have a purpose.
It says page structure is part of design.
And it says AI can absolutely participate in rigorous design work, but only when the human driving it is willing to edit, challenge, supervise, and refine every important decision.
That is the showcase value of the project.
Not AI without humans.
Not humans ignoring AI.
But strong human intent, using AI as leverage.
That is the difference between generated output and designed systems.
Why This Belongs in My 0→1 Stories
This is a zero-to-one story because the outcome is bigger than the page itself.
The real move was taking a loose collection of evolving design decisions and turning them into a visible, defensible, reusable system.
That shift changed the site.
It changed the codebase.
It changed how future decisions get made.
And it became a concrete example of something I care deeply about:
rock-solid design can absolutely be created with AI, but only when the human standard stays high.
That is the whole thesis.
And this project is one of the clearest proofs of it on the site.