Part 7 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 you already have. In Part 3, we protected genuine empathy. In Part 4, we built 30 days of deliberate practice. In Part 5, we dismantled the more-data myth. In Part 6, we reclaimed authorship—designing with AI, not for it.

This article is the most practical one I have written in this series.

Because there is a problem that is not being named clearly enough in the design conversation about AI, and it is costing practitioners and teams real time, real money, and real professional credibility.

The problem is this: the AI tools landscape in 2026 is moving so fast, and the organizational pressure to adopt something is so intense, that most design teams are choosing tools the wrong way. They are choosing based on what looks impressive in a demo. Based on what a vendor's marketing describes. Based on what other teams appear to be using. Based on the pressure from a leader who has read about AI in a business publication and wants to see adoption on the next quarterly roadmap.

None of these are evaluation criteria. They are social signals. And design teams that select AI tools based on social signals—rather than based on deliberate, criteria-driven evaluation—end up with tools that do not match their actual workflow, do not serve their specific users, and do not deliver the value that was promised in the meeting where the adoption was approved.

This article gives you the framework to do it differently. A no-hype checklist for evaluating AI tools before you commit—in terms of time, budget, workflow disruption, and professional reputation—to using them.

The pressure to adopt is not an evaluation criterion

Let me name the dynamic that is shaping most AI tool adoption decisions in design teams right now, because it is the context that makes the rest of this article necessary.

The pressure to adopt AI tools is real and coming from multiple directions simultaneously. Leadership is reading about AI productivity gains and asking why the design team is not capturing them. Clients are asking whether AI is part of the agency's workflow. Peers appear to be adopting new tools constantly, and the social media discourse around design is saturated with demonstrations of AI-assisted work that looks effortless and impressive. And the tools themselves arrive with confident marketing that positions adoption as obviously correct and non-adoption as obviously behind.

In this environment, the question, "Should we evaluate this tool carefully before adopting it?" can feel like a question that marks you as someone who does not understand the urgency of the moment. It is not. It is the question that marks you as the professional in the room.

When selecting an AI UX design tool, consider factors like ease of use, integration with existing workflows, collaboration features, platform compatibility, and pricing. Scalability, support for design systems, and AI-driven capabilities are also key. These are the right starting criteria. But they are starting criteria—the first filter, not the complete framework. The designer or design leader who stops here and calls it an evaluation has completed the first step of a much longer process.

The tool that passes the starting criteria filter still needs to be evaluated against the specific requirements of your practice—your users, your workflow, your team's capabilities, your organization's constraints, and the specific outcomes you are trying to achieve. That evaluation takes time. It takes discipline. And it is the investment that separates tool adoption that strengthens practice from tool adoption that disrupts it without delivering value.

"It's easy to get bogged down in long feature lists and complex pricing structures. To help you stay focused as you work through your unique software selection process, focus on the factors that matter to your specific workflow—not the ones that look impressive in a demo."— CPO Club (2026)

The seven questions vendors will not answer unless you push

In 25 years of practice, I have evaluated more tools than I can count—design tools, research tools, collaboration tools, and now AI tools. And across all of those evaluations, I have found that the most useful information about a tool's actual suitability for your practice is rarely volunteered by the vendor. It has to be extracted through specific, direct questions that most buyers do not think to ask and that most vendors have trained their sales process to redirect around.

Here are the seven questions I ask in every AI tool evaluation that I am serious about. They are the questions that separate tools that are genuinely useful from tools that are impressive in demos and inadequate in practice.

Question 1: What does this tool do when it is wrong—and how does it tell me?

Every AI tool is wrong sometimes. The relevant evaluation criterion is not whether the tool is wrong—it is what happens when it is wrong. Does it fail confidently, presenting incorrect output with the same visual authority as correct output? Does it signal uncertainty in ways that allow you to apply appropriate skepticism? Does it hallucinate—generating output that is plausible but factually incorrect—and if so, in what types of situations is hallucination most likely?

Vendors will not volunteer this information. Ask for it directly. Ask for documented examples of failure modes. Ask how the tool signals low confidence in its outputs. Ask what the process is when the tool produces output that is incorrect in consequential ways. The vendor who answers these questions honestly is selling a tool they believe in. The vendor who redirects to demonstrations of successful output is selling the demo, not the tool.

Question 2: What data does this tool use to generate outputs—and who owns what it learns from my data?

AI evaluation requires understanding not just output quality but the sources and processes that generate it. The same prompt can produce different outputs across runs, and outputs can be technically valid while being factually wrong or contextually inappropriate.

Every AI tool learns from the inputs it receives. The question is what it does with what it learns from you. Does it use your research data, your design files, and your user insights to improve a shared model that other customers also benefit from—meaning your proprietary information is contributing to outputs for your competitors? Does it retain your data after the session ends? What are the data residency policies—particularly relevant for Indian design teams working with user data governed by the Digital Personal Data Protection Act 2023?

These are not paranoid questions. They are professional due diligence questions. And the answers have real implications for how a tool can and cannot be used with sensitive user data.

Question 3: How does this tool perform with non-Western, non-English content—and can you show me evidence, not claims?

As we established in Article 6, AI tools carry cultural bias rooted in the demographic composition of their training data. For Indian designers working with Hindi, Marathi, Tamil, Telugu, or other regional language content—or with visual contexts drawn from Indian rather than Western design traditions—this bias is not a theoretical concern. It is a practical limitation that affects the quality of the tool's output for your specific work.

Ask the vendor to demonstrate the tool's performance with content in the languages and cultural contexts you actually work with. Not with English content that looks like your work. With your actual content. The tool that performs well with English UI copy and poorly with Marathi UI copy is not a tool that serves your users—it is a tool that serves the demographic represented in its training data, which is not your demographic.

Question 4: What does the pricing model look like at a realistic scale—not at demo scale?

Pricing structure matters significantly since some tools charge per seat while others bill by generation volume, which can shift costs dramatically as usage scales.

The demo is shown at a scale that makes the tool look affordable. The invoice arrives at the scale of actual usage, which is frequently an order of magnitude larger. Ask for a cost projection based on your actual usage patterns—your team size, your typical project cadence, and your expected generation volume. Ask specifically about the cost of the features you will actually use, not the features that make the demo impressive. Ask what happens to cost when the tool is used at full team capacity rather than by one enthusiastic early adopter.

The AI tool that looks like a reasonable investment in the demo and produces a budget surprise at the quarterly review is not bad. It is a tool that was evaluated on the wrong criteria.

Question 5: How does this tool integrate with my existing workflow—and what breaks when I add it?

Most AI tools for designers work alone, cut off from the rest of your workflow. The tool that exists as an island—that requires a context switch away from your existing tools, that does not connect to your design system, that produces outputs that must be manually reformatted before they can be used in your primary environment—is a tool whose productivity gains are partially consumed by the integration overhead it creates.

Ask specifically about the integration points that matter to your workflow. Does it export to the file formats your team uses? Does it connect to your design system in a way that makes AI-generated output consistent with your established visual language? Does it integrate with the research repositories, project management tools, and collaboration platforms that your team depends on? Integration claims in marketing materials are not integration evidence. Ask for a live demonstration of the specific integrations that matter to your workflow, with your actual tools, using your actual files.

Question 6: What does adoption actually look like—not the onboarding, but the six-month reality?

Every AI tool vendor will show you a compelling onboarding experience. What they will not volunteer is what the adoption curve looks like after the initial enthusiasm—the point at which the team moves from exploring the tool's capabilities to relying on it for production work, the friction that emerges in that transition, and the support resources available when the team encounters problems that the documentation does not address.

Ask for references—not testimonials selected by the vendor's marketing team, but the contact details of a design team that has been using the tool in production for at least six months, whose work profile is similar to yours. Ask that team: What was harder than the vendor said it would be? What did you have to figure out on your own? What would you tell a team considering this tool that the vendor did not tell you?

The answers to those questions are the most useful information available about the tool's real-world performance. They are available. You have to ask for them.

Question 7: What is the vendor's roadmap—and how does it align with where your practice is going?

I also evaluate how often vendors update their underlying AI models, because output quality degrades fast when a platform falls behind the latest foundation models.

The AI tools landscape is moving fast enough that a tool that is well-suited to your workflow today may be behind the capabilities of its competitors within twelve months. Ask the vendor about their roadmap—not the vague "we are committed to continuous improvement" roadmap, but the specific features and integrations they are building and the timeline for building them. Ask how often the underlying AI models are updated. Ask what the process is for incorporating user feedback into product development.

The vendor whose roadmap aligns with the direction your practice is moving is a vendor worth building a relationship with. The vendor whose roadmap is confidential or vague is a vendor asking you to make a long-term commitment without long-term visibility.

The no-hype evaluation checklist

Beyond the seven vendor questions, here is the framework I use to evaluate AI tools in practice—the criteria that separate tools that are genuinely useful from tools that are impressive in demos.

Criterion 1: Output quality in your specific context

Do not evaluate the tool on the examples in the vendor's showcase. Evaluate it on your actual work. Take a real brief—a real design problem, a real user context, a real set of constraints—and run it through the tool. Evaluate the output not against the tool's aesthetic logic but against your specific design criteria. Does the output serve your user? Does it reflect your user's cultural context? Does it require significant revision to be usable in production? The ratio of useful output to revision cost is the most honest measure of a tool's productivity value for your specific practice.

Criterion 2: Learning curve versus productivity gain

Every new tool has a learning curve. The question is whether the productivity gain the tool delivers, once the learning curve is complete, justifies the investment required to reach that point. Be honest about the learning curve—not the time it takes to understand the tool's basic features, but the time it takes to develop the prompt fluency and workflow integration that produce genuine productivity gains. Tools with steep learning curves can deliver significant value—but the investment must be planned for, not assumed away.

Criterion 3: Impact on team capability, not just individual efficiency

AI tools that make individual designers more efficient can simultaneously make design teams less capable—if the efficiency gains are achieved by removing the deliberate practice of skills that the team needs to develop and maintain. The tool that automates first-pass wireframing may save a senior designer time while depriving a junior designer of the practice that builds layout intuition. Evaluate tools not just for their impact on your individual workflow but for their impact on the capability development of the full team.

Criterion 4: Failure mode acceptability

Every AI tool fails. The evaluation criterion is whether its failure modes are acceptable in your specific practice context. A tool that fails by producing aesthetically poor output is acceptable in most contexts—the failure is visible and correctable. A tool that fails by producing output that is culturally inappropriate, accessibly non-compliant, or factually incorrect in ways that are not immediately visible is not acceptable in contexts where those failures have consequences for users. Know your failure mode tolerance before you adopt.

Criterion 5: Reversibility

What happens if you adopt this tool, build it into your workflow, and then need to move away from it—because the vendor changes their pricing, or discontinues the product, or the tool's output quality degrades, or a better alternative emerges? Is your work portable? Are your files in formats that other tools can work with? Is the knowledge your team has built specific to this tool or transferable to alternatives? Tools that create lock-in—through proprietary file formats, non-exportable outputs, or workflow dependencies that are difficult to reverse—deserve additional scrutiny before adoption.

The organisational conversation: How to push back without being the obstacle

The framework above gives you the evaluation criteria. But applying those criteria in an organizational context requires a second skill: the ability to have a productive conversation about tool adoption with stakeholders who are motivated by social signals rather than evaluation criteria.

The design leader who comes to a leadership meeting and says "I do not think we should adopt this tool" without a clear framework for why is easily dismissed as resistant to change. The design leader who says, "Here is the evaluation framework I am applying to this tool, here is where it currently does and does not meet our criteria, and here is the timeline for completing the evaluation," is making a professional case that is difficult to dismiss.

The key is to position careful evaluation not as resistance to AI adoption but as responsible AI adoption. The organization that adopts AI tools through social pressure and demo enthusiasm is the organization that spends the next six months managing the gap between what was promised and what was delivered. The organization that adopts AI tools through deliberate evaluation is the organization that actually captures the productivity gains that AI can deliver—because it has selected tools that are genuinely suited to its work and its users.

This is the conversation that design professionals need to lead in their organizations. Not the conversation about whether to adopt AI—that conversation is over. The conversation about how to adopt it well. That conversation belongs to the people who understand both the tools and the users they are supposed to serve. That is designers and researchers.

What good AI tool adoption actually looks like

There are design teams and organizations that are getting this right—that are building genuine AI fluency without the tool churn and productivity disruption that characterizes rushed adoption.

The common thread across teams that are adopting AI tools well is not that they are adopting faster. It is that they are adopting more deliberately. They are starting with a specific problem they want to solve—a specific stage of their workflow that is time-consuming and amenable to AI assistance—rather than with a tool they have decided to adopt. They are evaluating tools against that specific problem, running structured pilots with limited scope and clear success criteria, and expanding adoption based on evidence from the pilot rather than enthusiasm from the demo.

ITX's approach to AI tool integration uses a policy-driven process for proposing, reviewing, and selecting the right tool for the job, protecting against adding new tools unnecessarily. This may be especially true when it comes to artificial intelligence.

They are also managing the distinction between tools that are useful for individuals and tools that are appropriate for team-wide adoption. The AI writing assistant that a senior copywriter finds genuinely useful may not be appropriate for a junior writer who is still developing the judgment to evaluate AI output critically. The AI research synthesis tool that accelerates a senior researcher's analysis may not be appropriate for a junior researcher who needs the practice of manual synthesis to build the interpretive skills that make them valuable. Adoption that improves individual efficiency while degrading team capability is not good adoption.

Applying LucyUX to AI tool evaluation

The LucyUX framework—Listen, Understand, Conceptualize, Yield—applies directly to the process of evaluating and adopting AI tools.

  • Listen: Before you evaluate any tool, listen to your team. What are the specific friction points in your current workflow? Where are the tasks that consume disproportionate time relative to the value they produce? Where is the work that feels mechanical—the transcription, the initial coding, and the generation of first-pass options—versus the work that feels genuinely creative and judgment-intensive? The answers to these questions define the problem space that an AI tool adoption should address. Listen before you evaluate, and evaluate against what you have heard.
  • Understand: Build an accurate model of what the tools you are evaluating actually do, distinct from what their marketing claims they do. This means running them with your actual work, not the vendor's demo content. It means understanding their failure modes, their cultural assumptions, their integration constraints, and their cost models at a realistic scale. It means talking to practitioners who have been using them in production—not the enthusiastic early adopters who are still in the honeymoon phase, but the teams who have been using them long enough to have encountered the limitations.
  • Conceptualize: Design your adoption process deliberately. Define the specific use cases you are adopting for. Define the success criteria that will tell you whether the adoption has achieved its goals. Define the evaluation timeline—the point at which you will assess the pilot and decide whether to expand, adjust, or discontinue. Define the guardrails—the contexts in which AI tool output will require human review before use, the contexts in which it is safe to use without review, and the contexts in which AI assistance is not appropriate. The adoption process is a design problem. Apply design thinking to it.
  • Yield: Measure what matters. Not the number of AI tools adopted, not the volume of AI-generated outputs produced, not the speed of the design process. The quality of design decisions. The experience of real users with the products that AI-assisted processes produced. The capability development of the team over time. These are the yields that tell the honest story of whether AI tool adoption is serving your practice—and they are the only yields worth reporting to the organization.

Your action this week

Identify one AI tool that your team is currently using or considering adopting. Apply the seven-question framework to it this week—either by going back to the vendor with the questions or by running the evaluation yourself with the tool in hand.

You will not answer all seven questions fully in one week. But the process of asking them will reveal something specific: which questions the tool's documentation and marketing answer clearly and which questions require you to dig or push. The questions that require digging are the questions whose answers most affect the tool's real-world suitability for your practice. The fact that they require digging is itself an evaluation signal.

Write down what you find. Not a formal report—a one-page honest assessment of what you know about this tool, what you do not know, and what you would need to know before you would be comfortable recommending it for full team adoption. That one page is the beginning of your team's AI tool evaluation practice. It is more rigorous than most organizations have. And it is the foundation of tool adoption decisions that hold up over time.

My perspective: What I actually believe

The AI tools landscape rewards the organizations that are thoughtful over the fast organizations. Not because being fast is bad—speed of adoption can be a genuine competitive advantage when the tools are right. But because the tools that are right are not identifiable from demos and marketing materials. They are identifiable from deliberate evaluation against specific criteria that only you and your team can define.

I have spent 25 years watching design tools come and go—tools that were going to change everything and then did not, tools that seemed niche and then became foundational, and tools that were adopted under pressure and then quietly abandoned when the pressure moved on to something new. The pattern I have observed consistently is this: the practitioners who developed a clear, criteria-driven approach to tool evaluation—who knew what they needed from a tool before they evaluated one—made better adoption decisions and built more capable practices than the practitioners who adopted based on what other people appeared to be doing.

AI tools are not different in this respect. They are faster-moving and more consequential than most previous tool categories—which makes the case for deliberate evaluation stronger, not weaker.

Evaluate before you adopt. Push for the answers vendors do not volunteer. Build the capability to evaluate before you build the dependency on the tool. That sequence—evaluation, then adoption, then fluency—is the sequence that produces genuine professional value from AI tools. The reverse sequence produces demos that impress in meetings but disappoint in production.

Up next in the "UX × AI" series: “The UX of AI Itself Is Broken.” We spend a lot of time discussing how designers should use AI. We spend very little time discussing how AI products are designed—and whether they meet the standards that the UX profession would apply to any other product. In Article 8, we turn the lens around: an opinionated audit of how AI products are designed today, the UX failures that are endemic across the category, and what it reveals about what happens when the people building AI products do not apply human-centered design principles to the products themselves.

References & further reading