Part 6 of the “UX × AI” series.

In Part 1, we reframed the relationship—AI as the intern and you as the designer. In Part 2, we recognized the skill—prompting is brief writing. In Part 3, we protected what cannot be delegated—genuine empathy with real human beings. In Part 4, we got practical—a 30-day guide to building workflow fluency. In Part 5, we dismantled a myth—more data is not more insight, and scale is not a substitute for understanding.

This article is about something that happens slowly and mostly invisibly and that the design community has not yet named clearly enough to defend against.

It is about what happens when designers stop designing with AI and start designing for it.

The distinction sounds subtle. It is not. It is the difference between a practitioner who uses a tool to extend their creative agency and a practitioner who has allowed a tool to narrow it—who has, without deciding to, handed the authorship of their design decisions to a system whose aesthetic preferences, cultural assumptions, and optimization criteria are not their own.

This is happening now. Across product teams, across design agencies, across the student cohorts of design institutions. And it is happening not through dramatic acts of delegation but through a hundred small moments of acceptance—of choosing the first AI-generated option because it is good enough, of prompting toward outputs that confirm existing assumptions rather than challenging them, of letting the tool's aesthetic bias become the product's aesthetic voice.

Understanding this shift—and learning to resist it deliberately—is one of the most important design competences of this moment. This article is about developing it.

Every tool has a bias, AI more than most

Let me start with a principle that is older than AI.

Every tool shapes what its user makes. The hammer biases toward driving nails. The photograph biases toward moments that can be captured in a fraction of a second. The spreadsheet biases toward problems that can be expressed as rows and columns. This is not a failure of the tool—it is a property of all tools. The tool has a grain. Working with the grain is fast. Working against it requires intention and effort. And working without knowing the grain exists is how the tool ends up using the designer rather than the designer using the tool.

AI design tools have a grain of truth. And it is a significantly more consequential grain than most design tools that have come before, for three reasons.

The first is scale. AI design tools are trained on datasets of unprecedented size—millions of design outputs, user interfaces, visual systems, and interaction patterns. The aesthetic conventions that dominate those datasets become the tool's default output. The conventions that are underrepresented—non-Western design traditions, accessibility-first aesthetics, and vernacular visual languages from outside the mainstream of digital design—are produced only when the designer explicitly prompts for them, and often imperfectly even then.

The second is authority. AI output arrives with a visual confidence that earlier generative tools did not have. When a designer receives an AI-generated wireframe or visual direction, it looks finished in a way that a rough sketch does not. The apparent finish suppresses the critical evaluation that rough work invites. The designer who would immediately question a sketch—who would say "this doesn't feel right for our user" or "this doesn't reflect how people in this context actually live"—is less likely to apply that same criticism to an output that looks polished.

The third is speed. AI generates options so quickly that the designer who is working under time pressure—which is most designers, most of the time—faces a structural incentive to accept the first adequate output rather than investing the additional time to push the tool toward the genuinely right one. Speed is valuable. But speed applied to the wrong aesthetic direction produces wrong outcomes faster.

"45% of design leaders fear a homogenization of digital interfaces linked to the widespread use of generative tools, while 38% are concerned about a gradual erosion of fundamental skills in design and usability. The danger lies not in automation itself but in the implicit delegation of strategic decisions to systems whose optimization criteria are not always explicit."— Harvard Business Review (2025)

The homogenisation problem: What it actually looks like

There is a phenomenon that researchers have begun to name and study—design homogenisation—and it is becoming one of the most documented side effects of AI-assisted design at scale.

Design homogenization is what happens when a significant proportion of digital products begin to look, feel, and behave in ways that are increasingly similar—not because their designers made similar choices, but because their designers used similar tools that made similar default choices on their behalf. The interfaces are clean. The typography is legible. The color systems are accessible. And they are indistinguishable from each other because they were all generated from the same training data by designers who accepted the tool's aesthetic judgment without sufficiently interrogating it.

Research on design fixation in generative AI has shown that designers exposed to AI outputs tend to perpetuate the same visual and conceptual patterns, creating a vicious cycle of creative homogenization. This is not a marginal finding. It is a documented cognitive effect—the AI output, by being the first thing the designer sees, anchors their subsequent design thinking in ways that are difficult to escape without deliberate effort.

AI design systems are primarily trained on English-centric datasets and often align with Western aesthetic conventions. While these biases are well-documented in text and image generation, they manifest with equal consequence in interactive creative domains like web development. The result, as one researcher described it, is that AI tools risk normalizing everything toward a dominant, Western-centric aesthetic—marginalising other styles and constraining the ability of users from non-Western contexts to see themselves reflected in the interfaces designed for them.

For Indian designers—working for Indian users in the specific cultural, linguistic, and visual contexts of one of the world's most diverse design landscapes—this is not an abstract concern. When an AI tool is asked to generate a design for a rural financial services app, its default output will reflect the aesthetic conventions of the Western fintech products that dominate its training data. Clean sans-serif typography. Minimalist layout. Color palettes drawn from the global tech aesthetic. An interface that looks like nothing the user in Jalgaon or Guwahati or Tirunelveli has ever encountered in their lived visual world—and that communicates, through its aesthetic choices alone, that it was not made for them.

The designer who accepts that output because it looks good has not made a design decision. They have accepted the tool's design decision. And the tool does not know who the user is.

The vibe coding warning: Speed without validation

Vibe coding—using AI to quickly generate functional prototypes from prompts or screenshots—exploded in 2025. But designers are recognizing its limitations when used without proper validation. The most detailed concern captured the core issue: the trend of shipping AI-generated UIs without proper user validation. Many stakeholders pushed to adopt AI rapidly, prioritizing output over user insight or design expertise. This created additional design overhead with limited ROI.

The phrase "vibe coding" is instructive—and not in a flattering way. It describes a design practice that is driven by the immediate aesthetic appeal of AI-generated output rather than by the rigorous understanding of user needs that good design requires. The vibe is attractive. The validation is absent. And the gap between what looks good in a prompt output and what works for a real user in a real context is precisely where design value lives—and precisely where vibe coding abandons the discipline.

I wrote about this pattern in my earlier work on the fast food trap in design. AI-generated interfaces are the fast-food version of design—produced quickly, visually appealing, and nutritionally empty of the genuine user understanding that makes design worth having. The product that was vibe-coded into existence in two weeks will look impressive in a stakeholder presentation. It will fail in the field, with the real user, in the ways that fast food always fails—adequately satisfying in the moment, genuinely insufficient over time.

Designers must develop their prompting skills to avoid cookie-cutter outputs. One design practitioner put it directly: "If you're terrible at prompting, it's going to be generic. It's an art and a skill." Speed will stop being impressive.

Speed has already stopped being impressive for the practitioners who are paying attention. What impresses now is specificity—the design that is unmistakably right for this user, this context, this cultural situation. And specificity is not something AI produces by default. It is something the designer produces by knowing their user deeply enough to push the tool past its defaults.

The cultural bias beneath the surface

There is a layer to the AI aesthetic bias problem that goes deeper than visual homogenization, and that is particularly consequential for designers working in contexts that are underrepresented in AI training data.

The training data for leading generative design and image models disproportionately favors Western and English-speaking perspectives. These datasets are likely skewed toward well-documented Western design and artistic traditions over non-Western traditions. As a result, underspecified prompts lead to a narrow set of default conventions that, although often treated as neutral or realistic, are rooted in specific cultural perspectives.

AI models tend to encode and amplify dominant aesthetic standards, frequently biasing generated outputs toward Western conventions and excluding non-normative representations. This phenomenon arises from training data reflecting the tastes of specific demographics, thereby reinforcing limited cultural capital and resulting in the homogenization of aesthetic output.

For a designer working on a product for a farming community in Vidarbha, a healthcare platform for elderly users in Tamil Nadu, or a government services interface for tribal communities in Jharkhand, the AI tool's default aesthetic is not merely aesthetically wrong. It is culturally wrong. It carries implicit assumptions about visual literacy, about color semantics, and about the spatial conventions of information architecture that reflect the design culture of Silicon Valley and not the lived reality of the users the product is supposed to serve.

AI models trained on historical design data can perpetuate old assumptions—layouts that favor certain demographics and color combinations tied to specific cultural contexts. The output looks clean and modern. The underlying assumptions may not be inclusive by any real standard.

This is the specific form of the authorship problem that Indian designers need to be most alert to. The AI tool will generate something that looks contemporary and professional. It will not know that the color red signals auspiciousness in one regional context and danger in another. It will not know that the visual density conventions of successful regional language newspapers have shaped the reading expectations of a significant portion of its target users. It will not know the specific trust signals that make a financial product feel legitimate to a first-generation digital banking user in a Tier 3 city.

The designer knows these things. Or should. And the design practice that uses AI without this knowledge—that accepts the tool's default cultural assumptions without interrogating them—is a practice that is designing for the AI's world rather than the user's.

The authorship question: Who is actually designing?

Let me ask the question directly, because it is the question that organizes everything else in this article.

When a designer accepts the first AI-generated wireframe without significant modification, who designed that wireframe?

When a design team uses AI to generate a full visual direction and then implements it without a process of critical evaluation against the specific needs of their specific users, whose aesthetic judgment is the product expressing?

When a product ships with an interface that is the aggregated output of multiple AI-assisted design decisions, each individually reasonable, each accepted because it was good enough—whose design is it?

These questions are not rhetorical. They have practical answers, and those answers have professional consequences. The designer who cannot articulate why they made the specific visual and interaction choices in their product—who cannot explain the decisions in terms of user needs, cultural context, and design intent—has not designed the product. They have curated AI output. And curation, while a legitimate skill, is not the same as authorship. And authorship is what clients pay for, what users deserve, and what the design profession is built on.

93% of designers are now using generative AI tools, and 73% believe that AI as a collaborator will have the biggest impact on the field. But 54% of designers say their clients or stakeholders want to jump on AI trends without clear use cases. The pressure to use AI is real. The pressure to use it without clear intent—to adopt it because others are adopting it, to accept its outputs because they are fast and adequate—is equally real. And the designer who navigates that pressure without a clear framework for when to accept AI output and when to push beyond it is a designer who is drifting toward curation and away from authorship without making the choice deliberately.

What staying the author actually requires

Authorship in AI-assisted design is not about using AI less. It is about maintaining the design intelligence that makes AI output genuinely useful rather than merely adequate.

  • It requires knowing your user before you open the tool. The designer who begins an AI-assisted design process with a clear, specific, qualitatively grounded understanding of their user—their visual context, their cognitive expectations, their cultural frame, and their specific situation—is the designer who can evaluate AI output critically. They know what right looks like for this user. They can tell immediately when the AI's default output does not match that understanding. And they can use that gap as a prompt for pushing the tool further—toward the specific, the contextual, the right.

The designer who begins with the AI output and then tries to understand the user through it is working in the wrong order. The tool's aesthetic assumptions have already anchored the process before the user's reality has had a chance to shape it.

  • It requires treating AI output as a starting point, not a solution. The wireframe the AI generates in thirty seconds is a hypothesis about what a solution might look like, not a solution. The designer's role is to evaluate that hypothesis against the specific design criteria that only their user understanding can generate—and to revise, reject, or push further based on that evaluation. The designer who evaluates AI output the way a researcher evaluates a hypothesis—with deliberate skepticism, specific criteria, and the willingness to discard what does not pass—is the designer who maintains authorship. The designer who evaluates it the way a shopper evaluates a product—does it look good? Is it good enough?—has ceded authorship to the tool.
  • It requires making the invisible decision visible. Every AI-assisted design includes a moment of acceptance—the moment the designer says, "Yes, this is the direction." That moment should be a deliberate, articulable decision: "I am accepting this because it serves the user's need for X, and I am modifying it in these specific ways to address Y." Not "I am accepting this because it looks good and I have other things to do." The difference between those two moments of acceptance is the difference between a practitioner who is using AI to extend their design intelligence and one who is using it to avoid exercising it.
  • It requires prompting with cultural specificity. The AI tool's defaults reflect the cultures represented in its training data. The designer who wants output that reflects a different cultural context—the specific visual language of Indian design, the specific trust conventions of a particular regional user group, or the specific aesthetic expectations of a low-literacy interface—must provide that specificity in the prompt. Not "design a healthcare app" but "design a healthcare app for rural women in their 40s in Maharashtra, where the primary trust signal is recognition by the local ASHA worker and where the visual conventions of successful Hindi-language print media have shaped the reading expectations of the audience." The more specifically you encode the user's cultural context in the prompt, the less the tool's default cultural assumptions will shape the output.

"The future of UI and UX will depend on organizations' ability to strike a balance between artificial intelligence and human expertise. The most successful experiences will not be those entirely generated by AI, but those in which machines enhance designers' ability to explore ideas, test hypotheses, and objectively evaluate their choices."— AIvancity (2026)

The design fixation trap, and how to escape it

The research on design fixation in AI-assisted practice identifies a specific cognitive pattern that every designer using AI tools should be aware of: the first AI output anchors subsequent design thinking in ways that are difficult to escape without deliberate effort.

In traditional design practice, fixation—the tendency to persist with an initial design direction even when better alternatives exist—has long been recognized as a risk. Design education and practice have developed a range of techniques to combat it: brainstorming with constraints, design critiques that specifically seek alternatives, and the deliberate practice of killing the first idea before developing the second.

AI does not eliminate fixation. It accelerates it. The AI output arrives so quickly and looks so polished that the designer's critical evaluation—which in a traditional design process has time to develop before a first concept is visible—is confronted with a completed-looking output before it has fully engaged. The result is that the designer's judgment is applied to the refinement of the AI's direction rather than to the generation of genuinely alternative directions.

Escaping this trap requires a specific practice discipline. Before you evaluate the AI's output, write down your own design intent—your specific hypothesis about what this design should achieve for this user. Then evaluate the AI's output against that intent, not against its own internal logic. The AI output that looks good may not serve the intent. The AI output that looks less finished may be closer to what the intent demands. The only way to know is to have stated the intent before the output was visible.

This practice—intent before output—is the single most effective habit I have found for maintaining authorship in AI-assisted design work. It is also the habit that most directly reflects the discipline of the LucyUX framework: you cannot conceptualize effectively without having listened and understood first.

Applying LucyUX: Design intelligence before design tools

The LucyUX framework—Listen, Understand, Conceptualize, Yield—is not a process that AI can shortcut. It is a process that AI can support, but only in the stages where AI is genuinely useful. And the stages where AI is most tempting to use—conceptualizing the generation of design directions—are the stages that are most dependent on the quality of the work that preceded them.

  • Listen: The listening stage is entirely human. It is the field research, the user interviews, and the contextual observation that build the specific, culturally grounded, user-situated understanding that makes subsequent design decisions right rather than merely adequate. No AI tool can do this stage. And skipping it—moving directly to AI-assisted conceptualization without the listening that should precede it—is the primary source of the authorship problems this article describes. You cannot design with AI for your user if you have not first listened to your user without AI.
  • Understand: The understanding stage is where the designer synthesizes what they have learned into a specific, articulable model of the user's needs, context, and expectations. This understanding is the designer's most valuable asset in the AI-assisted design process—it is what allows them to evaluate AI output critically, to identify what the tool has gotten right and what it has missed, and to push the tool toward the specific rather than the generic. AI can support this stage—by helping to map and organize research data—but the synthesis, the interpretation, and the model-building are human work.
  • Conceptualize: This is where AI is most genuinely valuable. With a clear, specific understanding of the user already in place, the designer can use AI to generate a broad field of design directions quickly—exploring more of the solution space than would be possible through manual sketching in the same time. The critical discipline is to evaluate those directions against the user's understanding that preceded them, not against the AI's aesthetic logic. The designer who is generating options with AI while holding the user's reality in mind is designing with AI. The designer who is generating options with AI and evaluating them on the AI's terms is designing for it.
  • Yield: The yield stage measures impact on real users, not the aesthetic quality of AI-generated outputs. Did the design change improve the experience of the specific users whose research informed it? Did it serve the cultural context it was designed for? Did it pass the test of actual use—not the test of looking good in a Figma frame? These are the yields that authorship produces. Curation produces outputs that look good. Authorship produces outcomes that work.

Your action this week

Take your most recent AI-assisted design output—a wireframe, a visual direction, a set of microcopy, or anything produced with significant AI involvement. Ask three questions about it.

  • First: Can you articulate, specifically and in terms of your user's needs and context, why the specific choices in this output are right for this design problem? Not why they look good in general. Why are they right for this user, this context, and this situation?
  • Second: Which elements of this output reflect the AI tool's default aesthetic conventions rather than deliberate design decisions you made? Be specific. Where did you accept the tool's judgment rather than exercise your own?
  • Third: What would you change if you were to design this output from scratch, with full knowledge of your user, without an AI output to anchor your thinking? What would be different? And what does that difference reveal about where the tool's grain and your user's reality diverged?

These questions will not tell you that the AI output is wrong. They will tell you where it is right for the right reasons and where it is right for the tool's reasons—which is a different thing. And knowing that difference is the beginning of the authorship practice that AI-assisted design requires.

My perspective: What I actually believe

The design community faces a specific and important choice in its adoption of AI tools. It can use AI to extend its creative agency—to explore more of the solution space, to generate more options, and to move faster through the execution stages of design while preserving the intelligence that makes those stages worth executing. Or it can use AI to replace creative agency—to generate outputs that are accepted because they are adequate, to shortcut the user understanding that makes design decisions right rather than merely defensible.

The first path produces designers who are more effective because of AI. The second produces designers who are more dependent on AI—who have, through a series of individually reasonable acceptances, allowed the tool to narrow rather than extend their practice.

AI lifts the heavy tasks while humans guide the decisions that actually help real users. AI accessibility tools keep getting better and automate a big portion of what designers struggled with before. But human judgment is still needed to avoid shallow compliance.

I believe in AI's capacity to extend design practice. I have said it throughout this series, and I mean it. But extension requires a self that is doing the extending—a designer with genuine user understanding, specific cultural knowledge, and the critical judgment to know when AI output serves the user's reality and when it merely reflects the tool's defaults.

Preserve that self. It is the thing AI cannot generate, cannot replace, and cannot improve. It is the thing that makes everything AI produces in your practice worth having.

Design with AI. Not for it.

Up next in the "UX × AI" series: “How to Evaluate an AI Tool Before It Evaluates Your Career.“ The AI tools landscape is expanding faster than any design team can responsibly track. New tools arrive weekly, each promising to transform some part of the design workflow. Vendors make claims that are difficult to evaluate without deep technical knowledge. And the organizational pressure to adopt something—to be seen as keeping up—creates urgency that works against the careful evaluation that good tool selection requires. In Article 7, we build the no-hype checklist: what to look for, what to ignore, and the questions that vendors will not answer unless you push.

References & further reading