At Perplexity, the design system lives in the codebase, not Figma. Designers contribute directly to the frontend, creating a single source of truth that eliminates drift between design files and production code, forcing a highly practical and collaborative process.

The idea that design systems stifle creativity stems from the high cost of re-coding components after a design change. In a world with a single source of truth, where design changes automatically update the code, this cost disappears, allowing systems to be radically changed without engineering overhead.

Instead of iterating on prompts for single assets, focus on building reusable systems. This approach ensures brand consistency, saves time, and empowers non-designers to create on-brand assets efficiently by turning complex workflows into simple interfaces.

Inspired by architect Christopher Alexander, a designer's role shifts from building the final "house" to creating the "pattern language." This means designing a system of reusable patterns and principles that empowers users to construct their own solutions tailored to their unique needs.

Teams can cultivate a shared sense of taste by encouraging constant and rigorous critique of both internal and external work. This process allows the team to self-regulate, learn from each other, and elevate their collective craft without top-down mandates.

While brand consistency is a benefit, the primary business impact of a well-built design system is operational efficiency. It drastically accelerates speed to market for new features and slashes onboarding time for new hires because the system's intelligence is effectively self-documenting.

Technical tools are secondary to building a successful design system. The primary barrier is a lack of shared vision. Success requires designers to think about engineering constraints and engineers to understand UX intent, creating an empathetic, symbiotic relationship that underpins the entire system.

Developing a team's creative taste isn't abstract. It's a trainable skill built by establishing a ritual of reviewing great, average, and poor creative examples side-by-side. This process of comparison and discussion calibrates the entire team on what quality looks like.

The founders avoid creating a rigid, atomized design system because the product is still iterating too quickly. They accept a "messy" component library and technical debt as a trade-off for speed. Formalizing a design system only makes sense once the product's UI has stabilized.