Beyond Figma Thinking: Toward AI-Native Design Tools

Point-solution tools often have this quality. They do one thing exceptionally well, and sometimes expand into doing a category of things well. If a tool becomes popular and refined enough, it may come to embody a standard. The most successful tools define and birth explicit or implicit standards. PDFs, graphics formats, and webpages are all examples. Browsers themselves are expressions of a core standard that allows interoperability across the web.

In work with many handoffs, standards are essential. They are the negotiated layer between one format and another. Standards bring many good things: predictability, interoperability, extensibility. But standards also become constraints. They are embedded in tools, and it becomes difficult to imagine a world beyond what the standard allows. There’s a tension between advancing the standard and adding new capabilities, and the fact that the more specialized a standard or tool becomes, the more rigid the system overall becomes.

Early design tools like FrameMaker or QuarkXPress were built around print layouts. They had to handle the handoff from digital to print: standardized paper sizes, RGB-to-CMYK translation, and so on. Later, tools like Fireworks and Flash were built for digital as the end medium. But even then they had to handle new handoffs — local files to web formats, or design to software environments.

Eventually Sketch became the standard for creating low- and high-fidelity mockups of software. Engineers would use these as guides for building in code. Then Figma dethroned Sketch, moving the practice to the cloud, enabling collaboration, commenting, and more integrated handoffs with engineering.

Both Sketch and Figma are vector tools with a bias: they represent software as static. Figma added light prototyping features, state linking, and basic motion, but the core orientation is around static frames. A designer is largely encouraged to make a frame, that frame is filled with rectangles and copy. Great attention is paid to the visual style of the elements in the frame and their relationship with one another in a layout. This is essentially graphic design with an emphasis on function over form.

As Figma evolved toward production: they specialized refinement of components, design systems, and developer handoffs. As this specialization has grown, it has become even harder to use Figma to think fluidly about experiences and flows.

You may have the luxury of designing a tight and narrowly defined product where all the frames fit easily in a single Figma file. But if you work on larger software products you simply can’t work in a single file have every screen, every state. This means the larger the software system, the less of it a designer sees.

Most designers are responsible then for working on a single feature or area of the product. Often thie leads to silo thinking, and picking the “first screen” of a feature as their starting point, ignoring the step right before it. The truth of the comple user journey is ignored due to either organizational or technical or Figma’s inability to really hold the the whole system. This creates deep disconnects between features and what precedes them. Figma encourages this lazy habit: files are isolated by default, there’s no overreaching network of files as nodes across a product. Large files bloat and slow down, pushing designers to narrow their focus even more.

Within features, the core unit is a frame — a rectangle. That rectangle has become the defining characteristic of Figma thinking. Designers are effectively laying out components on a canvas, working more like layout artists than experience designers.

There is no notion of timeline in Figma. Flash had one, and its very existence invited designers to think about what came before and after, to explore transitions. Figma doesn’t forbid this, but it doesn’t support it. Its energy has gone into components, systems, and handoff — all solid investments, but ones that bias design toward static production.

One of the casualties of this specialization has been the ability to design in both time and space — to explore experiences as flows across systems. Imagine being able to link any part of an app, simulate user activity at any point, and experience cross-system interactions. Imagine a tool that auto-produces states for every screen and element. Imagine a tool hooked up to simulated or real system data, so prototypes always run on live content — surfacing data quality issues and missing information as part of the design.

Before AI, perhaps Figma’s trade-offs were tolerable. In a deterministic world, static screens made sense. Steps between states felt procedural and predictable. Components mirrored engineering constraints.

Software is much more alive. Outcomes are nondeterministic. As users move through larger AI flows, each screen or context change can deliver a one-off, unique experience. Designing with a deep understanding of nondeterministic outcomes is not optional. It is the work.

Figma’s frame-by-frame rails constrain designers. They chunk the work, limit imagination, and reduce dynamic experiences to static boxes. Designers trained this way often struggle with emerging “vibecoding” tools. Vibecoding invites thinking in time, sequence, and narrative, rather than in rectangles. But many designers misuse it, trying to force it into a deterministic mold — fussing over layout and color like graphic designers, instead of working with flows.

Vibecoding tools themselves aren’t yet ready. They don’t embed or enforce design system coherence. They produce throwaway code, useful only to show that something is technically possible. They don’t yet carry the burden of scale or handoff.

Still, they hint at what’s next.

Soon we’ll see tools that match the design opportunity of an AI-first lens:

• Tools that embed system components, elements, and styles, enabling effortless inheritance downstream.

• Tools that support fork-and-commit workflows, so new work is immediately ingested into the system and available to others.

• Tools that synthesize or directly use live system data, APIs, and LLM endpoints — producing prototypes that are more real than demonstrations.

• Tools that encourage interrogation of user actions and mental models, with as much precision as today’s pixel-perfect layout tools.

• Tools that encourage flows and narratives, beginning from user intent and working backward into features and functionality.

These tools will have drawbacks, as all do. But I welcome the day we can embrace a paradigm that releases us from Figma thinking.