06 · What I do
Twenty-seven methods, and the discipline to not run most of them.
The list is here because a specification usually names one of them, and a page that leaves it out fails the search you are running. Complete is the easy half.
The harder half is on the right. Three real projects, and the handful each of them actually used. No two took the same set, because the question came first and the method came after it.
A method chosen before the question is a method chosen for the proposal.
A method is a named way of finding something out or deciding something. Sitting with people while they work. Testing a screen with eight of them and watching where they stop. Running a session that ends with a decision somebody signs. Nothing on the list below is more exotic than that.
They are listed in full because job specifications name them, and if the one you are matching against says “card sorting” you need to see the word. What the rest of the page argues is that running more of them is not better work. Three to six is what a real project has needed, and choosing which three is the part you are actually hiring.
Before any of them runs
Three reasons a method gets run, and two of them are bad.
Research budgets are rarely wasted on bad sessions. They are wasted on good sessions that nobody was waiting on. These are the two failures I watch for in myself, not just in briefs that arrive.
The method was named to win the work, before anybody knew what the question was. Now it runs because it was promised. A card sort agreed in a pitch is a card sort answering a question nobody has asked yet, and the budget it spends is the budget that should have gone on fixing what it found.
Every practitioner has a favourite and every favourite gets over-run. Mine is watching people work, which means the discipline I need is knowing when the answer is a number rather than an observation. A method you are fluent in is the easiest one to run for no reason.
Something is about to be built one of two ways, somebody has to choose, and there is a result that would change their mind. If no possible finding changes anything, the study should not run, however well it would go.
Which is why the number below is small. Twenty-seven is what I can run. Three to six is what a project has ever needed, and the gap between those two numbers is the part of this job that is judgement rather than technique.
The full twenty-seven
Grouped by what they are for, with what each one settles.
Listed plainly, because you may be matching against a spec that names one of them. Each line is what that method can settle, which is also the fastest way to see when it is the wrong one to reach for.
Named in a spec, and worth a conversation
Four I will push back on, and what I would run instead.
Not refusals. If you need one of these for a reason I have not thought of, we run it. But I would rather have the argument in week one than hand you a deliverable in week six that answers nothing.
Asked for when interviews are meant. Put eight people around a table and you get the group's answer: the confident one anchors it and the rest calibrate to them, which is a real finding about groups and nothing at all about how any one of them works alone.
Instead: the same eight as individual interviews, or a co-creation session if the point really is to get a room to agree on something.
The method is fine. The ask is bigger than it sounds: five consecutive days of the decider, the engineer and the domain expert, all of them off their other work. In an enterprise that is a scheduling negotiation, not a design decision.
Instead: if those five days cannot really be had, two workshops with the same people and a prototype between them. A sprint without the decider in the room is a workshop with a countdown on it.
It needs traffic and one agreed measure. Most enterprise products I work on have neither: a few hundred named users, and four stakeholders who each have a different definition of better. An underpowered test does not give you a weak answer, it gives you a confident wrong one.
Instead: usability testing to find out what breaks, then analytics to size it once it is live.
Both produce volume, and volume is almost never the scarce thing. A team stuck on a problem usually has more ideas than it can evaluate. The bottleneck is choosing, and a wall of stickies makes choosing harder rather than easier.
Instead: name the constraint, then run a workshop that ends in a decision somebody signs.
The same list, on three real projects
Three products, three different subsets, none of them larger than six.
These are the methods with a case study behind them rather than a claim. The rest of the twenty-seven are things I can run when a question needs them.
The brief that arrived was about coverage: more datasets, newer sources. Fifteen analysts working real quotes said the bottleneck was interpretation, not lookup. Support tickets and survey responses said it again from another angle, so I timed it directly.
Contextual inquiryUser surveysUsability testingInformation architectureThe sessions were fine and the findings were real. The only thing wrong was where in the cycle they happened, so testing moved inside the sprint and ran against the previous sprint's designs, while the design could still change.
Usability testingUser surveysJourney mappingFifteen organiser interviews produced one persona that decided the product: an HR manager running events on top of her real job. A competitor sweep found five gaps, and the interviews had already returned two of them unprompted.
InterviewsUser personasMarket researchJourney mappingInformation architecturePrototypingThe other five
Where these methods are actually spent.
This page is the index. The five below are the work the methods get chosen for, and none of them is bought as a method.