A map, not a sales pitch
You already have a process. You know how to run a discovery, how to sit with a messy wall of notes until a theme emerges, how to argue for a flow in front of people who would rather ship the old one. None of that is in question here.
What most designers are missing is not craft. It is a clear sense of what these tools actually do, so you can predict where they will save you a day and where they will quietly waste one. That prediction is the point of this lesson. Get it right and the rest of the course is practical. Get it wrong and you end up either using AI for everything, which produces confident nonsense, or using it for nothing, which is a slower way to do the same job.
So: the mechanism first, then the map.
What a language model is actually doing
A language model is a system that predicts the next chunk of text, over and over, based on statistical patterns learned from an enormous amount of writing. That is not a slight. Prediction at that scale produces something genuinely useful. But it explains almost every strength and every failure you will meet in this course.
It explains why the tool is superb at producing the shape of a thing. A user flow has a shape. An empty state has a shape. A research theme written up for a stakeholder deck has a very recognisable shape. The model has seen a great many of each and can produce a competent one immediately.
It also explains why it will happily produce a research finding that no participant ever expressed. It is not lying to you and it is not confused. It is producing text that fits the pattern of a research finding, because that is the job it was built to do. Whether the finding corresponds to anything in your transcripts is a separate question that the mechanism never asks.
In plain English
- Language model:
- A system that predicts the next piece of text from patterns in what it has read. Everything it produces is a plausible continuation, not a looked-up fact.
- Hallucination:
- A confident, well-written claim that is simply not true. It looks identical to a correct answer, which is why it is dangerous.
- Context:
- Everything you have put in front of the model in this conversation. If it is not in the context, the model does not know it.
- Prompt:
- The instruction you give. In practice, the brief. Vague brief in, generic work out.
There is a second thing worth being blunt about, because it catches people out constantly. The model knows nothing about your situation except what you put in front of it in that conversation. Not your product, not your analytics, not last quarter's research, not the reason your team abandoned the tabbed version, not what your users are actually like. When it says something specific about your users, it is not drawing on evidence it has and you do not. It is producing the kind of sentence that usually appears in that position.
Hold on to both ideas: very good at form, no relationship at all with truth, and no knowledge of your situation beyond what you supply. Every recommendation in this course follows from those.
The honest map
Here is the design process, stage by stage, with a blunt assessment.
| Stage | How much it helps | Why |
|---|---|---|
| Framing and desk research | A lot | Summarising a domain, listing what you do not yet know, drafting a research plan. Form work. |
| Recruiting and interviewing | Not at all | You need real people saying real things. There is no substitute and no shortcut. |
| Synthesis | A lot, with supervision | It clusters and names themes quickly, and invents findings just as quickly. Lesson two is entirely about this. |
| Ideation | A little | It gives you volume, not novelty. Useful for breaking a blank page, poor at surprising you. |
| Flows and edge cases | A lot | Exhaustiveness is its strongest suit. It will list the states you forgot. |
| Wireframes and layout | A little | It can describe structure sensibly. It cannot see, so it cannot judge a composition. |
| Visual design | Not at all | Taste, hierarchy and restraint are not pattern completion. |
| Interface copy | A lot, after briefing | Strong drafts, wrong default voice. Lesson four fixes the voice. |
| Usability testing | Not at all | It has no users. A simulated participant tells you what plausible feedback sounds like. |
| Critique and pressure testing | A lot, carefully | A tireless devil's advocate, until it starts agreeing with you. Lesson five. |
| Handoff and documentation | A lot | Tedious, structured, high volume, low judgement. Ideal territory. |
Read the "not at all" rows twice. They are not temporary limitations you can prompt your way around. Interviewing needs a human on the other end. Usability testing needs someone who does not already know how the product works. Visual judgement needs eyes and a point of view.
The rows marked "a lot" have something in common too. In every one of them, the work is high in volume and low in irreducible judgement, and you remain able to check the output against something real. That is the pattern to look for when you meet a task this course does not cover.
The most expensive mistake in this space is asking a model to stand in for a user. It will produce fluent, specific, quotable feedback about your design. That feedback is a description of what feedback tends to sound like. Acting on it is worse than having no research at all, because it feels like evidence.
Checkpoint
A language model predicts plausible text, so it is strong wherever the work has a recognisable shape and weak wherever the work depends on truth, taste or real users.
Who should skip this course
Genuinely skip it, with no hard feelings, if any of these describe you.
You have never used an AI assistant for anything. This course assumes you can hold a working conversation with one and are not distracted by the novelty. Start with Prompt Engineering and come back.
Your real bottleneck is organisational. If your problem is that nobody reads your research, or that engineering starts building before you have framed anything, faster synthesis will not touch that. A better deck does not fix a broken relationship.
You work somewhere you cannot paste participant data. Health, finance, legal, government and plenty of other contexts have rules about where interview transcripts may go. Those rules are not obstacles to route around. If you cannot put the material in, most of this course does not apply to you, and the responsible answer is to stop here rather than to find a workaround.
You are hoping it will do the design. It will not. It has no taste, no stake in the outcome and no memory of what your team already tried and abandoned.
You want a tool tutorial. This course teaches habits deliberately. Tools change constantly. Habits do not.
If you are still here, the mindset that works best is treating it as a fast, tireless, occasionally dishonest junior collaborator. You would not ship a junior's work unreviewed. You also would not refuse their help on a tedious task.
Checkpoint
This course suits practising designers who can already work with an AI assistant, and it will not help with organisational problems, visual taste, or material you are not permitted to share.
๐ Quiz
Question 1 of 4Why does a language model produce research findings that no participant expressed?