# Do you still need a designer if AI generates the UI? | Other Land URL: https://otherland.studio/blog/do-you-still-need-a-designer-if-ai-generates-the-ui > Generating a screen is cheap. Keeping the hundredth screen coherent with the first ninety-nine is not. What a design team delivers in an AI-first product team. Know a team that needs this? Send it their way ## Do you still need a product designer if AI can generate the UI? Generating a screen is close to free. Keeping a hundred screens coherent is not. Veronika Bogush, Operational Director October 23, 2026 · 7 min read ### Key takeaways - Generating one screen is close to free. Keeping the hundredth screen consistent with the first ninety-nine is what a design team is paid for. - If nobody on the team has design expertise, you can tell generated work runs, but not that it is accumulating debt. - On an agent-built product we work on, the designer's first month went into rebuilding AI-generated components into a real system. - Without a designer, polish stops, every new feature looks worse, and the engineer and head of product absorb the work. Yes, but not for the reason most agencies will give you, and not for the part of the job you are picturing. Generating a screen is close to free now. Generating the hundredth screen so that it still agrees with the previous ninety-nine is not. That second thing is what you are paying a design team for, and it got harder in the last two years, not easier. Here is the useful way to think about it. Every generated component is locally plausible. It renders, it works, a stakeholder looks at it and says fine. The cost does not show up in that screen. It shows up three months later, spread across forty screens, as a product that no single person can navigate confidently and no one on the team can explain why. ### What generation made cheap, and what it did not Got cheap Did not get cheap Producing one screen Making screen 100 agree with screens 1 to 99 Standard components (buttons, forms, tables) The five percent of interactions no library covers Iterating on a visual direction Deciding which direction the product should take Building what was specified Noticing that the specification produces the wrong product Shipping Knowing whether what shipped is good The last row is the one that hurts. If nobody on your team has design expertise, you cannot evaluate the output. You can tell that it works. You cannot tell that it is accumulating debt. So the generation runs, the product grows, and the drift is invisible until a real user is confused and you have no idea which of the last two hundred decisions caused it. ### A live example We work with an AI-native real estate operating system being built for the Dubai market. It is a good test case because the engineering constraint that used to protect products from bad design decisions is completely gone there. Their setup: - The specification is written by a business analyst, validated through a twelve-phase pipeline with human gates, then handed to an agent fleet that builds it. - Their engineer does not write code by hand. A feature can deploy overnight. - There are over a hundred and twenty epics scoped for a first release aimed at roughly six months out, and five distinct user roles sharing one underlying object. In a team like that, development stops being the bottleneck. Their head of product said it plainly on our first call: the constraint moved to analysis and design. That is not a complaint about designers being slow. It is arithmetic. When building is instant, the only expensive thing left is deciding what to build. Our designer joined about a month in. What he inherited was a set of AI-generated components: functional, minimal, and with no naming conventions or consistency underneath them. Someone had needed something to exist, and it existed. Rebuilding that into an actual system was most of his first month. ### The screen that looked right and was wrong Before the designer joined, the business analyst had put together a working prototype to sanity-check what he had written. Sidebar, tables, sections, the familiar SaaS shape. For his purpose it was correct. It let him see whether the spec held together. As a product direction it was wrong, and not in a way that shows up in review. Nothing was broken. It just quietly assumed that the product would be another dashboard, because that is the shape the model reaches for when you ask for a real estate management interface. The product it needs to be works differently. The chat is the primary surface. A broker asks for something, and the interface assembles itself around the request: the right chart type for that question, the relevant documents, the current state of the deal in a panel beside the conversation. You do not navigate to a page for each object. You stay in one place and the surface adapts. That decision cannot come out of a prompt, because a prompt is always about a part and this is a judgment about the whole. It also cannot come from a component library. The charts in that interface are custom, built to respond to specific kinds of questions a broker asks. Libraries cover the common cases well. The cases that make your product yours are exactly the ones they do not cover, and generating them anyway is how you end up with forty near-duplicate components that each exist for one screen. ### Where we tried to remove the human and put them back Worth telling because it is the boundary, and we found it by crossing it. At one point review itself got automated on both sides. The client ran an agent that commented on the designs against the requirements. Our designer ran an automated pass that resolved the comments. Both worked, technically. The output was strange, the comments were strange, and after an iteration or two everyone agreed it was not producing judgment, just motion. Review went back to being a human reading the work. Not because automation failed at the task, but because the task was never the comments. It was someone deciding what matters. ### The part clients do not see, and why we made it visible Most of what a designer does in this kind of team is invisible to everyone else. Polishing a component so it stops looking generated does not appear in any ticket. It has no obvious output. It is the difference between a date picker that functions and a date picker you would put in front of a paying broker, and to anyone who is not a designer those two things look identical. On that project we hit this directly. Work was happening, real hours were going into it, and it was not represented anywhere in the system, which made it look like nothing was happening. The fix was not an argument. Each component now gets its own ticket, so the polish is a visible unit of work with a state, like everything else. If you are buying design work in an AI-first team, this is worth doing on your side too. The work you cannot see is usually the work you are actually paying for. ### ”The system is set up now. Can we take it from here?” This is the fair version of the question, and it tends to arrive at a specific moment: once the design system is working. The components exist, the patterns are written down, the team can generate against them and get something reasonable back. From the outside it looks like the expensive part is finished and what remains is maintenance. So it is worth answering concretely rather than defensively. We put it to our designer on that project: if he stepped away for a month, three months, six, what actually happens. - Polishing stops immediately, and the experience gets worse right away rather than gradually. - Look and feel degrades noticeably on every new feature, since new features keep arriving at the same speed. - Delivery slows down, because the engineer starts fixing visual and interaction bugs instead of orchestrating the agents that build the product. - The head of product spends more of his time on verification. His own comparison was to removing QA. The work does not disappear. It gets absorbed by people whose job it is not, done less well, at a higher cost, while the thing they were supposed to be doing goes slower. That is the honest commercial answer. You are not paying for screens. You are paying for someone to own coherence. And to own it without becoming the bottleneck, because a design team that slows down an overnight pipeline has given back everything it was hired to add. ### How to check this before you pay Four questions that separate a design partner who fits an agent-based team from one who does not: #### Where does your design system live? If the answer is a Figma library and nothing else, ask how it stays in sync with what actually ships. On that project the system lives in code, and Figma exists so the team can review and comment. #### What happens after handoff? Someone has to look at the built screen on staging and fix what does not match. Ask whether they can do that directly or whether every small correction restarts the whole design cycle. #### Show me something you decided once that keeps applying Error handling rules, states, patterns. Decisions with long tails are the ones that pay for themselves. Redrawing screens is not. #### What will you refuse to generate? A designer who generates everything is not adding judgment, and a designer who generates nothing is going to be your bottleneck. You want the specific answer about where the line sits and why. If you are building this way and trying to work out what design should look like inside it, we are happy to talk about what has and has not worked for us. ### Other Land's design services Product DesignProduct design agency for SaaS and AI productsDesign EngineeringDesign engineering agency for teams that ship in codeGrowth DesignGrowth design agency for increasing conversion, activation and retentionDesign SystemsDesign systems for SaaS, AI products and mobile appsUX AuditUX audit services for SaaS and AI productsMVP DesignMVP design and build for early-stage SaaS and mobile startupsWebsite DesignWebsite design and development for product companiesBrand DesignBrand design and brand refresh for product companies Blog ### Other Land articles on AI product design AI product design October 12, 2026 #### Why AI-generated products look generic, and what designers do differently by Artem Ivanov, CEO Engagement models October 22, 2026 #### When does a startup actually need a designer, and which model fits by Veronika Bogush, Operational Director AI product design May 28, 2026 #### How AI Quietly Changed Modern UX Patterns by Other Land team