04 · Design · Ride-along
The arrive button is in the cab. The person is already on the dock
The user researcher watches how a task fails in the body and on the site, not which item is missing from a feature list. He does not promise to change the product. Findings go to the product manager's to-do.
- 05:10 Depart. The driver holds the phone in one hand, the other on the wheel. A small-type list he will overshoot.
- 06:40 Arrive. He is already off the truck at the dock. The arrive button is still on the previous screen. He lets the warehouse clerk tap it on their own phone.
- 06:55 Hand over. Paper delivery note and phone state do not match. He does not know which one counts, so he photographs both.
The user researcher keeps "how people fail" apart from "what the rule is"
The business analyst records document exceptions. The user researcher records the body, the place, and the pause while the job is finished. Public user-research roles talk about contextual interviews and usability tests, not satisfaction surveys. DaXi Technology puts research on the shift: ride along, follow nights, watch under noise and gloves. "I think this button should be bigger" in a meeting room is an opinion. Someone on the dock who cannot hit it is a finding.
The user researcher does not promise the product will change. He hands over observations: at which step the pause happened, what workaround the person used, which data the workaround made false. An observation has to enter the product to-do as "arrive happens on the dock; the recorder is not the driver", not "experience is poor". Proxy taps, screenshots, logging in as someone else — all say the system's task and the person's place are not together. The product manager decides whether to change it. The user researcher makes sure the decision maker sees behavior, not his preferred design.
A study writes what it will watch before leaving, or it becomes a tour
Before departure he writes three watch points. More than that he will not remember. This time: where the person stands when arrive happens; which screen the phone is on; which one they trust when paper and system disagree. He does not treat a full video as the finding. Video is only for checking times later. Field notes use the person's words, not sentences like "experience is poor". Experience-is-poor cannot tell the interaction designer where to move a button.
The sample must include people who are not fluent. Follow only veterans and the finding becomes "they can all use it". New drivers, a covering warehouse clerk, someone who holds the gun left-handed — those are where the interface assumptions break. The user researcher also refuses to treat a leader's demo path as the user path. Leaders do not do this action every day. The three watch points are on one sheet before leaving. If no proxy tap happens on site, the first observation is falsified. The conclusion cannot be rewritten as "experience is still poor". Falsification also goes into the report, or the study only collects scenes that match the guess.
After a proxy arrive, the timing is fake
A delivery project wanted to score drivers on arrive time. The user researcher rode two early shifts. The arrive button sat on the second screen of task detail. After parking, the phone was still on navigation. He got out to match papers with the warehouse clerk. To keep the queue moving, the clerk tapped arrive on their own account. The system recorded the arriver as not the driver, and the time as after papers matched. Score that time and you penalize the clerk's hand speed, not the haul.
Day two he changed the sample: a driver two weeks in, and a cover who holds the phone left-handed. The new driver could not find the task from navigation and let the co-driver tap; the cover, used to the right hand, hit the neighbouring "depart". Those two failures are not the same event as the veteran's proxy tap. Follow only the veteran and the finding becomes "they can all use it". The user researcher writes the three people's pauses separately. He does not fold them into one poor-experience sentence.
He did not ask for "a bigger button". He wrote: the action happens on the dock, not in the cab; a proxy tap pollutes who is responsible; paper is still the basis both sides hand over on. That is observation, not a design. The product manager decides whether to change it. The next ride-along checks only two things: is there still a proxy tap, and is the recorded person the driver. If the proxy tap is still there, the task is still not in the person's hand. This page does not watch how receiving posts to the books. That is a document exception. It goes to the business analyst.