I watched a senior designer close a six-month project last year with a decision that nobody on the team could explain afterwards. Not because it was wrong - it worked beautifully. But because the reasoning behind it was so soft, so rooted in accumulated instinct, that when someone asked "how did you know to go that direction?" the honest answer was "I just knew."
He'd spent weeks sitting with the research. Not reading summaries - sitting with it. He'd had three difficult conversations with stakeholders that changed his understanding of what the business actually needed, as opposed to what they'd written in the brief. He'd observed users doing something with the product that nobody had anticipated and that no interview would have surfaced. And somewhere in the middle of all that - in a way he couldn't fully articulate - a direction emerged.
AI cannot do this.
AI can produce deliverables. It can structure a competitive analysis in minutes, generate a research synthesis that reads well, build out a complete information architecture from a set of requirements. It can create - with or without deep context, it can produce. But can it push the work forward the way that designer did? Can it - for better or worse - at least say with conviction "this direction is right, and here's why I believe that"?
No. What you get instead is a confident-sounding output that shifts direction the moment you question it. A changed approach every time you push back. A deliverable that exists, looks professional, can be presented in a review meeting - but the understanding that's supposed to live underneath it was never built.
And that's the distinction this blog is about. Not whether AI is useful - it is. Not whether designers should adopt it - they should, and we've written about how to do that well. But there is a layer of design skill that AI cannot reach, and if you let that layer atrophy because the deliverables are coming faster than ever, you'll discover the loss at the worst possible moment - when a project demands judgment and all you have is output.
What "Core Skills" Actually Means
When I say core skills, I don't mean "knowing Figma" or "being able to run a usability test." I mean something deeper - and harder to teach.
Core skills means gaining genuine context of your work, your domain, and your users, and using that context to drive a solution that fits into customers' lives. Not a solution that looks good. Not a solution that passes a review. A solution that works - in the real world, under real constraints, for real people.
That definition hides a lot behind it. Let me unpack what it actually involves:
You have to set a direction first - not just accept one from a product manager. You have to identify the relevant goals and milestones for your work. You have to find users to talk to - real ones, not synthetic proxies. You have to conduct those conversations and figure out what people actually mean when they say something, because what they say and what they mean are rarely the same thing. You have to generate insights and recommendations from that data - not summaries, insights. You have to ideate solutions, test those solutions, develop them to a point where they work, put them into the field, and check whether they actually deliver on the promise.
When I lay it out like that, it sounds like a process. A sequence. A workflow that could theoretically be automated.
But here's what actually happens: a human designer stands at the centre of all of this and weaves each stage to the next. They skip some stages. They add others. They loop back when something doesn't feel right. They make calls based on experience, intuition, and a reading of the room that no model can replicate.
And sometimes - this is the part that's hardest to explain - the direction a senior designer takes is so soft in nature that you can't even articulate why they went that way. They read something in the research that wasn't in the data. They sensed a stakeholder concern that wasn't spoken. They made a design choice that seemed counterintuitive but resolved three downstream problems no one had identified yet.
And that choice concluded the project positively.
This is tacit knowledge - and it's the most valuable thing a designer develops over a career. Research from CHI 2024 found that tacit knowledge in design "relies heavily on intuition and experiential knowledge, making it difficult to articulate, codify, or share" [1]. The California Management Review published a piece in March 2026 titled "Tacit Knowledge Is Your Next Competitive Moat," arguing that "the real differentiator is not the data or even the models, but the tacit knowledge embedded in the judgment of their people" [2].
AI doesn't have tacit knowledge. It has statistical patterns. And the gap between those two things is where design quality lives.
The Ford Lesson
If you think this argument is theoretical, consider what happened at Ford Motor Company.
In June 2026, Ford launched a campaign to rehire veteran engineers - the so-called "grey beards" - who had been pushed out through early retirement packages and layoffs, replaced by software developers and AI-powered simulation systems. The promise had been seductive: faster development cycles, lower costs, elimination of physical prototypes through digital twins and generative AI [3].
It didn't work.
The algorithms couldn't predict how a specific metal alloy would react to extreme temperatures after five years of use. They couldn't sense the subtle vibrations that signal a future transmission failure. They operated in what engineers called a "sterile data environment" - technically accurate but experientially hollow.
Ford had to bring back the people whose intuition was built from decades of hands-on work. The AI could model. It couldn't know.
This is the exact same dynamic playing out in design teams right now. AI can generate a persona. It can't know your user. AI can produce a journey map. It can't feel where the experience breaks.
The Hammer and Nail Problem
Now, when you read all of this, you might think I'm saying AI is useless throughout the product lifecycle. I'm not. We've written extensively about how AI changes what you design, why the "replacement" framing is wrong, and how to build a personal AI workflow that actually makes your practice stronger.
What I am saying is: you don't have to use a hammer on everything by treating every problem as a nail. You need to figure out what actually needs a hit.
Here's the distinction:
Use AI when deliverables need to be structured from things you've already learned.You've spent two weeks in research. You have raw data, notes, observations. Using AI to help structure that into a coherent synthesis document? That's leveraging a tool for what it's good at - organising volume. The insight came from you. The structure comes from AI. That works.
Use AI when you need to collect and process data - but not to drive final insights from it.AI can scrape competitor reviews, aggregate support tickets, transcribe interviews, and surface preliminary patterns. Excellent. But the moment that says "users are frustrated with onboarding" - that's a summary, not an insight. The insight is why they're frustrated, what that frustration connects to in the broader experience, and what it means for your design direction. That's yours.
Use AI when you have a concept vision and need a tangible expression of it.You know the direction. You can see it in your head. Using AI to rapidly generate visual explorations of that direction, to produce variations you can react to, to accelerate the translation from concept to screen? That's smart use. The vision came from you. The execution speed comes from AI.
Use AI when you need to evaluate at scale. You have a heuristic evaluation framework. AI can apply it across dozens of screens and flag potential issues. You can then review that evaluation report with human judgment - confirming, dismissing, or investigating further.
In all of these cases, the process remains in your control. AI is a tool within your workflow, not a replacement for your judgment.
But if you're using AI in stages you don't completely understand yourself, you will end up only convincing yourself and your team. And that usually hurts more than it can help.
The Story That Illustrates Everything
Let me give you a real example.
A designer I spoke with needed to recruit participants for usability testing on a B2C product. They decided to run recruitment ads on Meta - Instagram specifically. They used Claude with Meta's MCP integration to set up the campaign.
The first problem: Meta's objective as a platform is to make you spend as much as possible. Claude's natural tendency is to be helpful and say "yes, we can do this." Neither of these incentives are aligned with the designer's actual goal - finding five qualified participants for ₹2,000.
They launched the campaign. The first cycle generated leads, but they were unqualified - wrong demographic, wrong behaviour profile, people clicking because the ad was interesting rather than because they matched the research criteria.
They went back to Claude. "This is common, I understand," it said. "You targeted too broadly. Let's tighten the audience, adjust the budget, change the creative." Confident. Reassuring. Plausible.
Second cycle: zero leads. The audience was now too narrow. Budget too low for the restricted reach.
They iterated again. And again. Each time, Claude offered a new explanation and a new adjustment - each one internally logical, each one failing to produce results.
After several futile cycles, the designer realised the core problem: they needed someone who had actually run successful participant recruitment on Meta. Not someone who could theorise about it. Not a model that could generate plausible-sounding advice. Someone who had done it, failed, learned what the documentation doesn't tell you, and developed the tacit knowledge of what actually works.
Claude can help. But it can't direct. And in stages where you don't have the expertise to evaluate whether its help is good, you end up in a confident-sounding loop that goes nowhere.
The Automation Fantasy
This brings me to a pattern I'm seeing with alarming frequency.
A product manager - usually someone without deep design experience - decides that the design workflow should be automated with AI. End to end. Research to delivery. They've seen the demos. They've read the case studies. They believe that what used to take a designer two weeks can now take an AI thirty minutes.
They're inviting a mess.
Not because AI can't participate in the design process. It can, and it should - as we discussed in our piece on evaluating AI tools for design teams. But because the process of building core design understanding requires things that shouldn't be automated, even if it feels like you can.
Automating research means the designer never builds empathy. Automating synthesis means the designer never develops judgment. Automating ideation means the designer never learns to navigate ambiguity. Automating evaluation means the designer never calibrates their own quality bar.
MIT economist Daron Acemoglu's 2026 research on AI and knowledge systems warns that "automating entry-level tasks can negatively affect long-term growth because it hampers the intergenerational transmission of tacit knowledge" [4]. When you automate the learning stages, you don't just speed up the work - you eliminate the conditions under which expertise is developed.
A design team that automates its core workflow doesn't become faster. It becomes shallower. And shallow teams produce shallow work - work that looks professional but doesn't hold up when it meets real users, real constraints, and real business pressure.
The Core Skills AI Can't Touch
So let me be specific. Here are the design skills that remain fundamentally human - the ones that AI can assist with but cannot perform, and the ones that will define your value for the foreseeable future:
Problem isolation. Being able to sit in a room with stakeholders - each with their own agenda, their own understanding of the problem, their own definition of success - and guide that group toward a shared, specific problem to solve. AI can provide supporting data to help you find a good problem. But it cannot navigate the politics, the egos, and the competing priorities to get five people to agree on one problem worth solving. You and the team do that.
Contextual research judgment.Reading your organisation's culture and your project's real constraints - not the stated ones - and determining which research methods to propose. Knowing that a diary study is the right approach but that your timeline doesn't support it, so proposing a contextual inquiry instead. Knowing that your stakeholder will dismiss survey data but will be moved by watching a user struggle on camera. This is organisational intelligence layered on methodological knowledge, and AI has neither.
Direct user observation.Going and watching your users struggle through things you have already delivered. Sitting in their environment. Noticing the workaround they've developed that they'd never mention in an interview because to them it's just "how they do it." The insight that changes your direction often comes from something you see, not something you're told. AI cannot observe. It can only process what's been captured and described.
Stakeholder influence.Presenting a design direction to a sceptical VP and reading, in real time, whether they're tracking with you or losing patience. Adjusting your language mid-sentence. Knowing when to show data and when to tell a story. Knowing when to push and when to concede gracefully. This is a performative, embodied skill that AI cannot replicate because it requires reading a room - not just the words being spoken, but the body language, the tone, the unspoken hierarchy.
Strategic direction-setting.Looking at incomplete information - partial research, ambiguous business goals, conflicting stakeholder input - and committing to a direction anyway. Not because you're certain. Because you've synthesised enough signals to make an informed bet, and you have the experience to know that moving forward with 70% confidence is better than waiting for 100%.
Ethical and contextual judgment.Deciding that a feature shouldn't exist even though it's technically possible and commercially attractive. Recognising that a dark pattern will increase conversion but erode trust. Understanding that a different culture uses your product differently and that your Western-centric persona doesn't account for that. These are moral and contextual decisions that require human values, not statistical patterns.
Cross-functional weaving.Moving between research, design, engineering, and business conversations - translating between each group's language, priorities, and constraints - and maintaining coherence across all of them. This isn't a single skill. It's a continuously improvised performance that shifts based on who's in the room, what's at stake, and what happened in the last meeting.
Adaptive process design. Knowing which parts of the design process to follow, which to skip, which to extend, and which to invent - based on the specific project, team, timeline, and organisational context. No two projects should follow the same process, and the designer who recognises this produces better work than the one who follows a fixed methodology, whether that methodology is human-designed or AI-suggested.
As one UX writer quoted in Figma's State of the Designer 2026 put it: "AI does not recognise nuance, cultural references, perspective, or depth. Those are human capabilities that cannot be replicated" [5].
What This Means for You
If you're a designer reading this and feeling somewhat defensive - "but I use AI well, I'm not over-relying on it" - good. You're probably fine.
But ask yourself this: in the last month, have you sat with a user in person? Have you facilitated a stakeholder alignment session without a template or AI-generated agenda? Have you made a design decision based on something you felt rather than something you could point to in a report? Have you navigated an ambiguous situation where there was no clear data and you had to commit to a direction anyway?
If the answer to most of these is no, your core skills are atrophying. And they atrophy quietly - you don't notice until the moment you need them and they're not there.
Strengthen your core. Use AI for what it's good at - we've written a detailed guide on building your personal AI workflowthat gets this balance right. But protect the stages where understanding is built. Those stages are slow, messy, and uncomfortable. They're also irreplaceable.
Be honest about what you don't know.If you're using AI in a domain you don't have expertise in - like the Meta ads example - recognise the limits early. AI will make you feel competent. Feeling competent and being competent are not the same thing.
Resist the automation pressure. When a PM or a leader suggests automating the design workflow end-to-end, push back - with evidence, not emotion. The work that builds lasting product quality is the work that AI can assist with but cannot own. We explored what design teams should look like in 2026and the answer isn't "fewer designers doing more with AI." It's "designers who are stronger at the things AI can't do."
The designers who will define the next decade of this profession aren't the ones who mastered the most tools. They're the ones who built the deepest understanding - of users, of businesses, of human complexity - and learned to use AI as an amplifier for that understanding, not a substitute for it.
That's what we develop at Xperience Wave. Not tool training. Not workflow automation. The core skills - research judgment, stakeholder influence, strategic direction, business fluency - that make you irreplaceable in any market condition. If you want to know where your core is strong and where it's thinning, talk to us.
Sources & References
- [1] Son, K. et al. (2024). "Demystifying Tacit Knowledge in Graphic Design: Characteristics, Instances, Approaches, and Guidelines." CHI Conference on Human Factors in Computing Systems 2024. https://dl.acm.org/doi/10.1145/3746058.3758467
- [2] California Management Review. (2026). "Tacit Knowledge Is Your Next Competitive Moat." March 2026. https://cmr.berkeley.edu/2026/03/tacit-knowledge-is-your-next-competitive-moat/
- [3] The AI Chronicle. (2026). "Ford Rehires Veteran Engineers After AI Failures." June 2026. https://theaicronicle.com/en/news/companies/ford-rehires-gray-beard-engineers-ai-shortfalls
- [4] Acemoglu, D. & Kong, D. (2026). "AI, Human Cognition and Knowledge Collapse." MIT Economics Working Paper, February 2026. https://economics.mit.edu/sites/default/files/2026-02/AI,%20Human%20Cognition%20and%20Knowledge%20Collapse%2002-20-26.pdf
- [5] Figma. (2026). "State of the Designer 2026." https://www.figma.com/blog/state-of-the-designer-2026/
Further Reading on Xperience Wave
- AI as Design Material: How Knowing What AI Can Do Changes What You Design
- Why "AI Will Replace Designers" Is the Wrong Question
- How to Build Your Personal AI Workflow as a Designer
- A Design Leader's Framework for Evaluating AI Tools
- What Should a Design Team Look Like in 2026?
About the Author
Shaik Murad is Co-founder and Head of Product & Design at Xperience Wave, a UX design studio based in Bangalore, working across designer mentorship, UX services for businesses, and a design community of 1,000+ designers.
- Murad, Co-founder & Head of Product & Design, Xperience Wave
