A New Mobile Experience
What we’ve been up to so far
Our new Context Graph effort is steering us into some new and uncharted territory. But I can’t help but feel a sense of adventure because this opens up so many opportunities for new products and experiences — exciting times!
I spent the early part of my career working with a bunch of startups. “Move Fast and Break Things” was often the motto. Sometimes it was the right approach. Hammer away, and don’t be afraid to pivot later on. But stopping to question what or why we’re hammering is becoming more and more important.
Our team was tasked to create a New Mobile Experience. Here’s how we’ve been approaching it.
The Design Sprint
We started by reading The Sprint Book written by the folks at Google Ventures. “Sprint” writes about a five-day process for iterating on ideas and ultimately shipping products that solve real user problems. Additionally, the book has some great examples of other teams that have followed the same process.
To help us figure out what we should start hammering on, we decided to run our own sprint.
Since working remotely is fairly common at Mozilla, the first thing we wanted to do was get together in person. A prerequisite to running a sprint, but also just very helpful things to do for a new team. As luck would have it though, scheduling proved to be our first issue. Not a great start.
But there’s still a lot we needed to do before meeting. Our two main goals right now are:
- Familiarize ourselves with the Sprint process
- Share an understanding of what problems we’d like to solve
Remote Sprinting
Here’s where things get more interesting. Before meeting, we decided to try and run a modified sprint. Specifically, to running one remotely. Scary, I know. But the hope is that it will help us achieve the two main goals I mentioned earlier — to work together, and to learn.
Gemma, our Lead User Researcher, headed up this effort for us and designed with our first remote sprint. She also played the role of facilitator. You can read more about the process in her upcoming blog post (link to be posted soon!) but I’ll give a quick recap below.
At a high level, they’re two weeks long, requires a lot of video meetings (everyday to be exact), and involves a large amount of trust. Most days break down to a team working component followed by an individual homework assignment (to be completed before the following day).
Week 1
Day 1: Team — Select a high-level topic, Individual — Research and map out the problem space
Day 2: Team — Share research, choose a topic of focus, Individual — Sketch out ideas for solutions
Day 3: Individual — Cont’d sketching ideas for solutions (Crazy 8s style)
Day 4: Team — Quickly present own sketches, vote on the best ideas
Day 5: Team — Turn the “best idea” into a testable hypothesis, Smaller Team — Begin drafting a storyboard
Week 2
Day 6: Team — Share storyboard draft, give feedback, Smaller Team — Address feedback, or start on a prototype
Day 7: Team — Share the progress on the prototype, Smaller Team — Create, pilot and launch a user test
Day 8: Team — Watch user testing videos, capture learnings, Individuals — Brainstorm next steps
Day 9: Team — Evaluate the process, iterate on the prototype
Day 10: Team — Postmortem/follow up sprints
How Might We
The second goal here is to have a shared understanding of the goals and the problem spaces. It’s important for us to be research and data driven here so we created a template to help us out.
Since we’re distributed, it’s really helpful to have these posted somewhere. The team can refer back to them at any time, and they can be used to settle tie breakers. It provides a “North star” that everyone can always look to.
Adapting this from the Activity Stream Team and The Sprint Book, here’s how we’re phrasing our ideas in the form of a hypothesis statement:
We know this is a problem worth solving because
(user research/background research/other sources, attach if possible)
We believe that
(doing this/building this feature/creating this experience)
for (these people)
will achieve (this outcome).
We will know this is true when we see
(this user feedback/data).
The primary thing we want to be able to answer after user testing is if users
(used/understood/adopted, etc).
What’s next?
Gemma, our Lead User Researcher, will be publishing a post on designing and running remote sprints.
Ricardo, our Senior Interaction Designer, just facilitated our second remote sprint and has already been sharing his thoughts as a first time facilitator .
Next week, we’ll be meeting in person for a full Sprint Week.
This process has already inspired two new experiments we’ve started hacking on. The first, a clipboard application to help users gather links for later. The second, a notification manager to give users more control over disruptive notifications.
The way teams are distributed across timezones at Mozilla, I think it will always be helpful to find new ways of working. Perhaps some of our learnings here will be helpful for other teams too. We’ll continue to iterate on this process and look for ways to improve it. Each sprint, better than the last.
