Originally written February 2026

I use Claude to synthesise research. I have a structured instruction set, I manage context across projects, and I've developed the habit of challenging outputs rather than accepting them. I've been scored against seven dimensions of AI effectiveness and came back at 73 out of 100. None of that made me better at designing AI features for my users.

Those are two completely different things.

Using AI as a designer is a workflow practice. Designing AI-powered products is a design discipline.

The skills overlap less than you'd think. The first is about your relationship with the tool. The second is about your users' relationship with uncertainty. I've had to get better at both – and they require different things.

Thread 1 – AI as your tool

This is the thread most designers mean when they say they use AI. Research synthesis, wireframe generation, copy refinement, document drafting. The tools are getting faster and the outputs better, and the question is whether you're developing a sophisticated practice around them or reaching for occasional shortcuts.

Sophisticated practice looks like this: structured prompts that produce consistent output, context management across sessions, a default habit of challenging outputs rather than accepting them, and a workflow that uses AI to accelerate your thinking rather than replace it.

Roughly 70% of design teams now use AI routinely for wireframing, asset generation, and research synthesis. Thread 1 fluency is becoming table stakes rather than a differentiator. That's not an argument against developing it – a designer who has genuinely integrated AI into their workflow produces more, iterates faster, and synthesises research more thoroughly than one who hasn't. The point is that Thread 1 is the floor, not the ceiling. The ceiling is Thread 2.

Thread 2 – AI as your product

Designing for AI-powered features requires a different set of instincts entirely. When you use Claude, you know roughly what it's doing and roughly when it's wrong. You've built intuition about hallucination, about overconfidence, about the kinds of output that need verification. That intuition took time to develop, and it helps you enormously.

Your users don't have it. A legal fee earner interacting with an AI case summary doesn't have a model for when to trust the output. A solicitor reading an AI-drafted email suggestion doesn't know what the model was optimised for. They'll do one of two things: trust it completely or not trust it at all. Either failure mode is a UX problem.

Thread 2 is designing for this. Building trust mechanisms that don't require users to become AI-literate. Designing failure states for when the output is wrong – and the output will sometimes be wrong. Thinking about confidence display: how do you communicate to a non-expert user that this answer is more reliable than that one? Building override patterns that feel natural rather than like admitting defeat. These are genuinely hard design problems. Thread 1 experience doesn't prepare you for them.

Why conflating them matters

The failure mode when you don't distinguish the two threads is predictable: you design AI features for users like you. You assume they'll read the output critically. You assume they'll know to re-prompt when it's wrong. You assume they understand what "AI-generated" means in terms of reliability. Designers who are sophisticated AI users bring those assumptions into the product because they feel natural – because they are natural to them.

They're learned behaviours, developed through hundreds of interactions with the tools. Most users haven't had them. The Niland Test – the evaluation framework I built for testing prompts against real legal users – exists precisely because of this gap. Prompts that seemed strong to me performed poorly with fee earners who had different mental models, different domain knowledge, and different tolerance for uncertain output. My intuition about what good looked like wasn't reliable for their context. The evaluation method had to be built to bridge that gap.

Thread 2 design requires research into how your specific users form mental models of AI behaviour. That's not a tool fluency question. It's a user research question.

What both look like in practice

Thread 1: I use Claude to synthesise research findings from UserZoom sessions, route different types of design work across separate project contexts, and challenge outputs as a default rather than an exception. The workflow habits that accelerate research, sharpen thinking, and produce more consistent output.

Thread 2: designing the Copilot AI interface for legal professionals, building the Niland Test evaluation framework, the Sentiment Analysis notification that earns trust before it acts, and the decision tree that turns an AI summary into a concrete next step. Each required thinking about trust, transparency, failure, and user mental models rather than about how to get a better output from the model.

The reason both matter for hiring is that Thread 2 is where most of the value is – and where most designers fall short. Thread 1 is increasingly expected. Thread 2 is still rare. A portfolio that demonstrates you can do both tells hiring managers something specific: you understand AI from both sides of the interface.

A note on AI fluency

The industry talks about AI fluency as if it's one thing. It isn't. A designer can be excellent at Thread 1 and have no Thread 2 instincts at all. A designer can have done extensive AI feature design and still use Claude like a search engine. Both gaps are real, and both limit what you can do.

The designers who will shape how AI is integrated into products over the next decade will need both the workflow fluency to use the tools well and the design discipline to build for users who don't have that fluency. That's the gap worth building toward. Not just using AI well. Designing for people who use it differently from you do.