design trends

Running Surface

The running surface is the live application built in code that serves as the design environment for product work in 2026. Designers no longer spend their days crafting static frames in Figma that approximate what the product might look like. Instead they open the real repo in Cursor or use v0 to generate components that appear in a running dev server. They edit real React components with real Tailwind classes and see the results instantly. The surface runs on the actual stack the team ships. Production fonts load exactly as users will see them. Breakpoints respond the way the browser enforces them. Every state from hover to focus to loading to error to empty exists because the code requires it. Tools like Lovable let solo designers spin up entire apps from a prompt and then refine the running product without any artboard step. The Vercel UI registry acts as a living palette of real components that you own and modify. This approach collapses the distance between design and engineering. The artifact you tweak is the artifact users receive. No translation. No implementation step. The five differences from traditional design become obvious here. Fidelity is perfect rather than approximate. Speed is measured in seconds rather than days. Collaboration happens in the diff not in comment threads. The handoff is deleted because design is implementation. Edge cases surface immediately because the surface cannot render without handling them. In Figma edge cases are something you remember to draw. On the running surface they are something the code forces you to discover. This model ships better product because it cannot lie about the experience.

What the running surface is not is as critical as what it is. It is not Figma with AI plugins that try to bridge the gap to code. It is not a set of beautiful mockups that look perfect in presentations but bear little resemblance to the shipped product once real data fonts and interactions get applied. It is not a parallel universe where the design system lives in Figma tokens while the code uses different values leading to silent drift over time. It is not the fantasy of perfect handoff where a designer delivers a file and an engineer uses dev mode to extract specs and somehow gets it right. It is not the six month redesign delivered as a PDF that gathers dust because the company pivoted twice before engineering could start. The running surface has no room for these outdated patterns. It demands the designer participate in the codebase. It requires the team to treat code as the source of truth with Figma used only for brand exploration or downstream documentation. It rejects any workflow where the thing the designer makes is different from the thing the user touches. This honesty is brutal at first but it compounds into faster cycles and higher quality output. The running surface is not for everyone on day one. Designers must learn to read code at least at the level of understanding components and tokens. Teams must have some form of component library even if it is the basic shadcn setup. Without those pieces the friction outweighs the benefits.

Take Linear as a concrete example of the running surface in action. In 2026 their design team does not produce final Figma files for new features like their AI powered triage system. A designer starts by prompting v0 with a description that includes their design tokens for consistent styling. The output is a working component that they fork into the Linear codebase. Using Cursor they edit the running surface directly. They test with real issues from their workspace. This reveals edge cases like very long issue titles that break the layout in ways no Figma frame would have predicted unless explicitly drawn. They adjust the component add proper loading states for the AI suggestions and ensure keyboard navigation works seamlessly. The team reviews the change through a deployed preview link where they interact with the running surface not a prototype. The PR merges and the feature ships without any traditional handoff. Stripe offers another strong example. Their design system is code first. Figma serves as generated documentation pulled from the code rather than the other way around. When designing updates to their terminal checkout experience designers work inside the actual components. They use real test cards and simulate different network conditions to see how the running surface behaves. The empty state for no saved cards and the error state for declined transactions get designed in context with the primary flow. This prevents the post launch surprises that plague teams using static designs. Anthropic designers work on the running surface inside their own product using Claude to help generate and refine React code for the interface. A recent change to the settings panel was conceived tested and shipped entirely on the running surface with no static mockup ever created. These examples illustrate how the running surface changes the output from approximations to honest experiences that work from day one.

Turn to the running surface when the work you are doing is product design that will ship to users in the next sprint. It is ideal when iteration speed is your constraint and when you have a design system as foundation. Use it for interactive elements where hover focus scroll and motion matter. Linear Stripe and Anthropic all live here because it lets them move faster than competitors still stuck exporting Figma files. The code first audit from the parent article offers the test. If you answer yes to three or more of the five questions the running surface is your next step. Do not use it for brand identity exploration before the codebase exists. Figma still owns logo studies type scales and color systems. Skip it for team alignment sessions and journey mapping where FigJam has no equal. Teams where designers cannot read code should not start here. Build that muscle first through small edits and pair programming with design engineers. Early stage products might use Lovable to get a running surface up quickly but must commit to proper code as soon as the direction is validated. The bias must shift. Every new project should default to the running surface unless there is a clear reason to start in Figma. The old pipeline of frames to handoff to implementation is dead. The teams that recognize this are pulling ahead.

The running surface forces your product designs to confront reality immediately and that is why it wins.

Related terms

Keep exploring