DesignSpec
A searchable encyclopedia of UX principles for UI components — built because designers deserve to understand what they build, not just copy it.
Everyone's Building Design Systems. Almost Nobody's Researching Them.
I kept seeing the same pattern play out — on teams I worked with and across the broader design community. A designer opens Figma, pulls in a UI kit, maybe runs a component library through an AI tool, and ships a design system in a week. It looks consistent. It looks professional. But ask them why the modal closes on backdrop click. Ask them why that empty state uses an illustration instead of inline copy. Most of the time there's no answer — because the decision was never made. It was inherited.
The problem isn't that designers use tools and references. It's that the industry has made it so easy to move fast that the research step has quietly disappeared. And with AI now able to generate entire component libraries on demand, that gap is getting worse, not better.
A design system should be a record of intentional decisions — not a collection of assumptions wearing a design system's clothes.
The Problem Isn't Access to Components. It's Access to the Reasoning.
There's no shortage of UI component libraries. What's missing is a clear, searchable resource that explains why components work the way they do — the UX principles, accessibility requirements, edge cases, and failure modes that should be understood before any design decision is made.
I wanted something I could open mid-project and look up: when does a tooltip become an inline message? How many items before a select becomes a problem? What makes a modal appropriate versus a drawer? Not blog posts. Not a 40-page PDF. A fast, searchable reference built specifically for the moment a designer needs to make a call.
A Living Encyclopedia for Design Standards.
DesignSpec is a searchable web app where designers can look up any UI component and get the researched UX principles behind it — do's, don'ts, accessibility guidelines, and real-world implementation patterns — in plain language, in seconds.
The core interaction is simple: search a component, get the reasoning. No accounts required, no paywalls, no noise. Each of the 43 components is documented across 6 structured sections including interactive examples, sourced UX principles, WCAG accessibility guidelines, and platform-specific code snippets.
Homepage — searchable component library with category filters
258+ Documented Sections. Each One Earned.
Each component page goes deep — interactive variant examples, an accessibility checklist, UX principles cited to primary sources like Nielsen Norman Group, Fitt's Law, and Material Design Guidelines, plus implementation notes and a clear do/don't section. This isn't generated filler. Every entry was reviewed against real sources.
AI Accelerated the Build. The Judgment Was Mine.
I want to be transparent about how this was made — especially for a project about design standards. AI was a tool, not the author.
Lovable handled the build based on my design direction and component specs. I directed layout, rejected 3 homepage iterations before landing on the final direction.
Claude drafted initial component documentation. I edited every entry for accuracy, cross-referencing against NNG, WCAG, and platform HIG docs. Generated ≠ verified.
Visual direction explored through prompting and iteration. Chose 1 direction from ~12 explored. All final design decisions — layout, type, color, hierarchy — were mine.
The gap between the first AI-generated draft and the final product is where my work lives. Any designer can generate a component library. The skill is knowing which decisions to keep, which to kill, and why.
The Hardest Part Wasn't Building It. It Was Deciding What Was True.
The biggest challenge with DesignSpec wasn't technical — it was editorial. AI can generate UX documentation quickly, but generated content has no point of view and no accountability. I had to review every component entry and ask: is this actually correct? Is this principle well-established, or is it a plausible-sounding assumption?
For some components, that meant going back to primary sources — Nielsen Norman Group, WCAG documentation, platform Human Interface Guidelines — and cross-referencing what was generated against what's actually researched and documented. That process took longer than the build itself. But it's the work that makes the product worth using.
Building for Other Designers Is the Hardest Design Brief.
Designers are a critical audience. They'll notice immediately if something doesn't meet the standard it claims to hold. Building DesignSpec meant I couldn't cut corners on the content — the whole premise of the project is that shortcuts are the problem.
That accountability made me a better designer on this project than I am on most. When you're the designer, the developer, the editor, and the first user, there's nowhere to hide. Every decision either holds up or it doesn't.
The other thing I took away: having a real point of view matters more than having a perfect product. DesignSpec exists because I believe designers should understand what they build. Products with a clear point of view attract the right people.