{"id":4300,"date":"2019-12-18T12:11:39","date_gmt":"2019-12-18T17:11:39","guid":{"rendered":"https:\/\/blog.mozilla.org\/ux\/?p=4300"},"modified":"2019-12-18T12:42:09","modified_gmt":"2019-12-18T17:42:09","slug":"reflecting-on-its-our-research-at-mozilla","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/ux\/2019\/12\/reflecting-on-its-our-research-at-mozilla\/","title":{"rendered":"Reflecting on “It’s Our Research” at Mozilla"},"content":{"rendered":"

I thought we involved stakeholders in research pretty perfectly, here at Mozilla. Stakeholders come to research studies, listen attentively to research report-outs, and generally value the work our team does. Then I read \u201cIt\u2019s Our Research\u201d<\/a>. I still think the Firefox User Research team has great buy-in across the organization, but after reading Tomer Sharon\u2019s book, there are so many more things we could improve on! And what fun is a job, if there\u2019s nothing to improve, right?<\/p>\n

I\u2019d like to call in some stakeholders to help me tell four short stories related to four pieces of advice Tomer Sharon provides in his book. (By the way, there are so many ideas in that book, it was hard to pick just four.)<\/p>\n

This post is authored by <\/em>Jennifer Davidson<\/em><\/a>, with contributions from <\/em>Julia Starkov,<\/em><\/a> Jim Thomas,<\/em><\/a> Marissa (Reese) Wood<\/a>, and <\/em>Michael Verdi<\/em><\/p>\n

Let\u2019s start with the \u201cfailures\u201d. Failure is a big word, but they\u2019re really two examples where I could\u2019ve done better, as a user researcher.<\/p>\n

 <\/p>\n

<\/h2>\n

Never skip a field debriefing<\/b><\/h2>\n
\"An

An artistic bridge in Salem, Oregon with a clear blue sky. The weather was just too nice to debrief.<\/p><\/div>\n

Tomer Sharon recommends that we never skip a debrief. A debrief includes those precious moments immediately after interviewing a participant or visiting a participants\u2019 home. They capture your first reactions after the experience. Sharon details that they\u2019re important because it helps prepare for analysis, and helps stakeholders remember the sessions. On the Firefox UX team, we have a great debrief culture. We reserve time after interviews, even if they\u2019re remote interviews to capture initial thoughts. This practice is more formal when we do field research — where we not only have an individual debrief form that we fill out immediately after each visit, but we also do group debriefs together after each interview to talk together about what we observed. I would say we always<\/i> do debriefs after every interview or session with our users, but then I\u2019d be lying. Let\u2019s have Julia Starkov, a Mozilla IT UX designer talk about her experience when we skipped a debrief in the field.<\/p>\n

The time we skipped a debrief, as told by Julia:\u00a0<\/i><\/p>\n

We wrapped up our Salem user research on a Friday afternoon; we were staying in different cities and some of us had plans right after the interview. We were also parked outside of the participant\u2019s house so we decided to skip the group debrief and get the weekend started. While this felt like a huge relief at the time, I regret not pushing for us to meet at a cafe and wrap up the research together. By the time the weekend came and went, and I flew back to California, it was hard to recall specific parts of that interview<\/b>, but mainly, I felt we could have definitely benefited from starting synthesis right away as a group. Overall, I thought the research effort was a total success, but I feel like I would have retained more insights and memories from the experience with a bit more team-time at the end.<\/p><\/blockquote>\n

 <\/p>\n

Always include an executive summary<\/b><\/h2>\n

An executive summary is a few sentences, maybe one slide (if it\u2019s in slide format) that summarizes a research study. I\u2019ll tell you — it is the hardest part of a research study. Let\u2019s have Marissa (Reese) Wood, Firefox VP of Product, explain the importance of an executive summary.<\/p>\n

The importance of an executive summary, as explained by Reese:<\/i><\/p>\n

The purpose of an executive summary is to describe the main and important points of your document in such a way that it will engage the readers. The intent is to have them want to learn more and continue to read the document. This is important because the reader will pay greater attention to detail and read the doc all the way through if they are engaged.\u00a0 In short, without a good executive summary, the document will likely not get the attention it deserves.<\/p><\/blockquote>\n

Reese puts it nicely, but I\u2019ll reiterate, without an executive summary, people may not pay any attention to the study results (a researcher\u2019s worst nightmare!). So over the past year, the Firefox UR team has been iterating on our executive summary style, to better fit the needs of our current executives. We try to be more succinct with our executive summaries than before, with clear takeaways and calls to action for each report.<\/p>\n

Now let\u2019s move on to talk about a couple of successes.<\/p>\n

<\/h2>\n

<\/h2>\n

Make it easy to participate<\/b><\/h2>\n

 <\/p>\n

\"A

A picnic table overlooking the Puget Sound, with a coffee, a packet, and post-it notes on it. We took our research packets everywhere that week. Also, it’s never too nice to debrief.<\/p><\/div>\n

Be prepared — not only with great research practices like doing a pilot (a practice research session before doing the rest of the study, to work out the kinks in a research protocol) — but also, by making it easy for stakeholders to participate. This means that the researcher, or a supportive operations manager, needs to do some administrative tasks. When you have stakeholders come with you on home visits, get them the materials they need to take notes or photos. With every field research trip I do, I find little tweaks I can make to improve the stakeholder experience. Earlier this year, I took a little extra planning time, and with a great example from other team members (particularly, Gemma<\/a>!), created a packet in a waterproof (that\u2019s important if you\u2019re doing research in the rainy Pacific Northwest like we were) document folder for each stakeholder. It felt like making personalized goodie bags for a birthday party. The packet contained everything they needed to participate: pen, sharpie, note-taking guide, photograph shot list, post-its, a legal pad, and a label with their name on the packet. And Jim Thomas, Firefox Product Manager, will talk about his experience participating in field research.<\/p>\n

 <\/p>\n

The time I participated in field research, as told by Jim:<\/i><\/p>\n

As a Product Manager, I know how important it is to spend time connecting with your users, learning how they think about your product, observing what they do and how they react. I’ve done this informally throughout my career, but formal field research seemed like it would involve a lot more rigor. In fact, it was even more rigorous, but it didn’t feel like it thanks to the prep work put in by the team. Every session had our roles and responsibilities planned ahead of time, with relevant materials in a convenient package. Debriefing after each session was simple even at restaurants or picnic tables because everything we needed was at our fingertips. All the process was handled for me so I was able to focus on my most important goal: learning about our users and their perspectives.<\/p><\/blockquote>\n

 <\/p>\n

Analyze together<\/b><\/h2>\n

 <\/p>\n

\"Sticky

Lots of sticky notes about how people learn to use new software and apps that the team pulled together. This was one of four walls that were covered in sticky notes by the end of the analysis.<\/p><\/div>\n

Sharon recommends analyzing results together with stakeholders. He mentions that ideal outcomes from analyzing together are:<\/p>\n