Introducing a Design System where none existed

claim 2.1dependent — cites claim 2 (AQTech)

Identified the absence of frontend standards, proposed a Design System, built it from scratch and taught the team how to adopt it.

impactStandardized frontend developmentReduced duplicated componentsBecame frontend reference

Context

AQTech's frontend had grown feature by feature. Each developer solved UI problems locally: three date pickers, four button variants, inconsistent spacing, no shared vocabulary between design and code.

I was an intern. Nobody asked for a Design System, because the cost was invisible: it was paid in small increments on every feature.

Problem

Duplication was the visible symptom; the real problem was decision fatigue. Every feature required re-deciding paddings, colors, error states and component APIs. Reviews argued about pixels instead of logic. Onboarding meant absorbing folklore.

Constraints

—No dedicated time, so the system had to be built alongside feature work.

—No designer ownership: the source of truth had to live in code.

—Vuetify was already in the stack; the system had to wrap it, not fight it.

—As an intern, I had no authority to mandate anything. Adoption had to be voluntary.

Alternatives Considered

—Adopt Vuetify defaults everywhere. Rejected: defaults didn't encode our domain patterns (dense engineering data, asset hierarchies), and that gap was where the duplication grew.

—A written style guide without code. Rejected: documentation that requires discipline loses to deadlines.

—A component library wrapping Vuetify with our tokens, patterns and docs. Chosen.

Decision

Build the Design System as the path of least resistance: importing the system component had to be strictly less work than writing a local one.

Every component shipped with usage docs and copy-pasteable examples. I migrated the highest-traffic screens myself first, so the system proved itself before anyone was asked to adopt it.

Trade-offs

—Wrapping Vuetify meant inheriting its constraints and upgrade cycle. Accepted for velocity.

—Building alongside feature work meant slow, incremental coverage. Accepted, because it forced the system to grow from real needs instead of speculation.

—Voluntary adoption is slower than mandate. Accepted, and it's why the standards survived after I left.

Implementation

TypeScript component library on Vue 3 wrapping Vuetify, paired with a Figma component library kept in sync with the code: design tokens, form patterns, data-density presets and accessibility defaults baked in. Documentation lived beside the code and every component page answered 'when do I use this instead of X'.

Adoption strategy: migrate loud screens first, pair with each developer on their first use, and treat every 'the system can't do X' as a bug in the system, not the developer.

Impact

—Frontend development standardized; duplicated components stopped appearing in review.

—New features started from composition rather than construction.

—I became the team's frontend reference, and the standards remained after I left.

—The experience produced a durable principle: a Design System succeeds only when adoption becomes the easiest path.

Lessons Learned

Authority is not a prerequisite for standards; evidence is. Migrating real screens before asking for adoption converted skeptics better than any argument.

The best engineering standards are adopted voluntarily; the system must out-compete the alternative on effort, not on principle.

Evidence

Capabilities claimed and demonstrated: Design Systems (built one from zero), Technical Leadership (adoption without authority), Developer Experience (adoption-as-product mindset), Frontend Engineering (the components themselves), Accessibility (defaults baked into components, not retrofitted per screen).