A woman in Pune opens her grocery app on a Saturday morning to reorder the same atta, milk and bread she orders every week, and the reorder button is not where it was last time. The app has decided she might like a new layout. She finds the button eventually, but the small habit she had built is gone. When a product team says it wants generative AI in the interface, this is one of the two things it can mean, and it carries most of the risk.
Two projects with the same name
The first idea is letting a model draw the screens: wireframes, layouts and copy that a designer then reworks. That speeds up design work, and the customer never sees the model.
The second is letting a model change the screens for each user while they use the product. That changes how the product behaves in front of customers, every day, in ways nobody on the team reviewed. We keep the two conversations separate from the first meeting, because the budget, the testing and the risk are completely different. If you are scoping either one, our AI solutions page lists the kinds of work involved.
Generated wireframes are a faster first draft
A designer can ask a tool for "a dashboard for a regional sales manager with targets, dealer-wise collections and quick actions" and have a layout to react to in a minute. That saves blank-page time, and the sales head has something to point at in the first meeting instead of the third.
The draft is plausible, which is different from right for your users. It puts the chart on top, when what the manager checks first every morning, standing in a dealer's shop with the phone in one hand, is which dealers have not paid. The components do not come from your design system. Review it the way you would review a sketch from a new colleague in their first week: useful to react to, not something you ship.
- 01Promptrole, task, data shown
- 02Draft screens
- 03Designer reworkorder, system components
- 04Five-user teston their phones
The draft is the start of the design process, and real users see it only after rework.
Adaptive screens start with rules
The usual pitch is that a repeat shopper sees checkout shortcuts and a first-time visitor sees a guided path through the catalogue. Most of that needs no model. A returning-customer flag, a saved address, a preferred UPI app and a handful of if-then rules decide what to show. The behaviour is predictable, your QA team can write a test case for it, and the support agent on the phone can describe the screen the customer is looking at.
A model earns a place when the choice depends on something rules cannot express, such as what the customer typed into search in their own words. Even then, limit what it can do. Let it choose between layouts you designed and reviewed. Do not let it invent a new one at two in the morning for a customer in Kochi.
- Model suggestionoptional, picks a variant
- Ruleswho sees what, tested
- Designed variantsreviewed, accessible
- Default screenwhat everyone falls back to
The model sits at the top and can only pick from what the layers below allow.
Words on the screen need an owner
Models can propose button labels in a given tone, draft the Hindi and Tamil versions of a screen, and fill in placeholder text. When you have sixty screens to fill before a festive-season launch, that help is welcome.
The trouble is consistency. A button that says "Proceed" on one screen and "Continue" on the next, for the same action, makes people pause, because a user scanning a screen matches words, not meanings. And a translation that reads fluently can still be wrong in a legal or medical sense; only a native speaker who knows the domain will catch it. Keep a glossary of approved terms for each language, and give one person the job of approving text before it goes out.
Conversational screens follow the same rule. A model can draft the WhatsApp flow a logistics firm uses for rescheduling a delivery. The designer still decides what the assistant can do, what it refuses, and how a frustrated customer reaches a person, which is the subject of our post on handing off from an agent to a person.
Accessibility suggestions are a starting point
A tool can flag low colour contrast, propose alternative text for images, or suggest how a flow might work by voice. These are useful prompts for the designer and worth running on every build.
They are not testing. Generated alternative text describes what is visible, which is not always what matters. "A man holding a document" does not tell a screen reader user that the image is the warranty card they need to photograph. Automated checks cover only part of the accessibility requirements. The rest needs someone using the screen with a keyboard, someone using it with a screen reader, and ideally people who use assistive technology every day.
Where adaptive interfaces lose people
The biggest one is personalising with no fallback. When the guess is wrong, the customer is left on a screen that makes no sense for them, with no way back to the normal one. Close behind is a layout that changes between visits. On the second visit, people expect things where they left them; if the screen keeps moving, nobody builds a habit, and the support agent cannot say "tap the button at the bottom right" because it is not there for everyone.
Generated copy goes live without being checked against the product's own terms. An accessibility scan gets treated as full coverage. And success gets measured only in clicks, so a change that annoys users goes unnoticed because they tapped around more trying to find things.
Build the default screen first
Before any model work, settle these:
- Every generated layout is labelled a draft until a designer has reworked it.
- Every personalisation is written as a rule first, and you can say what a model would add.
- A default interface exists that any user can return to.
- A glossary and a named approver cover all generated text.
- Accessibility is tested with tools and with people.
Start with the default screen. Once it exists and has been tested with five real users, you know exactly what the model is allowed to change and what stays put. If the question is also who on the team does this work, our post on what generative AI can and cannot do for a design team covers it.
