Gemma Petriehttp://www.gemmapetrie.com
Wed, 10 Feb 2016 17:07:14 +0000en-UShourly1https://wordpress.org/?v=4.4.5Workshop: Using Interviews in Design Researchhttp://feedproxy.google.com/~r/GemmaPetrie/~3/AurtGz9HTUg/
http://www.gemmapetrie.com/2015/07/23/workshop-using-interviews-in-design-research/#respondThu, 23 Jul 2015 20:50:35 +0000http://www.gemmapetrie.com/?p=1058I was recently invited to the UIC Daley Library to speak to an awesome group of librarians that are using UX methods to learn about and improve their institutions. The workshop focused on my work at Mozilla, how to plan a research study, and best practices for user interviews. Activities throughout the day gave all the attendees hands-on experience scoping, drafting, and running a user interview. You can see my slides below and learn more about the Chicago Library UX group on their meetup page.

]]>http://www.gemmapetrie.com/2015/07/23/workshop-using-interviews-in-design-research/feed/0http://www.gemmapetrie.com/2015/07/23/workshop-using-interviews-in-design-research/chiDUXX Job Seeker & Speaker Directorieshttp://feedproxy.google.com/~r/GemmaPetrie/~3/Zhm0dOacyV8/
http://www.gemmapetrie.com/2015/04/17/1036/#respondFri, 17 Apr 2015 17:21:41 +0000http://www.gemmapetrie.com/?p=1036
A new resource from chiDUXX, a women’s networking and mentoring organization I help run in Chicago:

Have you ever wished for an easy way to find talented Chicago UX women looking for a job or interested in speaking at an event? Well, we have some exciting news! Starting today, we are launching two directories for Chicago UX women:

We encourage you to add your name and to spread the word. The directories are open to any Chicago women, not just chiDUXX members. Please note, any information you submit will be publicly viewable. You can update your information at any time by following the original survey link. Feel free to contact us if you have any questions: http://www.meetup.com/chiduxx/

]]>http://www.gemmapetrie.com/2015/04/17/1036/feed/0http://www.gemmapetrie.com/2015/04/17/1036/Everyday Multi-Device Task Continuityhttp://feedproxy.google.com/~r/GemmaPetrie/~3/ljSgSCG1RIY/
http://www.gemmapetrie.com/2015/04/16/everyday-multi-device-task-continuity/#respondThu, 16 Apr 2015 15:47:03 +0000http://www.gemmapetrie.com/?p=1034For many consumers, software and hardware choices are increasingly becoming choices between incompatible brand ecosystems. In today’s marketplace, a consumer’s smartphone choice is likely to have a far-reaching influence on options for everything from file storage to wearable technology. With each app purchase or third-party service sign-up, consumers become further invested in a closed brand ecosystem. As start-ups are acquired or privacy standards change, consumers may become trapped in an ecosystem that no longer meets their needs.

Mozilla strives to create competitive products and services built with open source technologies, that protect users from vendor lock-in, and that address user needs. We believe supporting these values is not only good for consumers, but is also good for our industry. In February, we conducted a contextual user research study on multi-device task continuity. This user research will help Mozilla design current and future products and services to support users’ behaviors and mental models. This research builds on our our Save, Share, Revisit study conducted earlier this year.

Research Questions

Tasks: What tasks require task continuity?

Patterns: What are common task continuity strategies, patterns, and work-arounds? Why do they occur?

Behaviors: What are current and emergent behaviors related to task continuity activities?

Devices: What constitutes a unified experience across devices? Do some devices perform specialized tasks?

Context: Given that previous research has focused primarily on work and productivity environments, what do home and work boundaries look like for task continuity? 1

Mental Models: What are the expectations, metaphors, and vocabularies in use for task continuity?

Tools: How effectively do current features and tools meet continuity needs? Why do challenges occur?

Methodology

The Mozilla User Research team conducted three weeks of fieldwork in four cities: Columbus, OH; Las Vegas, NV; Nashville, TN; Rochester, NY. We recruited a demographically diverse group of 16 participants. Each participant invited members of their household to participate in the research, giving us 43 total participants between the ages of 7 and 52. All 16 interviews took place in the participants’ homes. In addition to our primary research questions, the semi-structured interviews explored daily life, devices, and integration points. Further, participants provided home tours and engaged in multi-device workflow future thinking exercises.

Device Ecosystems

If you are reading this blog post, there is probably a good chance that you work in the tech or design industry. You likely have fairly advanced technology usage compared to the average person in the United States. Your personal device and service ecosystem might look something like this:

The device and service ecosystem for the average person in the United States includes fewer elements and fewer connection points. For example, here is the ecosystem map of one of the 16 participant groups in our study:

As you can see in these diagrams, the average user has single points of connection between his primary device (MacBook Pro) and all the other devices and services he uses. The advanced user, on the other hand, is utilizing various tools to move content between multiple devices, contexts, and services.

The Task Continuity Model

Based on our research, we developed a general model of what the task continuity process looks like for our participants. Task continuity is a behavior cycle with three distinct stages: Discover, Hold/Push, and Recover.

The Discover stage of the task continuity cycle includes tasks or content in an evaluative state. At this stage, the user decides whether or not to (actively or passively) do something with the content.

The Hold/Push stage of the cycle describes the task continuity-enabling action taken by the user. In this stage, users may:

Passively hold tasks/content (e.g. By leaving a tab open)

Actively hold tasks/content (e.g. By emailing it to themselves)

Push tasks/content to others by sharing it (e.g. Posting it on Facebook)

The user may also set a reminder to return to the task/content at this stage (e.g. Set an alarm to call the salon when they open). It is possible for a single action to bridge more than one Hold/Push state (e.g. Re-pinning content on Pinterest shares it with followers and saves it to a board). It is also possible that a user will take multiple actions on the same task/content (e.g. Emailing a news article to myself and a friend).

In the Recover stage of the task continuity cycle, the user is reminded of the task/content (e.g. By seeing an open tab) or recalls the task/content (e.g. Through contextual cues). Relying on memory was one of the most common recovery methods we observed. In order to fully recover the task/content, the user may need to perform additional actions like following a link or reconstructing an activity path.

Once the task/content is recovered, the user is able to continue the task in the Resume stage. Here, the user is able to complete the task or postpone it by re-entering the task continuity cycle.

The Task Continuity Model allows us to clearly map the steps involved in a specific task continuity activity. To illustrate, one of our participants discovered a video that he wanted to watch at a different time and on a different device. Here are the actions he performed to achieve this:

Discover: Finds URL for video he wants to watch later.

Push/Hold: Copies URL to email. Sends email reminder to himself.

Recover: That evening, while browsing on his iPad, recalls that he wanted to watch a video from earlier in the day.

Barriers: Participants choose a path of least resistance to complete a task. When confronted by a barrier, most participants will detour; sometimes those detours become a journey away from a product or service. Barriers we observed included authentication, forced organization, and overzealous privacy and security measures.

Further Research

This research provided a valuable foundation and framework for our understanding of task continuity, but it is important to acknowledge that it was conducted only in the United States. We were particularly surprised by the reliance on texting and screenshots and believe it is important to explore this behavior in areas where carrier-based SMS programs are less popular. We plan to build upon these findings by expanding this research program to Asia in May 2015.

]]>http://www.gemmapetrie.com/2015/04/16/everyday-multi-device-task-continuity/feed/0http://www.gemmapetrie.com/2015/04/16/everyday-multi-device-task-continuity/Save/Share/Revisithttp://feedproxy.google.com/~r/GemmaPetrie/~3/mH1GyorxU-M/
http://www.gemmapetrie.com/2015/02/23/savesharerevisit/#respondMon, 23 Feb 2015 18:51:09 +0000http://www.gemmapetrie.com/?p=1028In early January, Mozilla conducted user research to refresh our understanding of how people save, share, and revisit content with the goal of building our knowledge base for a larger contextual research project on multi-device task continuity that is currently being conducted. (More on that in a future blog post.)

Methodology

We recruited eight participants to engage in a three-day diary study to document their save, share, and revisiting behavior. Instructions were emailed to participants each morning based on daily themes: Saving, Sharing, Retrieving. Each evening, the participants were prompted to submit their diary entries and answer a few additional questions. Based on these responses, half of the participants were selected to participate in an additional 60-minute video interview with the researcher to explore these themes in greater detail.

Primary Findings

Most people are using low-tech systems to save, share, and manage their content. There is a tendency in tech circles to overestimate the popularity of services like Pocket and Evernote, when in fact the most competitive task continuity resources are basic services like email, local storage, text messages, and screenshots.

Most people are aware that their personal system isn’t perfect, and in fact often cumbersome to maintain, but other solutions are perceived as some combination of absent, confusing, or limited by storage/price.

People tend to save content to their devices, rather than to third-party systems. Some of the participants had tried services like Dropbox or iCloud, but abandoned them when they ran out of free storage space. Utilizing free local storage means people always know where to find things. If saving locally isn’t possible, people will often take a screenshot of the content or send it to their own email account in order to save it.

“If there’s a way I can physically save the article I would save it to my device or SIM card. If I can’t do that, I will take a screenshot of the articles and later go back and view them” – P6

“I found a picture of a toy I want to buy my daughter. I took a screenshot on my phone and I will go to the link in the pic using my computer later to show my mom.” -P2

For most participants, alternate device access was not a big concern when saving content. In fact, most of the time, people intended to revisit on the same device. When saving content, most people intended to revisit it within a short time frame – usually the same day or within a few days. This was due to the fact that people believed they would “forget” to return to the content if too much time passed.

For many participants, the line between sharing and saving was blurred. The primary methods for sharing content – Facebook, email, and text messages – where valued not only because they made it easy to share, but because they also made it easy to revisit.

“Social media and email services make it easy to revisit content because they log and save everything.” – P3

“I found Crockpot recipes on Facebook that I wanted to try, so I re-posted it to my Facebook wall.” – P7

Participants used a variety of low-tech methods to revisit content. The primary methods included relying on the URL bar to autocomplete URLS based on browser history, following links in emails, and leaving browser windows open.

Further Research

The Firefox UX research team is currently conducting a contextual user research project in multiple cities to learn more about multi-device task continuity strategies. These findings will add depth to our current understanding and help us design experiences that will support and expand on these user patterns. Stay tuned for more information on this work.

“The People Issue is about the significance of individuals—particularly 20 Chicagoans whose contributions to the city are in some cases overlooked. But it is also about the ways in which each of these people connects to a bigger community, and how that community can magnify an already potent force.”

Gemma Petrie was moved to find ways to make technology more accessible to people traditionally cut off from it—and found that the work brought her closer to those people than technology ever could: “Those interpersonal experiences, both in the local Chicago community and the global community, have been really powerful. It comes down to people.”

You can read my interview here. Be sure to check out the other 19 amazing individuals as well. (Two of my favorites are Gaylon Alcaraz and Chaz Ebert.)

Last month, Mozilla traveled to India to conduct user research on mobile usage. We are grateful to our talented research partners Dear and Tazurba International for their expert local knowledge, to the amazing Delhi and Rajasthani Mozilla communities who provided critical logistics and translation support, and to the many Mozilla staff members that took time out of their busy personal and professional lives to join us in the beautiful (and blazing hot!) Indian summer.

Field Team

The Mozilla User Research team believes it is important to bring a wide variety of colleagues into the field with us for research. We know that first-hand experience does more to build empathy and understanding than a presentation ever will. This trip marked our largest field team to date and included:

Jared Cole, Design Strategist

Francis Djabri, FxOS UX Designer

Peter Dolanjski, FxOS Product Manager

Sandip Kamat, FxOS Product Manager

Bruce Huang, FxOS Product Manager

Juwei Huang, FxOS UX Designer

Elizabeth Hunt, Marketplace UX Designer

Jane Hsu, FxOS Go-To-Market Strategy/Partnerships

Rina Jensen, Content Strategist

Amy Lee, FxOS Visual Designer

Peiying Mo, L10N Program Manager

Arky, L10N & Community Rep

Rob Rayborn, User Advocacy

The mausoleum of Sufi saint Nizamuddin Auliya in Delhi & a colorful truck on a Rajasthani highway. (Photos by Gemma Petrie)

Research Plan

We aimed to answer the following questions with our research:

Who are the people in our target market(s) in India?

What motivates someone to purchase a mobile device?

What can Mozilla enable people to do with a Firefox OS device?

How can Mozilla make a difference?

India is a vast and varied country and it was difficult to design a research approach that would cover multiple regions with adequate depth in the time we had available. We decided early on to focus this initial phase of our India research program in the north, specifically in Delhi, rural Rajasthan, and Jaipur.

This research used a variety of methodologies to gather data. We conducted one-on-one interviews in Delhi and Jaipur and worked with community members and local researchers to meet with local families, shopkeepers, and visit rural villages. In addition, we also conducted informal ethnographic observation during our two weeks in India.

Ethnographic Observation

One of our primary goals was to immerse our field team in Indian daily life and culture. Our large group and broad geographic research area presented some initial challenges during our planning stage. We made the decision to engage dscout to bring some order to our data collection and help field team members that were new to research think about how to capture and analyze their experiences.

We split each day into two modules with different themes like phone stores, mobile content, or family. We then divided our field team into small groups, accompanied by Mozilla community members, to explore different areas. Each group added photos, videos, and answers to a few short questions to dscout, allowing us to quickly gather a large amount of structured information on each theme. This data, combined with our team’s first-hand field experiences, provided a valuable contextual foundation for our research.

Mobile Open Houses

We conducted one-on-one interviews with 55 recruited participants at “Open House” events in Delhi and Jaipur. The interviews were split into four main topic areas: Current phone and technology usage, phone purchasing process, mobile content, and Firefox OS device user testing.

Study Goals

The goal of this research project was to understand how people in Thailand and Indonesia experience the Internet and to learn about emerging trends that will provide insight into new and current product features for Firefox.

Home in Bandung, Indonesia

Research Activities

The Mozilla User Research team believes it is important to experience in-context research with a wide variety of staff members. We brought a diverse set of talents into the field with us and gave each person the opportunity to engage in cultural immersion activities and two or more qualitative interviews in Bangkok & Chiang Mai, Thailand or Jakarta & Bandung, Indonesia. Our field teams were comprised of: Bill Selman (User Research), Gemma Petrie (User Research), Uday Dandavate (SonicRim Researcher), Larissa Co (UX Design), Zhenshuo Fang (UX Design), Holly Habstritt (UX Design), Bram Pitoyo (UX Design), Margaret Schroeder (Market Research), Gavin Sharp (Firefox Engineering), and Yuan Wang (UX Design).

We engaged in a variety of contextual inquiry and ethnographic research activities including:

Semi-structured interviews with 44 participants (22 buddy pairs) in their homes and offices.

We observed public, commercial, and educational environments.

We connected with local Mozilla community members and hosted community dinners in Bangkok, Thailand and Bandung, Indonesia.

We collected over 60 hours of audio and video and nearly 2,500 photographs.

Finally, we engaged in an extended analysis period with both field teams in our Portland, Oregon office.

Interview Participant in Bangkok, Thailand

Results

In Indonesia and Thailand, changes are taking place with respect to how (and how many) people are accessing the Internet. Rapid technological and socioeconomic development has influenced technology adoption curves and technology-centric behaviors. Our research identified various themes that will help inform the future development of our products. Here are a few of them:

Infrastructure:

Key pieces of critical infrastructure are lagging, especially in Indonesia.1-5

Telecom infrastructure is generally lacking (though improving); Limited bandwidth is shared between a very large subscriber base.

In Thailand, data is cheap (less so, proportionally, in Indonesia). Certain kinds of data usage (like social networking) may be unlimited, while others are metered. People in both markets use multiple devices/telecom providers to maximize coverage/minimize costs.

This lack of stable infrastructure inhibits what can be done with technology and influences software adoption and software updates due to poor or nonexistent download speeds.

Software Market in Indonesia

OS/Software Distribution:

Due to poor connectivity, downloading is often not the only software distribution channel in this region. Physical media such as DVDs and USB thumb drives still play a significant role in how software is distributed and installed. As a result, software packages are frequently installed in a shop, rather than at home. These packages can include everything from the OS, to multiple browsers, productivity tools, and games. In Indonesia, software being sold is often several versions behind the current version and may be compromised with malware.

Search & Navigation:

Participants have difficulty searching the Internet, because they don’t understand the pieces of the browser and the relationship of the browser to the Internet. This resulted in several beliefs:

The belief that Chrome is better for searching Google, because both are Google products.

The belief that search results are generated within the browser, thus searching in a different browser will produce different results.

Navigating to Google.com in order to enter Facebook.com in the Google search box.

Limited awareness that software can be customized or modified with add-ons.

Acquiring software based on popularity in their social circles rather than functionality or performance.

“It doesn’t work anymore” — There is limited knowledge of malware, malicious add-ons, etc., that may be severely impacting browsing experience

Restaurant Menu in Chiang Mai, Thailand

Translation:

Internet users in both markets rely on a blend of English and local language sources in order to find information they need. Users often, but not always, use English language menus on their devices (especially among Thai users trying to save screen real estate). Yet, while many users can navigate effectively in English, translation is still critical to their browsing experience. People want content in a context appropriate language: Local content in the local language and international content In English. Overall, there was a distrust of machine translations and a desire for improved content translation that provided additional cultural context.

What’s Next?

Mozilla is committed to providing the best user experience possible to our global community of users. It is important for us to understand the unique challenges and unmet needs that our users face around the world. We are grateful to all of the participants we were able to interview during this project and to the valuable support of our Thai and Indonesian communities. Over the last few months, our research team shared all of our Thailand and Indonesia study results with various teams at Mozilla. In addition to our observations, we suggested opportunities for addressing the unmet needs in this region. We look forward to incorporating design solutions to these challenges in our products. Stay tuned!

The User Research team is dedicated to understanding who our users are and how to build products that will meet their needs. Earlier this year we completed the Firefox User Types study as part of this effort. This research has already been used by internal Mozilla teams to think about different features and design solutions for Firefox, and the Summit gave the User Research team the opportunity to share this work with the entire Mozillia community. Our session, “Designing for our users, not for ourselves,” was facilitated by Mozilla User Research team members in all three Summit locations: Toronto (Cori Schauer & Gregg Lind), Santa Clara (Bill Selman & Lindsay Kenzig), and Brussels (Gemma Petrie and Dominik Strohmeier). Special thanks to our amazing UR and UX colleagues for their support at each session!

Getting Mozillians Excited about User Research

The summit was an awesome experience with more than 1,800 Mozillians across three locations. We were excited to share our work during our UR/UX breakout sessions, but with so many concurrent tracks, we knew not everyone would be able to to attend. In order to convey our enthusiasm for our research, spread the word about our sessions, and get the community talking about who our users are, we created and distributed enamel user type pins to all of the Mozillians in attendance.

The user type pins were distributed just before the Saturday morning keynote talk.

The pins were a hit and within minutes the keynote auditorium was full of Mozillians trying to trade with one another for their favorite user type. Nearly half of our community members fall into the “Wizard” category of users, but in our research this user type only represents 1% of North American Firefox users. We deliberately distributed only a few “Wizard” pins at the Summit in order to get people talking, and did it ever! As people frantically searched for these elusive pins, it gave us the opportunity to discuss the theme of our talk, “Designing for our users, not for ourselves.” (Thanks to Zhenshuo Fang for her lovely user types artwork and to Madhava Enros for the pin idea!)

“Wizard” work in Toronto.

Teaching the Community about User Types

The word was out about User Types, and more than 60 Mozillians came to the session in Brussels, 35 in Toronto and 30 in Santa Clara to learn more. During the presentation, we introduced everybody to the concept of having user types to guide our design and product development process. We also introduced each of the user types and their specific characteristics. We then split the room into six groups and each group received a short user profile, a collection of photos, pens, paper, and two exercises:

Review the representative profile – you are now that person. Finish this sentence “To me, the Internet is…” using the photos. Feel free to draw, annotate, or whatever you need to finish the sentence. Once you are done, choose three words that best describe the Internet to you [as the user type].

Now that you know how your user type thinks & feels about the Internet, spend time with your group brainstorming what your user type wishes Firefox could do for them. When done, choose the top three ideas your user type came up with and tell us “I wish Firefox would…”

User Types work in progress in Santa Clara.

After finishing the exercises, each group presented their results to the other teams. The goal of our session was to make people start thinking like one of our user types and we were incredibly impressed with the thoughtful ideas each group shared. The presentations highlighted an important constraint our designers work with every day: There are very different ideas about the Web and what Firefox could offer each of the user types, however we only develop one Firefox Desktop which needs to serve all of our users.

The “Stalwart” presentation in Brussels at the “Designing for our users, not ourselves” session.

Thanks to all the Mozillians in the different Summit locations who joined our session. In Brussels, we especially enjoyed the long discussion that followed after the official session ended. We hope that these discussions will continue and that we will all keep the user types in mind when working on future products so that we are better able to build the Internet the world needs. (Special thanks to Cori Schauer for her work preparing this session!)