Design Sprinting During Trying Times: Thinking Through Firefox for iOS and Private Browsing

A design sprint focused on privacy and browsing on mobile devices

Eight people from the Firefox for iOS team spent four days last week in a Google Ventures-style, remote design sprint. The team was inspired to gather for a sprint by existing Firefox user research about privacy and mobile devices and some business challenges that Firefox for iOS is facing.

In many ways, the sprint was traditional in its format. The two-year goal we set for the sprint was for Firefox to be the iOS browser people choose first for privacy. Related to that goal, we surfaced the following key questions:

Can we convert people into privacy-conscious browser users?
Can we solve the problems facing an unsavvy majority, rather than those of a savvy minority?
Can we connect this feature to revenue, conversion, and retention?

Using Miro as our primary tool (building on JustMad’s Miro template), our sprint team, comprised of engineering, design, content strategy, marketing, product, program management, and user research expertise, devised a solution that was a combination of sketches made by sprint team members. We initially named the final solution Private by Default and then re-named it to PandaBrowser for the purposes of user research. (We chose “panda” for our made-up product because pandas’ faces remind us of the mask used to signify Private Browsing Mode in Firefox today.)

The PandaBrowser was meant to be an iOS browser with private browsing mode on by default that included direct value-driven messages and other signals of privacy, including a straightforward way to clear one’s browser activity.

On the last day of the sprint, we ran five unmoderated sessions on the usertesting.com platform to evaluate a basic InVision prototype of the concept and learned the following:

Participants were familiar with the concepts of private browsing mode and incognito and confidently expressed what they thought those modes achieved, whether or not those perceptions were accurate for existing private browsing mode offerings by Mozilla and other companies.
Participants also mentioned privacy-related concepts like cookies, geo-location, and ad tracking, but may or may not have accurate mental models of those items.
Participants found value in their phone browser history, tabs, and/or bookmarks for task continuity and returning to previously visited sites, which for some participants meant that a browser defaulting to a private browsing mode that clears activity often would be inconvenient.
Participants assumed that our Private by Default concept was similar to Firefox Focus in that there was not a “regular” browsing mode to which one could switch. While the prototype did not include any UI elements for switching to a “non-private” mode, the original concept did envision a toggle for switching out of the default private mode.
Participants described specific use cases for a private mode which included watching pornography, searching for niche products like fake Juul pods, location-based searches, and monitoring prices for things like flights.

The team is now in the process of identifying which sprint learnings we want to pursue with further design iterations, experimentation, and user research in 2020.

Also a design sprint against the backdrop of a global pandemic

Mozilla has a long history of having a distributed workforce with close to half of employees working remotely. While this design sprint was originally planned to take place in-person in our Toronto office, the COVID-19 pandemic forced everyone to stay home and participate in the sprint over Zoom. Remote design sprints are not uncommon, but we did the following beyond typical remote working to be sensitive to the trying times in which everyone is living and working.

Rewrote the sprint guidelines to prioritize “Be kind to yourself”

We emphasized at the start of each day that “be kind to yourself” was the most important guideline for the sprint. This included making explicit that people could take breaks as they needed without questions from the team, determine any other accommodations they needed to practice self-care during the sprint, and communicate with the facilitator privately via Slack at any point. We also added the caveat to the “no devices” guideline that we expected sprint team members to focus as much as possible on their primary desktop/laptop device, where we used the Miro board filled with activities that requested active participation from across the team, but trusted that team members would monitor any other devices they needed in order to take care of loved ones.

Made an effort to be more generous with breaks

Given all teammates currently sheltering in place across North America, including three time zones, we considered extra time for wellness and rest. We made sure we did not work more than two hours without a break and made sure our twice daily breaks (30 minutes and then 90 minutes) were considered sufficient for team members’ needs. The team was most crunched for time on Thursday given the prototype testing work, but the team worked together on each day of the sprint to ensure we got our sprint activities done in order to adjourn for our breaks on time.

Checked-in with teammates after each break

The world is changing so quickly, and major news is transpiring throughout each day. Additionally, team members were experiencing major life events, some very sudden and emotional, during the sprint week not directly related to the pandemic. Each time the team convened, at the start of the day and after each break, we made sure to check on what if anything notable transpired during the break time that might merit discussion or at least team acknowledgement. These check-ins took 5-10 minutes.

Two people standing on a table, outside, at the side of a house, hositing a sofa to a second-story window

Collected suggestions for improvement at the end of each sprint day

Gathering team feedback on the sprint at the end of each sprint day is not particularly unusual, but emphasis for daily feedback during this sprint was placed on any accommodations that we might need to add before the following sprint day. Changes we made as a result of the daily feedback was to allow more time, even with our expedited sprint schedule, to hear team members’ rationale for their voting during activities.

Some other changes we will consider for next time:

If five consecutive days are available for the sprint, taking five instead of four days would lessen the workload toward the end of the week, especially for major sprint activities such as the prototype-making, user research planning, and group watching of the usertesting sessions. (Our team was limited to four days due to the Easter holiday.)
Perhaps lengthen some activities and shorten other activities. The team noted that more time with the Monday experts and for team discussions about important sprint decisions would be valuable.
Set higher standards for the accessibility of our sprint tools. For example, while we never used color as the only signifier for activities on our Miro board, there were some instances where color was privileged over other signifiers, even with one of our sprint team members having color-blindness. A more accessible sprint would not prioritize a single type of affordance (e.g., dependent on vision).

Long-lasting lessons

A Mozilla researcher who was not on the sprint team mentioned recently that perhaps one upside of the current pandemic is that we may all learn to be more empathetic to the people around us, perhaps more fully aware that we can never know what or the magnitude of what someone is experiencing in the current moment or even due to long-standing circumstances, some even systemic. While current world events inspired some changes we made to the way we work in the case of our recent design sprint, one could argue that these types of accommodations should be the norm. Our experience last week was a reminder that remote design sprints can be a valuable approach for bringing together a diverse group of people to do focused problem-understanding.

One of the sprint team members added: “…while we cannot physically be present with our friends, families, and coworkers, it felt really good to work together towards a common goal. Even if this goal isn’t going to change the state of our world right now, the togetherness and team-building warm fuzzies are ever more important during these times.” The idea of working toward an inclusive common goal is what we try to do at Mozilla on good days and, if recent times are any indication, on the toughest, too.

Thank you to the sprint team for your hard work last week and to the other Mozillians who provided feedback on an early draft of this post.

Originally published on Medium.com