From Human-Computer Interaction to Product Design: 4 Lessons From Doing User Research
“You’re almost always there. There are two ways of knowing. Learn from the past & design for the future. The user of the research is the user.”
I was a Human-Computer Interaction (HCI) researcher at CUTE Center since 2014. I joined the team to design AR/VR for early education. I designed and tested educational games for students and teachers.
After three interesting years, I found myself yearning for a new experience. And so I joined ReferralCandy in 2017 as a freshly-minted product designer.
Product design is a deep and wide field. I was excited to work on creating something I’ve never tried before. At the same time, I was scared of all the terms and words I wasn’t familiar with, and people asking me questions that took me awhile to decipher. The process was of course very different too.
I told myself that I would slowly but eventually connect the dots.
The first place where that happened was in user research. I thought getting to know users can’t be that different, no matter the domain. So I learnt to look for the connecting points from the past experience.
My first lesson: You’re always ‘almost there’ — so learn to operate with incomplete pictures
The reality is fleeting. No research allows you to understand exactly how your users are like, but good research lets you get as close to the truth you can get.
HCI research inherited a tradition from the natural sciences — the quest to discover general rules that predict how humans behave. Unfortunately, the users, being human, break all the rules as soon as they are conceived. The HCI researcher then again comes up another rule to catch up with the users. Some researchers, tired of the chase, suggest that we should start with stories about the users first and let the general rules emerge whenever they are ready.
Product design research, as practiced at ReferralCandy, is more akin to the latter type of HCI research, but dive even deeper into specifics. The product designer looks at problems that are specific to a certain type of users.
Sometimes, the solutions derived are specific to the team configuration. Each project team holds a fragment of knowledge about the users, then come together to form a shared but still-incomplete picture about the users. As soon as we know enough to act, we will disperse to take the next action.
As a takeaway, I’ve learnt that any insight could be challenged in the (near) future. You only need to find out as much as you need then act on it, before continuing digging.
Lesson #2: There are 2 ways of knowing, and you need to balance both in order to get a useful picture
Modern HCI and product research has come up with plenty of research techniques.
Although they come in different names, I’ve found that most techniques can be mapped under two umbrellas: listening and observing.
Balancing these two ways of knowing gives a well-rounded understanding of the users, whether in HCI research or product design research.
Listening to what the users have to say reveals their real motivation and intention.
I once designed a simple checklist and was puzzled by how many users intentionally miss the last huge, actionable button that will help them to progress.
Talking to just one or two users via support chat made me realize immediately: The users don’t just want to progress. They want to be assured that the product will work as expected.
In HCI research, the user’s self-report is multidimensional.
I’ve had the luxury of having in-depth, uninterrupted conversations with the users. A survey on the user’s attitude could also be broken down into numerous sub-components. We usually collected as much data as we could on the topic, then pieced out different parts to answer more than one question.
The luxury of the user’s time is not guaranteed in product design research.
Each conversation request to the user needs to work like a pitch and clearly tell the user “what is it in for me?” As a result, most of my conversations with the users happens as a part of a support conversation, where I first engage them with what they need. It can be anything from “help me set this up” to “show me how to sell more”. Then I decide what I want to know most and how to spend the short 10-15 minutes wisely.
Conversations with the users are rich and vivid. They’re also coloured with the user’s subjective perception.
I’ve talked to students and teachers who were super excited about using AR games for classroom learning. Without peering through the excitement to identify their real needs, the use of these new tech games could easily be phased out in months.
Similarly, users may feel negatively about a commercial SaaS product, despite the fact that it generates new sales and has a good ROI.
As the users can’t always articulate their problems objectively, it’s important to observe the users’ behaviour to cross-check with what they say.
In the SaaS product example, it turned out that fixing error messages and improving the feedback system might just do the job. Instead of having more features, the users might simply need to know that the product is working as expected. Noticing the user’s frustration with a particular part of the product can help to pinpoint the root of a problem.
There are many types of user observations — from more scripted methods such as structured usability testing to naturalistic ones such as shadowing and session playback. The former is less organic, but it helps to focus the findings and reduces noise.
Qualitative and quantitative usability testing (or experimental studies) is the most popular method in HCI research. In product design, it is equally valuable. Even with a small sample size, it becomes clear with usability testing what is working in the product and what is not.
I find that the challenge of usability testing in product design is mainly about acting on the insights.
A validation test may show that the main flow the project team has worked on for a month is not the one. Sometimes it can be challenging to explain the perspective shift to someone who was not in the session. In our product team, having non-designers attends early testing sessions usually goes a long way.
Lesson #3: Learn from the past and design for the future — it seems like extra effort, but it’ll save you time
Reviewing past works is a compulsory step in any academic work like HCI research. The HCI field, especially, gears towards novelty and favours completely new, exploratory inventions.
In the fast-moving product design space, documentation of past insights and decisions is sometimes de-emphasized for speed. Yet I’ve learnt that overlooking past insights may actually slow down the process. It will take more iterations to discover what another designer has done before.
Here’s an example to illustrate. Our users used to have a hard time wrapping their head around one of our features. The feature has gone through at least 7 iterations of redesign and renaming. I proposed to rename it to “Your Theme”. Another designer, acting as the lived document, let me know that we’d already tried that and failed before. We saved that time and used it on another experiment instead.
An academic work needs to outline how future works can build on its findings. Similarly, I’ve found that useful product insights are those that are future-ready. They provide a guideline that is open to new understanding in the future, in addition to solving the immediate problems at hand.
Lesson #4: The user of research is the user — so always keep them in mind
While the audience of HCI research insights may be different, the end-user of design research is always the users.
A HCI study may need to check all the boxes for academic rigour and a product insight deck may need to appeal to the resource-sensitive manager, CEO or client. Still, it should not lose sight of the users.
What works for me sometimes when I am stuck is to ask myself: Will the users be nodding their heads in agreement upon hearing my findings?
To others diving into new environments: It’s gonna be alright!
Moving from HCI to product design, these are the common threads I found in user research, that helped me to navigate in a new territory.
When did you last make the jump to a new, uncharted territory? I’d love to hear your stories!
