Product Design in 2026

Product Design in 2026 | Sam Solomon Product Design in 2026 March 11, 2026 Writing Lately, I’ve been getting the same question over and over. Where do I think product design headed? Everyone working in software is looking at what AI can do and asking, what’s next? It’s both an exciting and unsettling time. So I wanted to write about how I’m thinking about this right now—not as a prediction, but as a practical way to approach the next six to twelve months. A useful place to start is with a simple question: what is the value of product design in a software company? There are many answers, but from a business perspective the most important one is speed . Figma is a useful abstraction from code. It’s far faster to create a screen, storyboard or Figma prototype—than to change the code itself. And for the last decade that abstraction has allowed the best software companies to iterate faster. They allow teams to visualize what they’re building before writing code. That makes it easier to gather feedback, align on what’s actually being built, and explore different approaches before committing to one. Those tight feedback loops are where most of the value comes from. Problems and shortcomings are cheaper and easier to address when they appear in a Figma file instead of production software. AI today I want to talk about the frontier of product design today—how I’m using AI and what my workflow looks like. Once I started posting AI experiments , people began asking how I was incorporating AI into my design process. For a long time the honest answer was—I wasn’t. This stuff was just a novelty. That’s no longer true. Over the last couple of months I’ve been working on a handful of small personal projects. When I open Figma, it is mostly for collecting ideas and organizing my thoughts. FigJam is a dumping ground for screenshots and ideas. And that’s basically it. The typical starting point for a project is with an LLM—ChatGPT, Claude or Gemini. I’ll ask the model to help me reason through the idea. What might the ideal flow look like? What concepts am I missing? Once the answers start to take shape, the conversation shifts to implementation. I’ll push on the technical details: what are the tradeoffs between different approaches? What constraints might matter later? The end goal here is to create a plan to hand off to a coding agent to help it scaffold the project. In many ways this step isn’t that different from writing a product requirements document. Once in a good place, I’ll drop the plan in with a few images and a short prompt into the coding agent to generate a final plan before starting. Once the agent reaches a point where there is something to review I ask it to start a local server. Then it becomes iterative. If it’s a greenfield project, you can often just keep iterating with the agent until the feature is done. For web applications I’ve found the Relay Inspect MCP to be incredibly useful. I use it in every project. It lets the agent see the DOM, inspect console logs, take screenshots, and interact with the dev server. It prevents the back-and-fourth copying and pasting console and server logs and allows the agent to check it’s own work. Some will say—well you knew how to code anyways. And that’s true. But I don’t think that’s a limiting factor here though. First, I am a pretty poor engineer. That’s why I don’t write production code anymore. I don’t know Go, but most of the applications I’ve built use that as the primary language. I am way out of my element when it comes to building Mac Apps. But I’ve been able to build functional applications using Swift and SwiftUI. I think the primary advantage having an engineering background provides is knowing what questions to ask. But what about product teams working on mature products? What might this look like in a company environment? Wireframes and prototypes Ok, well how does any of this apply to delivery teams? What I see is that we’re going to be moving from Figma artifacts directly into code. The big distinction is that the abstraction Figma previously provided is no longer as useful. It has become far easier to manipulate the underlying code directly. In the future I think product teams will start to look at Figma as bloat in the delivery process. If a designer builds a functional prototype what use does it provide to translate that back into a Figma file? It becomes busywork that is done for the sake of process. Vibe coded prototypes aren’t going to be enough on their own though. There are still a few missing pieces to make this effective for delivery teams: A shareable URL (with internal/public controls) Comments or a way to collect feedback Code that engineers can use as a starting point Imagine this scenario—a designer starts with a rough PRD, some screenshots and a prompt. From those things a designer can start iterating on a feature and build an interactive version of it. It probably doesn’t necessarily look like the product at this point, but it gives a good sense of the feature. This is the equivalent of wireframing in 2026. These prototypes can be as detailed or interactive as the designer wants. It’s a place for designers to explore and iterate without the constraints of the application environment. When the designer is confident in the feature they will be able to give the agent instructions on how to implement this in the product UI. Here the agent looks at the existing project, the fontend application and design system. Then it will recreate this functionality within the product UI according to the designer’s instructions. The agent implements, creates a local server and seeds it with mock data. The designer tells the agent to deploy it and in 10 seconds a shareable link is created. This is high fidelity prototyping in 2026. Welcome to the future of product design! I expect most companies will find a way quickly deploy these tiny HTML, CSS and JS through internal solutions or using something like Cloudflare or Vercel. This allows for sharing these ideas with PMs or others on the team as well as getting feedback from customers. Design engineerS In January I wrote a hypothesis that product designers, product managers and engineers will start to merge into a new role . If that trend continues, it begins to blur the line between design artifacts and working software. When you can go from idea to working software in a single environment, the separation between design and engineering starts to break down. Historically, designers created representations and engineers built the product. But if software becomes dramatically easier to create, designers may start working much closer to the implementation. Not necessarily building full production systems—but creating small working pieces of the experience. When an interface actually runs, it becomes much easier to understand all the interaction details, state changes, and edge cases. And this is where the idea of the design engineer starts to make more sense. When creating software becomes fast and cheap, needs shift. The most valuable people on product teams will be the ones who can move fluidly between the problem and the implementation. They’ll be comfortable reasoning about product decisions, shaping interaction flows, and working directly with code—even if that code is largely written by agents. Closing thoughts I feel compelled to say—the core value of product design hasn’t actually changed. The job is still to figure out how to build the right thing fastest. It’s the tools that are changing. For a decade a Figma files have been the primary artifact of product design work. Now we’re entering a world where software might be the fastest way to explore those ideas. If that’s true, then the future of product design probably looks less like drawing rectangles—and more like tiny pieces of code. Comment Cancel reply Discover more from Sam Solomon Subscribe now to keep reading and get access to the full archive. Type your email… Subscribe Continue reading