Learnings from my first year as a UX researcher
Just 2 years ago I was mugging through my final year of college, ready to pursue a career in psychology, with no knowledge that UX/UI even existed. Life really finds a way to surprise you, because here I am celebrating my first anniversary of officially being a UX researcher! 🥳
To commemorate this milestone and reflect on my annual performance feedback, I wanted to pen down my learnings, to solidify them and ensure I don’t forget. So, here are some of my key takeaways from the past year:
#Lesson 1: Chesterton’s Fence
Chesterton’s fence is a concept by writer and philosopher G.K Chesterton that essentially states that if a fence exists, there’s likely a reason for it, even if it’s not apparent.
The exact quote goes like this:
“There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”
Chesterton’s fence has been most applicable when it comes to removing or simplifying product features. I’m often quick to conclude that we should remove features because it seems redundant. But I’ve been disproven countless times, because there’s often an underlying reason for why it was built in the first place, and removing it could’ve led to unforeseen consequences.
Additionally, as someone who is direct and who tends to hold strong opinions about products and processes, Chesterton’s fence has been a valuable learning for my communication style. It’s something I’m still working on, but spending the time to understand the history of a feature has been helpful for me to build empathy, and enabled me to give more sensitive and constructive feedback when proposing changes.
#Lesson 2: Users don’t know what they want until they see it
I first realised this a few months back when a friend asked for my thoughts on incorporating gamification in a budgeting app she was designing. I was initially opposed, because gamification seemed unsuitable for a serious matter like finances, and it could add unnecessary complexity. However, I ended up changing my mind when I saw her wireframes. Her app’s concept was super cute: Grow your money just as you would grow a plant.
My first thought when I saw her designs was that it could be a good motivator if users could grow a virtual plant each time they hit a finance goal. And they could look back at it a year later and be proud of having grown an entire garden. Which ironically is the gamification I initially thought was a bad idea. In other words, I didn’t think it was a good idea until I saw it for myself.
The concept of users not knowing what they want until they see it, was first popularised by Apple’s cofounder Steve Jobs. He said:
“Some people say, “Give the customers what they want.” But that’s not my approach. Our job is to figure out what they’re going to want before they do. I think Henry Ford once said, “If I’d asked customers what they wanted, they would have told me, ‘A faster horse!’” People don’t know what they want until you show it to them. That’s why I never rely on market research. Our task is to read things that are not yet on the page.”
In short, this mostly happens because users don’t always have the ability to imagine and articulate the most desirable solution before it exists.
While this is so, it doesn’t mean that we shouldn’t listen to users because they don’t know what they are saying. Ultimately, research is still necessary to gain an accurate understanding of the problem space. But when ideating we evaluate user suggestions critically, and explore ideas beyond their expectations, instead of limiting ourselves to what users said they wanted.
#Lesson 3: A great idea is only great if it’s executed well
When uncovering user pain points, occasionally the solutions to address them are readily (and obviously) apparent.
In one of our previous studies on new launch (NL) property buyers, we found that discovery of NLs was painfully fragmented, because there wasn’t any platform that consolidated all NLs into one place for easy browsing. Instead, discovery was occurring by chance if an ad pops up on their social media feed, or if they happen to hear about it from friends.
The obvious solution, which many users also suggested is to consolidate all the new launches out there into a comprehensive list for browsing. However while the idea was good, the execution fell short. During testing, we found that even though users liked the list we created, they all felt that a table format was information heavy and overwhelming to look at. They preferred a grid view (which we ended up implementing, here), which was more visually relieving on the eyes.
Users always find a way to surprise you, because this is just one of many incidents where we thought a solution was good and almost shipped it out until user feedback came in. So this is an important reminder that even an obvious solution can fall short if the execution is not carefully considered and tested. Always test as much as possible before implementation!
#Lesson 4: Triangulation of data is key
One of the most common feedback from stakeholders is that qualitative UXR insights cannot be trusted because sample sizes are too small. Especially because I work at a start-up, I don’t have the luxury of time to conduct big qualitative studies with a good sample size. And it’s extra frustrating because the stakeholders are right. Qualitative conclusions can only be taken sceptically because they cannot be statistically proven. Which is why triangulation of data is so important.
Triangulation is the practice of using multiple sources of data to verify your findings.
With triangulation, you can check if qualitative findings are credible, by seeing if the same finding is replicated in another data source (e.g. heatmaps/ analytics data).
Triangulation is also important for quantitative data, because it doesn’t tell you the whys. For instance, we may be able to see from analytics that users aren’t using the search bar even though it’s the centre stage of the screen. However, without the qualitative understanding of the reasons behind this behaviour, we wouldn’t know what next steps to take. It is possible that users on that page are in browsing mode, so they don’t know what to search for specifically. In this case, listing recommendations may be more appropriate, over a search bar.
#Lesson 5: You don’t have to do all the research in the team
The last learning I have is more personal rather than technical. Something I did a lot in the past year was to try to involve myself in as many (if not all) research projects as possible. I felt the need to gatekeep research related activities in the organisation, because afterall, this is supposed to be my specialty. If product designers can also do the research, then what is my role here for? It made my question what exactly do UX researchers (UXRs) do that contributes beyond what the UX designers (UXDs) could do.
After much self doubt and pondering, I’ve come to understand a few key ways the UXR role value-adds and differentiates themselves from the rest of the team:
- UXRs tend to conduct strategic research (exploratory; identifies opportunities and behaviours in the broader journey), whereas UXDs conduct tactical research (design-focused; to assess designs and help with design decisions)
- UXRs work on all verticals of a product, whereas UXDs tend to focus on a specific aspect. E.g. in a marketplace, UXRs would do research on both seller and buyers, whereas a UXD may only focus on designing for sellers.
- Because UXRs work across all verticals of the product, we can consolidate findings and provide more holistic recommendations that account for the product as a whole.
- UXRs may also occasionally conduct market research, to develop a broader understanding of the market and the competitor landscape.
- Lastly and importantly, UXRs are there to ensure scientific rigour of research within the organisation (as much as practicality allows), so that decisions are guided by accurate insights.
Looking back, trying to be on every research project spreads you out too thin, and sets you on a path to eventual burnout. So yes, I’ve come to appreciate that everyone can contribute to the research process. In fact, some of the UXDs I’ve worked with have exceptional research skills and I regard them as UXRs in their own right. And while this is so, it doesn’t diminish the importance of UXRs to the team.
Final thoughts
I wanted to end this reflection with an observation I made over the past year, which is that interns often possess a spark of optimism and passion that many full-timers don’t have. Of course, its totally understandable that the daily grind of work can result in disillusionment over time. Which is precisely why I wanted to write about this, as a note-to-self to upkeep that same level of enthusiasm and drive that I am feeling now in the first year of my career.
Overall, all the learnings here are a work-in-progress, and i’m still trying to conquer them! The past year has been a valuable experience I couldn’t have gotten without my supportive team members (shoutout to the 99.co design team). Looking forward to yet another new year of growth, challenges and opportunities that lie ahead 🥂.
