UX Researcher

While understanding users belonged to nobody in particular, the people building did the asking. That isn't a problem in itself, but the shape of the questions changes. Sitting down with a screen you drew yourself produces sentences like "this screen is easy to use, right?", and the person across the table looks at the face of whoever made it and says it seems fine. Nothing can be changed on the strength of that exchange.

Scheduling compounded it. Told to run three user interviews in the morning and ship a screen in the afternoon, what survives is the screen, because work with a deadline pushes out work without one. Research slips until it runs once in a batch at the end of the quarter, and by the time results arrive the decisions are already made.

So the work of running research got its own seat. Not because the skills divide, but because the days are structured differently. Meeting people means booking ahead, planning around cancellations, and spending hours sorting afterward. Slot that next to screen work on the same day and one of the two always slides.

The day is filled with time spent with people plus the preparation and cleanup on either side of it. The work comes in five bundles.

1. Setting the question — work backwards from what the team is trying to decide. Asking whether people like our search produces an answer with nowhere to go; asking where someone goes first when looking for a document from six months ago feeds straight into deciding what sits highest on the screen.
2. Recruiting — find five to eight people matching the criteria. Half the actual hours go here: writing the criteria, reaching out, matching calendars, and booking one extra against a same-day cancellation. Eight is the number because the same answers start repeating around the fifth or sixth person.
3. Running the sessions — a customer interview, a conversation to hear someone's experience and context directly, runs about 60 minutes, and three a day is the ceiling. The craft here is avoiding sentences that lead to an answer. Rather than asking how something felt, walk them back through what they actually did last time. In a usability test, where real tasks get performed to find the snags, you say almost nothing and watch the hands in front of the screen.
4. Sorting — pull statements out of the transcripts and group the similar ones. Six of eight people saying the same thing is usable evidence; two is still one person's circumstances. Writing the count down beside the finding matters, because otherwise the one memorable quote gets cited later and the whole picture bends around it.
5. Delivering — a 30-page report doesn't get read. A one-page summary goes out with a 30-second screen recording. Watching 20 seconds of someone hunting for the save button, together, in the meeting, produces a decision faster than ten lines of prose.

Research runs on two cycles. A short study attached just before a decision takes a few days and settles the direction of one screen. A quarterly study takes weeks and settles what gets built next quarter. Which method fits which seat gets chosen from the toolkit collected under UX research methods.

Questions arrive from the side deciding what to build, and results leave toward the side making screens. Five seats sit in between.

1. Product manager — the one bringing what needs deciding. When Mia has the next quarter's candidates organized, the items with no evidence behind them become the research subjects.
2. Designer — the one putting screens up to be tested. Noa's mockups go in front of users, and what comes back is where the hands stopped. Speed matters in this relationship. Results that arrive after a mockup has already gone to engineering get used next quarter at best.
3. Data — the product analyst, who turns product data into evidence, works as a counterpart. Numbers say what happened and how often; research says why. That 40 percent drop out at the checkout screen is something the numbers find, and what people hesitate over there is something research finds.
4. Sales and customer success — the channel to enterprise users. Without Sofia arranging the calendar, users inside large companies are hard to reach at all, since their time usually has to be cleared by somebody else.
5. Engineers — who get asked for a test build. When Theo produces a half-working screen in two days, more surfaces than a static picture ever shows.

"This isn't a decision worth putting a researcher on. Let's look at the numbers first."

Separating what needs research from what a count can answer.

"Six of eight opened the folder first. Only two used the search box."

Reporting with counts attached so the size of the evidence is visible.

"That question leads the answer. Don't ask how it felt, ask what they did last time."

One sentence of phrasing can move the entire result.

Pagedeck has no dedicated researcher yet, so Noa carries the work. Sessions with six users are booked as a fixed item each quarter, and no screen work goes into that week. Last quarter eight people were given the search results screen to use; six of them couldn't find the filters, and that 20-second recording set the next quarter's work.

The most common mistake is reading research as going and asking users what they want. Asking users sounds exactly like that. But questions about wants mostly return answers shaped like whatever tool the person uses today. Ask what a document list needs and you get a request for more sorting options, while watching people reveals that they ignore sorting and go to the search box. So the questions point at what someone actually did rather than what they wish for. Walking someone back through how they found that document last time yields more usable answers than asking which feature they need.

Dismissing it for small samples is the other one. Applying a conclusion drawn from eight people to tens of thousands sounds statistically uncomfortable. But the question this work answers is not what percentage — it's what is blocking people and why. What share of users can't find the save button is a question for counting; why they can't find it shows up after watching five. Use this method on a question about proportions and you will be wrong, and use counting on a question about causes and you'll invent the cause from the number.