10 Ways UX Research Is Changing

How is UX Research evolving with the times, especially given approaches like LeanUX that favor fewer handoffs, more participation, and more experimentation?

It is Sunday, and the listicle (and doodle) instinct is strong ….

See #1, #2, and #4 below …
  1. Pull based, just-in-time research. Spending weeks and months accumulating research is an accident waiting to happen. The environment is constantly changing. The danger of accumulating research inventory is that it is constantly depreciating. A small change in direction can render it stale and useless. Yes research takes time, but it is best to start at the last responsible moment. The ultimate just-in-time approach is to resist trying to “get ahead” of the work altogether and wait until there is capacity and time to start alongside the team. 80% of the value can be delivered quickly, and you’ll have 100% of the current context. What you find in many companies is a strange sort of neurotic design team driven shotgun research approach. They’re terrified they’ll get caught on the back foot or blow their “seat at the table”, so they undertake all sorts of pre-emptive research that fails to ever synchronize effectively with front-line teams.
  2. Research is validated continuously. Is the research informing actual product decisions? I’m not talking assumptions — like putting one thing earlier/later in a roadmap, an ooh-ahh session for a two-year mobile plan, or a slicker kick-off deck — I’m talking about actual decisions on what was designed, built, and validated (customer-delivered value). Did your research findings hold water when validated out in the real world, with real data, and real customers? It’s ironic that to support Agile product development teams, UX Research is frequently asked to work in a waterfall model. Don’t delay validating your work. Which brings us to …
  3. Less linear product development process. Look at any antiquated graphic of the product development process and you’ll see a big block for Design Research. That block exists TO THE LEFT of when developers start to write code. UX Research for modern software products is still heavily entrenched in practices that fit more appropriately with hard-goods, and agency-orchestrated product development. Learning is happening all of the time, and UX Research will always be pivotal in the learning process. We’re moving from project-based research to continuous learning.
  4. Less research in a vacuum. Take teams along for your learning journey and invite them to participate in activities. Share findings frequently and incorporate feedback. Regularly “synchronize” and reality check your progress. Build empathy by connecting teams directly with customers instead of presenting your findings as reports or briefs. In this model you play the expert, guide, and fellow learner.
  5. Facilitation. To support #4, you’ll need to become skilled at facilitating various activities with cross-functional teams. Most researchers I know are extremely good at relating to people. But they can be severely challenged when it comes to working with engineers and internal teams. It is easy to become beholden to your research, and approach the work from the standpoint of a missionary vs. a guide and coach. Study up on facilitation skills. Get to know the developer and product manager mindsets …
  6. Lightweight presentations. Since teams are involved directly in the research, it is less common to be producing slick presentations. It used to be that you’d find yourself in the spotlight rarely (and the research was a many month effort), so you needed to make it count. The goal is to communicate learnings, and since the learnings spend less time in “inventory” (see #2 above), there are fewer learnings to communicate in any single shot. Succinctly answer the questions that matter now. Less fluff.
  7. Using both quantitative and qualitative data. Teams expect researchers to use all of the data at their disposal, and these days (if you’re lucky) you’ll have access to a significant amount of quantitative data. What do your users actually do in your product? How do they navigate in the real world? What key features differentiate the population you’re studying? How can we augment personas (or jobs-to-be-done profiles) with actual data? What predicts low/high NPS? Are these really the “top tasks”? Gone are the days when the most a researcher would graph/analyze were the results of a five person usability test. I’d venture to say that the qualitative vs. quantitative schism is a non-issue. The two feed seamlessly into each other. To tell a good story and engage teams you need both.
  8. Experiment Design. As a researcher, your job isn’t relegated to pre-work, benchmarking, reviewing historical data for insights, and making a take-it-or-leave-it recommendation. You’ll be frequently involved in a dynamic work in progress, A/B tests, triaging feedback from newly released experiments, and validating your own research assumptions in real-time. Experiment-design becomes part of the tool chest. This doesn’t mean that everything needs to be a rigorous, by the book, ready for a scientific journal experiment, but you can’t waste the team’s time.
  9. A bigger research library to manage. With the large amount of data available, you’re going to build a big war chest of raw data, information, and insights/knowledge. Data is coming in from various sources, and you have to organize it and make it accessible. Sure you can leverage tools, but there’s still a role for the librarian … especially when the library is big.
  10. Evolving role of product managers. I’ve written about how product management is evolving, and the many overlaps these days in product development. This draws the UX Researcher into the fray. For one, UX becomes an embedded team member, so you have your people in the fray, and you must support them. There’s less of a buffer. But I’m increasingly seeing that product managers are coming around to respect the various techniques used by UX Research. I’ve heard PMs say things like “so THAT’s how you do an interview!” or “these methods are not in my skill set, but I’m finding them incredibly helpful!” There’s a growing respect and overlap.