Who are we?

A group of us at Mozilla were recently tasked with creating new mobile experiences beyond the browser. We were given the freedom to experiment in areas where users have real problems but other companies would be unable or unwilling to solve them.

This is an exciting opportunity, but… where exactly do we start?

Nick Nguyen, Mozilla’s VP of Firefox Product, gave us inspiration in a recent post where he noted that “the web today is like an old growth forest” with tall trees leaving little ground for new ones to flourish. This has come at the expense of the user, who can no longer discover the best the web has to offer because it’s overshadowed by ever more powerful giants. What if we did more to bring the right web page and most useful content to you on your mobile device?

This is where the “New Mobile Experience” team fits in. We’ve spent the past few months using the Design Sprint process to prototype apps that find the right web page in many different situations: shopping, news, and travel. In our most recent sprint we focused on helping people discover relevant content passively and proactively as they explored a new city.

What question did you want to answer?

We started with a large problem space and the ambitious goal of Helping mobile users discover and find things in unfamiliar places.

We wanted to provide a simple experience that allowed users to explore their surroundings and find interesting places and events. Imagine that you are in an unfamiliar location and want to find out what’s around you — venues, historic places, tourist destinations. You may find many things worth exploring, but typically that requires planning and research. How can we help users who need easy and simple recommendations of that sort? We found ourselves asking “why” a lot during the Sprint. Our goal of a “satisfyingly great day” was usually the answer.

Who was on the Sprint team?

The core team is geographically dispersed across 3 continents and 5 different time zones, so it took us a while to get everyone in the same location and meeting room. Mozilla is a global organization with a remote workforce that makes up nearly half of the entire company. This presents a whole different set of challenges when spearheading new products.

We made sure to include people with diverse backgrounds and skillsets to complement the viewpoints. The Design Sprint participants list included:

Nick Nguyen (Decider)
Maria Popova (Decider)
Gemma Petrie (Facilitator & User Researcher)
Anthony Lam (Design)
Ricardo Vazquez (Design)
Emily Toop (Engineering)
Chenxia Liu (Engineering)
Michael Comella (Engineering)
James Hugman (Engineering)
Mike Han (Marketing)

How did you make your prototype?

We started building our solution by researching and finding inspiration “outside our industry”. The idea was to unleash creative thinking by examining other companies’ products. From bots and messenger apps to how hostels use common space, we shared unconventional approaches to solving big problems.

We then followed the well-prescribed Design Sprint process by sketching individual ideas on paper, going through peer review and voting on the best ones. Having more people on the team resulted in a larger pool of suggested solutions we could select from, and that worked to our benefit. We had the luxury to pick and find inspiration from a bigger set of creative ideas.

Storyboarding was another highly interactive and creative session that made us think through details like the opening scene, setting the stage, downloading the new app, simulating the surrounding environment and so on.

The choice of tools was largely informed by the needs of the prototype we were building. For example, we wanted it on a mobile device. We had a storyboard that outlined a general UX flow, and we wanted to get it done within a couple of hours. We chose InVision because it was easy to get accurate, touch centered prototypes. The team helped and supported the design by collecting assets, working on the final copy and coordinating the timing of all the individual stages in the storyboard. Simultaneously, a group of us focused on user testing preparation led by our User Researcher. We created detailed participant screener, test script, and ran through the logistical details.

What did you learn from the test?

Day 5 of the sprint week comes with a lot of anticipation and excitement. It’s the culmination of a weeklong team collaboration and testament for our creative work. We were nervous anticipating user reactions and test results. One challenge was making the testers “imagine” they walk in a city and simulate appropriate notifications depending on their “location” and time of day. Luckily, our highly experienced User Researcher made the whole experience feel seamless and natural.

Our prototype tested well with all participants. Everyone saw the immediate value in suggested places of interest. The awe-inspiring moment was when users realized the tremendous benefit of event notifications. Equally interesting was that users had an incredibly allergic response to the suggested “coffee-break” notification. Technically it’s the same thing, but the reactions couldn’t be more opposite.

Here are some of the praising comments from our participants:

“I think it is a pretty cool application. I can see myself using it on vacation and traveling.“ [P1]

“I am definitely interested in this app. It is much more personal than similar apps. It seems like you won’t miss anything when using it.“ [P2]

“The design is good, it is very clear. I like that it shows things that are happening right now.“ [P4]

The results of the Design Sprint illuminated things we assumed, but also details we overlooked. For example, the logo of a widely used location-based app, like Foursquare, was completely unrecognizable. Some users were also challenged by the navigational model of the app. These are great lessons for us and set a clear direction for what to focus on next.

What’s next for your project?

We are pursuing further development and exploration of a travel mobile app. We decided to focus on “places of interest” recommendations rather than overall trip planning. The team started working on an early prototype/MVP that incorporates feedback and suggestions gathered from our user testing and a subsequent round of user research with a more geographically diverse set of participants.

What worked/didn’t work about the process?

The Design Sprint gave us the opportunity to conduct a very broad solicitation of ideas in a short timeframe. It was a safe place to explore the product thinking prior to investing in expensive development effort. Another great benefit of the sprint is the fast feedback loop and the ability to quickly get real user feedback while making sure the rest of the team is actively participating in that part of the process. We got answers to crucial questions, like: Will our idea make a good product? Is there room for another mobile travel app in a crowded and established market? What is the unique value that our product can deliver? How can we differentiate ourselves so we stand out?

As an added bonus, the sprint allowed the team to bond, work collaboratively and unleash individual creativity. This was an incredible opportunity for our highly distributed team that mostly works asynchronously and leverages video meetings as the main channel of communication.

Did you make any modifications to the process?

Having conducted two “virtual” sprints before, we wanted to follow the process as closely to the book as possible.

One issue we came across heading to this process was the higher number of participants. We faced a big dilemma — conduct two Design Sprints simultaneously, or tweak the process for a larger audience. At the end, we resolved to having 10 people in a single sprint. By making clear ground rules around timeboxing discussions and sticking with the timeline, we stayed on track and were able to test our best idea by the end of the week.

We also had two Deciders in the sprint, which resulted in an interesting dynamics. In addition to the Product Manager for New Mobile Experience, the VP of Firefox Product at Mozilla joined us for a whole week. He cleared his calendar and diligently attended to his duties as a Decider. Some people on the team felt uncomfortable at first, but most appreciated the fact that we had a senior executive dedicated and deeply involved in the Design Sprint.

Will your team sprint again?

We plan on conducting more Design Sprints following the best practices outlined in the book. We found tremendous value in discovering and vigorously debating new ideas whether we’re co-located or spread over the globe. Our “virtual” and on-site sprints so far targeted very different user needs and problem spaces. Each one taught us valuable lessons. From the expert interviews, to the passionate voting on best sketches, all the way to observing user reactions, we were rewarded with some of the most gratifying moments in product development. Continuing this adventurous journey will likely present more magic moments when a user tests our next prototype. We certainly hope that great findings are in store for us because, as the authors of the book acknowledge, “the successful test is not the end of the process” but the beginning of something really awesome.