@alecuffia Unsplash

One of the most powerful ways of gathering genuine insights on your product is by talking to users. Its not everyday that you (a designer working on products) get to meet your end users in their own environment. And when you do, you should make the most of it .

From my past experience @ Adobe of conducting customer for enterprise , following is a quick checklist I’ve put together that might help you get ready for your upcoming study.

Identify

  • Are you visiting the right set of users? Make sure you have done enough screening (using product usage data, vetting it out with Customer Success Partners (CSPs) etc.) to ensure the goals of your study resonate with the success of your users.
  • Pulling out analytics (product usage) data for these identified customers will really help you get clarity on what parts/features/workflows are they using the most and otherwise. For example: looking at percentage of customers interacting with critical feature or pages will help you understand who is using what, visits/clicks on info icons/popovers and customer support pages will help you identify a confusing feature/workflow etc.
  • CSPs are customer stakeholders who are responsible for selling, distributing or supporting your product. Often they are known as the Customer Experience Partners or Technical Support Consultants. Reach out to them and learn about your customer’s history of asks, successes, failures with the product and their usage patterns. I cant recommend this enough as, CSPs are closest to your customers and are in the best position to provide you with a thorough context (and sometimes help you with scheduling these visits too).

Communicate

  • Have you communicated to your audience about your planned visit and explained them about your intent and what is expected of them? It’s always easier when everyone in the room is on the same page prior to the start of the study and are prepared to deliver from the beginning.
  • Clearly highlight your asks (like a conference room, with or without A/V equipment, stationery supplies, etc. which can be difficult to arrange on the fly), the time duration of visit and introducing your team and intent of your visit.
  • If you need to shadow users in their own environments/at their desks, state this ask clearly with reasons. Shadowing your users will help you understand them holistically by observing their body language, mood patterns, latent motivations and usage patterns. Don’t forget to follow up with a confirmation email a couple of days before the day of study.
  • Step 0 towards respecting our users privacy (like GDPR) is asking them for permission before clicking pictures, videos, or gathering of other personal data for research and debriefing purposes.

Re-group

  • Have you decided who does what among your team? Its essential to assign duties to fellow members of your team for the study. Typically you would require a minimum of 2 and a maximum of 3 member team: a facilitator, a note-taker and sometimes a listener. Having a listener means you can get different perspectives for note comparisons and are less likely to miss out on anything. The extra member can also help the team out with clicking photos and recording whenever necessary.
  • Too many people in a room can be overwhelming for users and should be avoided*. You may reserve 5 minutes at the end of the session for observer questions if any.

*It is always beneficial to include other stakeholders from the Engineering/QA/PM team (who otherwise don’t get to meet the users) and give them an opportunity to listen to the user feedback. This will not only make them empathise more with the users but also make them understand the design process at large.

Be Prepared

  • Make sure you have a clear purpose of visit shared across the room. A script will help you set the right expectations, prime your audience and bring back the conversation in case it deviates during the course of the study. This is vital in building trust and making the process transparent for all stakeholders.
  • Ensure that you have all appropriate forms (NDAs explaining how recordings/data will be used etc.) that your users can sign to indicate their acceptance.
  • Consider this script as a mere guide. Its OK to skip a few questions and deviate a bit.
  • Online collaboration tools like a wiki can help you manage and collaborate efficiently.

“A strict line of questioning can sometimes prevent that organic discovery of pain points, delight or other insights.” — Nick Brown, Experience Researcher, Adobe

Example of a working document of a script from one our past customer visits for Adobe Target.

Note-taking & Analysis

  • Are there multiple people taking notes? This would make sure you don’t miss out on any important observation and can compare notes to get multiple perspectives.
  • Its essential to take detailed notes during the study. Do not write incomplete notes in the form of keywords to fill in the blanks after the study. Most often, you will forget the small but important details.
  • Personally I like to use pen and paper instead of a laptop. Looking down into a laptop while talking to users will make you miss out on their facial expressions and will create a barrier.
  • After the study, it would really help if all the note-takers (and observers) can collaboratively de-brief and synthesise all the notes digitally at one place. Deciding on the format of documentation (or organising them into insights/observations/themes etc.) will make its consumption easier.
  • Avoid paraphrasing user feedback. Care should be taken to ensure you do not introduce your own biases in your observations.
  • Make it anonymous. Refrain from using names while documenting user feedback, instead use job roles like marketer, creative etc.
Cheryl Chang of Adobe Target’s design team consolidated the feedback around wins, pain points and generated an “ExperienceMeter” graph based on the emotional experience ratings from one of the studies.

Share & Reflect

  • Its imperative to share the results/findings from the study with other stakeholders on your team. Remember that not everybody in your team gets access to real users.
  • Use this opportunity to bring everyone back at office on the same page with key insights from the notes. Figure out what went wrong and identify what you still need to learn. Publish the results publicly within the reach of the team. Sharing core findings with your team will help all stakeholders build consensus and collectively form a plan of action.
  • Do not use these findings to stereotype your users unless you have data from enough such studies. If you intend to do only a couple of studies, take the results with a grain of salt. Although, there’s no single correct number, I have witnessed data saturation point (repetitive insights) at an average of 8–10 similar persona users for my enterprise studies. The key is to look out for repetitive patterns in findings and stop probing any deeper.

Follow Up

  • Have you followed up with your customers and thanked them for their time? Its always nice to thank your customers for their time and effort through an email. Highlight next steps if any.
  • Try to hand out gift cards/rewards/renumeration soon after your study as a token of appreciation.
A Follow-up email to one of our customer visits.

Did I miss out anything or have anything to add? Would LOVE to read your thoughts/views (in comments) and learn from your experience. Thanks for reading!

I’d like to give a special shout out to my team-mates @ the Adobe Target’s design team who made these studies possible (Ankur Jhawar, Ben Brucker, Nick Brown, Lili Lin, Cheryl Chang and Ekta Agarwal).

Thank you Andy Welfe and Bailey Sharrocks for reviewing this article and all the valuable feedback. 🙏

https://medium.com/media/a19f46680bac3cbdc42953c920d0c104/href


Tips and tricks to successful UX visits for large enterprise customers was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.



Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here