There’s a certain kind of confidence that precedes failure, if not total disaster, in product design work. It’s not quite arrogance exactly — it’s the quiet, settled feeling that you’ve thought of everything. The brief is solid. The research is done. The team is aligned. You proceed with producing the design.
And then, somewhere downstream, reality introduces itself.
What you missed wasn’t a mistake in reasoning. It was likely a gap in awareness — a blindspot. And blindspots, by definition, don’t exactly announce themselves. That’s what makes them dangerous, just like when flying down a highway at 70 mph while changing lanes! 😬
❖ First, a distinction worth clarifying.
A risky assumption is something you know you’re assuming but haven’t yet verified. “Users will have stable Wi-Fi.” “The enterprise admin controls provisioning.” “Users will read the onboarding copy.” These are the live wires. You can see them, test them, mitigate them, etc. They’re risky but manageable.
A blindspot is something else entirely. It’s not a belief you’re holding loosely. It’s a consideration that hasn’t entered the frame at all. The field user accessing your product on a three-year-old Android in a construction yard. The organizational dynamics that will quietly route around your carefully designed workflow. The emotional residue of a legacy system your users spent five years resenting. 🙃
The relationship between these two is dynamic, not fixed. Surface a blindspot and it becomes a risky assumption — now visible, now workable. But ignore a risky assumption long enough and it retreats back into the shadows. It becomes invisible again, except now with potentially dire consequences attached.
This is why the work of surfacing blindspots is not a phase of the design process. It’s a posture — a continuous act of interrogation directed at your own thinking. 🤔
❖ The FADE framework I apply to this problem, works simply.
Facts — what is actually known, not inferred. Assumptions — what’s being treated as true without verification. Dependencies — what external conditions and correlations must hold for this to work (technical, political/relational, economic). Expectations — what success looks like, and whose definition of success we’re using.
Running a project through these four lenses doesn’t take long; but it tends to produce uncomfortable questions fast. And that’s the point!
Paired with pre-mortems — exploring “how does this fail?” before the work begins — and other pre-design dialogues (structured challenges to the problem framing itself, before any solution-thinking begins), FADE becomes a practice for catching what you would otherwise carry forward as invisible freight.
The deeper pattern here: blindspots aren’t just missing features or overlooked use cases. They’re misalignments across systems — gaps between the mental model the team is operating from, the data model the product is built on, and the actual experience model users are living.
When those three drift apart, blindspots proliferate. Surfacing them requires attending to all three simultaneously.
❖ Now let’s see when AI enters — and how it gets interesting.
So the standard pitch for AI in design basically goes something like: AI helps you execute so much faster, generate way more options, and thus cover more ground sooner. OK sure. But the more generative framing — or the one I find more useful and more impactful — is this:
AI can serve as a provocation partner.
When I use AI in early-stage design work, I’m not asking it to solve anything per se. I’m asking it to debate with me through exploratory investigations. I want it to surface edge cases I haven’t considered, identify assumptions I’ve treated as facts, expand across user contexts and failure modes I haven’t realized. The prompt I reach for often is pretty straightforward:
Identify potential blindspots and risky assumptions.
Suggest ways to validate or mitigate these early.Used this way, AI functions as a structured adversary of sorts — something that interrogates the problem space rather than populating it. The distinction matters enormously. An AI that just generates solutions is a production tool. An AI that interrogates your framing is a thinking partner. The first makes you faster. The second makes you less wrong, or at least a bit more critical.
❖ But here’s what the standard AI pitch omits.
AI doesn’t eliminate blindspots. It relocates them.
Before AI, your blindspots were largely a function of cognitive limits — what your team had time to think about, what your experience had equipped you to see, what your organizational culture made it easy to say aloud. With AI in the loop, those particular blindspots shrink. But new ones emerge, and they’re more insidious because they wear the confident costume of thoroughness. 🤨
Here’s what I think of as second-order blindspots:
False completeness. The AI generated a comprehensive list of considerations. The team looks at it and relaxes. Nobody asks what wasn’t on the list — what the AI couldn’t perceive because it wasn’t in the prompt, the context, or the training model.
Authority misplacement. AI outputs start being treated as findings rather than provocations. The distance between “AI suggested this” and “research shows this” collapses faster than you’d expect, especially under deadline pressure! Something to watch out.
Homogenized thinking. AI converges toward common patterns — what’s most common, most documented, most statistically central, and yes the mediocre middle. 😒 Blindspots at the edges, in the long tail, in the weird organizational corner cases, are exactly what it will miss.
Organizational invisibility. AI cannot feel the politics in a room. It doesn’t sense which executive is quietly committed to the old system, which team is being asked to change without being given the resources to do so, which incentive structure will route around your elegant solution the moment it meets the real world. These are not edge cases. They are frequently the whole game! The relational ecology of power dynamics of the client/customer is crucial to factor into product strategy. This is tacit, interpreted knowledge — it lives in relationships and can only be read by someone present in them, not simply data fed into an LLM.
Finally, the unsaid. AI works from what you give it. No less, no more. It has no access to what wasn’t articulated — the fear nobody named in the research interview, the constraint the client didn’t mention because they’re embarrassed by it, the user behavior that contradicts the story everyone in the building has agreed to tell. But maybe that will be compensated very soon!
❖ The meta-insight I keep returning to is this —
The shift AI introduces is not from blindspots to clarity. It’s from blindspots rooted in human cognitive limits to blindspots rooted in human-AI interaction patterns — what you asked, what you accepted too quickly, what neither of you could perceive.
This is not an argument against using AI in design work.
I use it constantly, and I do truly think the designers who resist it on principle are missing something valuable. But it is an argument for using it with a specific stance: not as an authority to defer to, but as a sparring partner to test against. An adversary that is practically useful because it is fast, pattern-rich, and completely without political instincts.
The goal isn’t to trust the AI’s blindspot analysis outright. The goal is to use it to surface your own — and then apply the judgment, contextual intelligence, and organizational literacy that no model in the current releases can simulate or fake. 🙌🏽
There’s a posture shift embedded in this. Instead of asking “what should we build?” you ask “what are we missing?” Instead of treating AI outputs as answers, you treat them as better questions. Instead of using AI to finish thinking, you use it to recalibrate thinking — to go back to the frame and interrogate it further. ⚡️
❖ Design done well is an act of structured humility.
Not the performative humility of “we don’t have all the answers yet.” The real kind — the kind that builds astute questioning into the process, that treats its own assumptions as malleable, that knows the riskiest moment in any project is the moment the team feels certain.
AI, used well, can be a tool for that humility. It can accelerate the surfacing of what you don’t know you don’t know — which is rare and valuable. But it requires you to hold it as a provocation, not a verdict! This demands pause with patient resolve against the pressured velocity to build and ship now.
Your blindspot is not always where you think it is. That’s the whole problem. And that’s where the real design work begins. 🙏🏽
✦ If you're leading a team trying to fit in AI as that sparring collaborator, I'm happy to talk through it! My consulting & coaching work features helping designers & design orgs find their footing amid these inflection points. Reach out to book a time >
Great perspective, @Uday Gajendar — esp. about the paradigm shift needed in in how we see and work with AI. I have been implementing some of these bias/blindspot finding mechanism in my solo independent work but your piece articulated it in a way that gives it a language.
I really like the FADE framework which I think succinctly captures an approach to document if not start address the issue (I am in half in a mind to ask your permission to make it as a Skill in Claude😀) — I would love to start using it in my work and see how.