When UX designers start working on a new feature for a product or rethinking an existing one, they don’t typically conduct thorough UX research to understand users’ needs for every screen and user-interface element. When product managers prioritize their backlog and turn it into a roadmap, they often don’t have a full understanding of all the options that are on the table or exactly how they would impact users. Product managers need to make guesses, and the more informed their guesses are, the fewer the iterations that their teams must go through to ship a great product.
As a user researcher, I’d prefer to provide product managers with complete data about each and every design issue, but I don’t usually have enough time to do that. So what can I do? I can build a reliable feedback loop by accumulating knowledge about our customers and their users and gathering it into an atomic research base. However, there still are some things that can go wrong.
Champion Advertisement
Continue Reading…
What Can Go Wrong?
Just building a good feedback loop doesn’t usually cover 100% of users’ problems. Some things that can go wrong include the following:
complaint bias—People don’t usually contact us about the things they like, so we don’t store much positive feedback. Therefore, even though we might think a part of a product isn’t working optimally, on the basis of several instances of feedback in our database, changing it might actually harm the many more people who have remained silent about it. In fact, many business-to-business (B2B) customers who rely on a number of software solutions to be successful might become accustomed to the way a product behaves now and build their internal processes accordingly. Therefore, if we were to change something crucial, they would have to reconstruct their processes.
slipping under the radar—Even if a company has a diligent, careful Customer Success or Customer Support team, it still takes lots of effort to spot a problem, understand the nature of the problem, and decide to report the problem, then actually report it. Some minor issues might go unnoticed, while others might be underreported because those using the product were less eager to contact support representatives. Still other problems might be ignored because the Customer Support managers have found a plausible workaround and have suggested that all customers use it.
insufficient persuasiveness—You could accumulate a dozen reports of convincing feedback from your customers and users, then build a great dashboard to convey them to your team, but your product manager might still decide to ship something that he heard a single customer needed during one call. However, hearing about a user’s personal painpoints can have colossal impacts on the product manager’s priorities, effectively acting on several biases at once.
Even though a feedback loop that has captured most of your users’ problems, it is still sometimes less powerful than having a single talk with a customer. So what do we do?
Building User Empathy Across Product Management and UX Design Through Ethnography
To solve this problem, we need to build empathy with users across our Product Management and UX Design teams. Then, when they’re prioritizing features or creating design prototypes, they can try on the users’ hats, which lets them do what they need to do in a more informed manner.
I know no better way of building deep empathy with users than observing their real-life experiences with your product, so ethnography comes to the rescue!
Some product managers and UX professionals view ethnography as a method that is suited solely to UX research that occurs at the very beginning of a product-development lifecycle, when they’re trying to understand the product’s market fit. I disagree. In fact, ethnography is useful for building empathy with users at any time. Ethnography enables you to build mental models of your users. Then you can consult these models when you’re making many decisions, large and small, and save countless time on design iterations and hot fixes.
If you’re working on a business-to-consumer (B2C) product, it’s not usually difficult to just find some users and talk with them. For example, I used to conduct research for K–12 EdTech (Education Technology) solutions and had great time visiting schools. I could sit somewhere at the back of the classroom during lessons and observe students use of our products in their everyday school life. I took UX designers, learning-experience designers, product managers, and front-end engineers with me, and we got many ideas and insights from our observations.
Some Alternatives to Ethnography for B2B Products
But what if you’re working on a B2B product, and it’s not as easy to observe your users in their natural habitat? We employ several different methods that at Juro, working with in-house lawyers who are not happy about external people messing around behind their back. Some of these methods include the following:
watching replays of user sessions—Although you can’t be sure what people were trying to do or what their plan was, you can guess. This is one of the easiest, yet most effective ways of witnessing firsthand how users behave when using your product. I’ve seen hours of footage of incredibly painful problems for enormous use cases that nobody has reported before. In some cases, we were able to build and launch solutions in just a few days after such viewing sessions, mirroring the intensity of the empathy that we acquired during those sessions.
watching sales demos—Of course, there are some demos that are easy and straightforward and others during which customers talk a lot, ask hard questions, and describe their unusual internal structures and use cases. Aim for the latter. Such demos are more like user interviews during which you can’t ask questions. However, due to our salespeople’s recommendations, we can broaden the scope of our understanding without spending countless hours digging for information.
participating in Customer Success’s end-user training—Another point of contact with customers when they tend to ask questions and might misunderstand some things is during end-user training sessions. They’re a perfect place to hear customers out, learn what they want, and observe how they react, then make changes to the product accordingly.
actually messing around behind our lawyers’ backs—However, none of the methods I’ve already described provides enough context to give you a holistic understanding of a lawyer’s life. Fortunately, we have a great lawyer of our own, so we can actually mess around behind his back.
In Conclusion
Although this is not a full list of practices that might help build some user empathy among the members of the Product Management and UX Design teams, this is the list of those that we’ve chosen for ourselves at Juro.
In my opinion, our approach works better than just creating several user personas or jobs stories, which remain external constructs that might be hard to internalize and act upon. The information those deliverables could provide would also be quite limited, albeit still a lot for readers to process, and would require constant renewal efforts. That’s why we’ve chosen to build user empathy rather than create artifacts—even though ours is a much less structured and predictable process.
Aleksander leads user research at Juro, the creator of an all-in-one, contract-automation platform for fast-growing businesses that helps visionary legal counsel and their clients to agree on and manage contracts using a single unified workspace. He has created a workflow for assembling product feedback and supporting evidence-based decision making. He has previously held a variety of senior user research roles. Aleksander studied psychology at Lomonosov Moscow State University and was a PhD student in the Russian-British Behavioral Genetics Lab, at the Psychological Institute of the Russian Academy of Education. He delivers university lectures on UX research methodology. Read More
