Minimum Viable Visual System

A minimum viable visual system is the three layer stack that replaces the fantasy of a full design system for most teams. The bottom layer contains design tokens. These are specific values for every color your product uses, every type scale from 12 pixels to 48 pixels, every spacing increment based on a 4 pixel grid, every border radius choice limited to two options, and every shadow style from subtle to heavy. Teams like Vercel define these in a single Tailwind configuration file that gets imported everywhere. The same values live in Figma as variables so design and code never drift. Updating the primary brand color means changing it in one place and the change propagates everywhere the next time someone pulls the latest code or refreshes their design file. This layer alone eliminates 70 percent of visual inconsistency. The middle layer consists of primitives. These are the fundamental accessible components that every interface needs. Instead of building your own button from scratch you take the Radix primitive through Shadcn and style it with your tokens. The same goes for modals, dropdown menus, form inputs, data tables, tabs, and toasts. Because the code lives in your repository you can modify it when needed without waiting for upstream approval. Updates happen on your schedule. AI tools like v0 and Cursor generate code against these primitives by default which means new features come out already matching your visual language instead of fighting it. The top layer is taste. No amount of tokens or primitives can replace a human who understands visual hierarchy, knows when to increase contrast beyond the token set for an important call to action, or decides that this particular dashboard needs a completely custom layout that bends the normal grid rules. At Notion this taste layer keeps the entire product feeling like it was designed by one person even though dozens contribute. The taste keeper reviews new surfaces, maintains the small set of allowed patterns, and says no to unnecessary new components that would dilute the system.

This stack is not a design system in the traditional sense. It lacks the dedicated roadmap, the full time engineering support, the comprehensive documentation site, the governance process, and the quarterly release cycle that define real systems like Shopify Polaris or GitHub Primer. Those are products in their own right with their own customers and their own profit and loss. A minimum viable visual system has none of that overhead. It is not the 400 component Figma library that looks impressive in a pitch deck but becomes a source of technical debt six months later when half the variants no longer match production. It is not the maintenance bill disguised as maturity. It is not cosplay. It is the honest acknowledgment that most teams are not Atlassian and should stop acting like they are.

Concrete examples of this approach working at scale are easy to find in 2025 and 2026. Linear runs on an extremely minimal token set paired with custom primitives for their command interface and issue tracking table. Their design lead maintains the taste layer with regular audits that keep the product looking sharp without requiring a design systems team. The entire visual system fits in fewer than five files yet produces interfaces that feel more coherent than products backed by 20 person design infrastructure groups. Vercel combines a very detailed Tailwind token configuration with a focused set of dashboard specific primitives for patterns like deployment timelines and edge function logs. Their taste comes from a design team that obsesses over motion and micro interactions. The marketing site at vercel.com and the dashboard share the exact same foundation so the brand feels continuous. No separate design system repository exists. No Storybook instance that the team has to keep alive.

Cal.com went one step further by extracting their primitives into a public repository that other teams can use. This turns their minimum viable visual system into a mild competitive advantage without turning it into the full maintenance nightmare of something like Atlassian Design. Resend ships beautiful email marketing interfaces built on Shadcn primitives and custom tokens. Prompts in Claude produce output that is 90 percent there because the AI knows the Shadcn patterns intimately. Their engineers then apply taste adjustments in minutes rather than days. Notion represents the outer edge of what this model can support. Their product has thousands of surfaces yet they maintain coherence through an aggressively small set of components and tokens. New features are reviewed against the existing vocabulary. If a new pattern is needed it is added only after careful consideration by the taste keepers who protect the visual budget like it is their own money.

Adopt a minimum viable visual system when your team has one primary product and fewer than 50 people touching frontend code. Use it when speed matters more than theoretical future proofing. Use it after you have validated that your product direction is stable enough to invest in consistency but not so complex that you need infrastructure. Use it in the AI era because every code generation tool on the market defaults to Tailwind and Shadcn patterns. Fighting that momentum with a custom design system built from scratch is a losing battle. Deploy it the moment you notice your Figma file has more components than your actual product has screens.

Avoid the minimum viable visual system only if you meet at least three of the following conditions. You run multiple distinct products that must share a single brand identity like Atlassian does across Jira, Confluence, and Trello. Your engineering organization exceeds 150 people with UI contributors spread across many teams. You have dedicated design infrastructure staff already budgeted and external developers consuming your components as an API. Or you work in a heavily regulated space like healthcare or finance where visual patterns must encode legal requirements and pass audits. In those cases the maintenance cost of a full design system becomes an investment instead of a tax. Most startups and even many scale ups never reach this bar. They build design systems anyway because it feels like the mature thing to do. The result is slower velocity, more Friday afternoon debugging of drifted components, and a visual debt that compounds faster than AI can fix it.

Tight tokens, thin primitives, and strong taste will always beat a bloated design system you cannot afford to maintain.