Project Log: Looking for User Needs Before the Interview Room
This week was mostly research before research.
That sounds a little odd, but it is probably the most accurate way to describe it. Before a formal interview starts, there is already a lot of work happening: deciding what to look for, checking what users have already said in public, turning scattered complaints into themes, and making sure the actual interview does not waste the participant’s time.
One of my main tasks was collecting public user feedback around glasses based drone control. I went through different social platforms and forums, looking for comments about what people liked, what felt awkward, and what they still wanted from the experience. I cannot share the internal document or product details, so I will keep this at the method level.
Online feedback is useful, but it is also noisy.
A user might write one angry sentence after a bad setup experience. Another user might praise the same feature because it worked perfectly in their specific situation. Some posts are emotional. Some are vague. Some are probably written after the person has already forgotten the exact steps that caused the problem.
Still, patterns start to appear if you read enough of it. People care about comfort, setup friction, clarity of status, and whether the system behaves in a way they can predict. They also care about small transitions: connecting, switching modes, recovering from confusion, finding media, understanding what the device is doing.
Those transition moments are easy to overlook in a feature list. They are harder to ignore when users keep complaining about them in public.
I also helped coordinate another round of demo interviews for an experimental interaction direction. The actual mechanism is under NDA, but the work around the interview is safe to talk about: scheduling, preparing the flow, checking the task order, handling time changes, and making sure the participant can focus on the experience instead of the logistics.
I used to think of interview coordination as admin. Some of it is admin, obviously. Calendar work is calendar work. But this week made me treat it more seriously. If the participant arrives confused, rushed, or unclear about what they are being asked to do, the data gets weaker before the interview even begins.
A bad setup can create bad feedback.
There was also some quick reading around HCI experiment methods, interviews, and questionnaires. I needed to understand the difference between collecting opinions, observing behaviour, and designing a small test that produces usable evidence. These methods sound similar when described casually, but they answer different questions.
An interview is good for understanding how someone explains an experience. A questionnaire can scale a narrower question. An experiment needs more control, but it can show behaviour more clearly if the setup is designed well. Mixing those up is a good way to get confident-looking data that does not actually support the decision.
I also spent some time thinking about my own AI workflow setup, especially how skills and plugins should be organised. That is a more personal tooling layer, but it connects to the same issue: tools only help when the boundaries are clear. A messy toolchain just creates another place to lose time.
The thread running through the week was preparation.
Preparing a public feedback scan so it is more than a pile of screenshots.
Preparing an interview so the user can actually respond to the experience.
Preparing a method so the team knows what kind of evidence it is collecting.
It is not the most visible part of product work, but it changes the quality of everything after it. The research starts before the recorder is on.
Leave a Reply