Sprint Story: Learn how we became Apple’s iOS Tips product team for a week.
Let’s solve a challenge as a team!
Collaborating as a team to solve big problem is usually not an easy exercise. Even less a fun one. Let’s face it: most of us work in an environment that was not designed to function that way. This is why we are sharing this story of our experience running a Design Sprint: 5 days of intense collaborative work to solve a big problem using Design Thinking methods.
So, what are the benefits of a Design Sprint?
- Engage coworkers.
- Learn a new way of solving problems.
- Develop expertise in pragmatic Design Thinking.
- Talk to users in person.
- Feel accomplished.
- Move fast.
- Have fun!
Let’s be clear: solving the core challenge of the sprint was NOT the only objective. It was definitely a nice-to-have. Our core objective was learning by doing while having fun as a team. It was an experimental exercise by essence with no intent to commercially use the output.
This Design Sprint was not about the destination. It was about the journey as a team. Nevertheless, we knew it was important to pick the right challenge for the team to be engaged for a full week.
We chose to pick a problem where no one had skin in the game or a personal attachment. We brainstormed potential problems based on observations from people in our close network or problems we personally faced recently.
We needed a challenge where:
- The underlying problem was intrinsically easy for the team to understand and gather insights.
- It was very likely that our team members had personally experienced.
- The prototype would be easy to build (i.e. digital product).
- We could easily and rapidly recruit local users to test our solution face-to-face.
We used these criteria to narrow down our list of potential problems.
iPhone users struggle to discover and understand how to use new features that come after a major iOS update.
Our goal for the sprint was straightforward :
As Apple’s Product Marketing team in charge of iOS 10, how can we help our users to discover and learn to use new features that come with each update of iOS.
This “role playing” trick, where we pretended to be the Apple team facing this problem, helped us to make the situation more real and concrete. It was also helpful when assessing the real life business and design constraints. We often went back to asking ourselves: “What would Apple do?”. And more importantly: “What would Apple NOT do?”.
It also came with some cons. We didn’t have deep past expertise around the problem. We also fell short in understanding the full extent of the problem, of existing solutions, and the current user behaviors.
We recruited the team on a volunteer basis. We approached our coworkers on an individual basis. We explained them the Design Sprint concept. We also talked about our goals and expectations. We discussed the benefits and learnings they could gain in participating. A few were excited to join the experiment and could free their schedule for an entire week.
The individuals in our core team have a pretty diverse mix of skillsets. There was a Graphic Designer, a UX Designer, a Business Developer, and a Planner. We were two facilitators: a Product Manager and a Product Designer. We took turns in facilitating the sprint. When one of the facilitator was not moderating, he was participating with the rest of the team.
Understanding the problem
To gain an understanding of the problem, we interviewed a couple of experts.
We brought in Matt, an Apple Genius with 5 years of experience. He provided tons of insights on user behavior. He helped us understanding how the cycle of iOS updates fits with Apple’s business goals and strategy. We also interviewed Will, a coworker who is an industry expert and Apple fan.
Thanks to our experts, we gained a holistic and deeper understanding of the problem. This helped the team to narrow down two sprint questions:
- Will users prefer using our solution versus existing available 3rd party solutions?
- Will users be less disrupted by a personalized solution versus a generic one?
We divided our audience across three personas: “normal users”, “power users”, and “evangelists”. We decided to focus our sprint on “normal” iPhone users. Based on our research, the problem we were focusing on was impacting them the most.
Brainstorming new ideas
The team used every tool in the Design Sprint toolkit to ensure we were truly diverging. As a result, we came up with lots of new creative ideas.
The “lightning demos” exercise catalyzed the team’s inspiration. We looked at a large diversity of design concepts in existing products. We focused on picking concepts from products outside of the mobile app industry. Lots of ideas came from video games level design, education web services, and social media. We came back to it multiple times over the course of the day. These design concepts acted as a repository of raw ideas that helped us in our creative process. They became the building blocks of our solutions.
We then used the 4 steps iterative sketching creative process:
- Note gathering
- Rough ideas
- Crazy 8s
- Solution sketch
Because of the size of the scope of our solution, we divided the work into three independent sections. Two person worked on each of them.
- The trigger: what brings a user to want to know more about a feature.
- The content: what helps a user understand how the feature work.
- The exit: what does a user after he learned and interacted with the new feature.
This creative process led to 6 full solutions sketches. We closed the diverging part of the design thinking process on these 6 full solutions.
The next day will be all about converging.
Making fast decisions
Now that we had explored lots of innovative and creative ideas, it was time to select which idea to pursue. Our goal was to end the day with a thorough detailed plan about what prototype we are going to build.
To narrow down from what we had, to what we needed, we used a series of steps to help us make fast decisions. Making group decision is generally an exhausting process. It is also prone to a variety of individual cognitive biases and group thinking.
To overcome these issues, we started by using a silent voting system to highlight the best ideas. With this technique, each team member has the same amount of influence over the final decision. It also helps the decider to make fast informed decisions. The team has to constantly goes back to the sprint goal to make sure we keep a common direction. The best ideas and sections are selected and recombined into a new solution.
Next step was the creation of a storyboard. The storyboard is a critical step to discuss the details of implementation of these big ideas before diving in building the prototype itself. It is an intense collaborative exercise.
Multiple vignettes are composing the storyboard, like a comic book. It starts with an opening scene and walk the user over tasks. In our case, we had 12 vignettes. The opening scene was an iPhone notification. There were several tasks for the user to perform combining interactions and videos.
The big and small ideas
Our solution was revolving around a handful of big ideas: personalization, engaging content, and fun discovery.
These big ideas translated in combination of small ideas during the storyboarding process. Here is an overview.
The main trigger was all about push, videos, and fly-test. We designed:
- A push notification trigger about a popular new feature that the user has never used so far.
- A 5 seconds walkthrough video of the feature.
- An option for users to directly try out the new feature after viewing the video. We tested two versions of this fly-test option: a simulator within the “Tips” app, and, a deep link to the real app where the new feature lives)
We also revamped the UI and navigation of the “Tips” app itself:
- We created a navigation menu with two levels: 1) apps & 2) feature in that app.
- We picked menu layout made of floating bubbles rather than a scrolling listing.
Finally, we added personalization into the menu content and layout by:
- 1 correlating the app bubble size with the level of popularity of the new features living in that app.
- associating the app bubbles color tone to the user personalized frequency of usage.
- distinguishing visually whether a user has discovered (video watched) or already used particular feature.
Building the prototype
We started with a discussion about the tools we could use to build our prototype. Teams usually have a design toolkit they are familiar with and they use in their job. Since we put together our team specifically for this Design Sprint, we needed to add this step to the process.
After some discussions, we agreed to use Adobe Experience Design. It comes up with all the UI elements of the iPhone and iOS10. Our UX Designer knew the tool very well. This was enough to make XD a natural winner.
Now that we had built each vignette in XD, we needed to stitch everything together. We also wanted to add animations and user interactions. The team decided to use Keynote to do that. Keynote is a surprisingly powerful prototyping tool. It is extremely easy to use for people with no design background. It also has a theater feature to run the prototype full-screen on an iPhone, which became very useful when testing the prototype with users.
We also created and embedded tutorial demo videos that we created with QuickTime and After Effects. This was one of our key idea for users to quickly learn how to use iOS new features.
You can check a few screenshots of the result below:
Testing with users
The excitement to have real users coming to our office to test our prototype was palpable. The prototype was far from perfect and extensive. But it was functional and usable. And that’s all we needed for our user research to fuel a good discussion with users.
But before people show up at your doorstep, you have to recruit them. A couple of day prior, we posted an ad on Craigslist. Following the Design Sprint book advice, it was simple and straight to the point. “User interview. $60 for 60 minutes of your time.” We rewarded the participants with an Amazon Gift Card for their time and participation.
We made sure they were part of our core audience. We created a small screener to test a couple of points:
- iPhone users for over a year. We wanted to make sure they’ve been through an update cycle.
- Not too tech-savvy. They had to qualify for “normal users” and not”power users”.
- Not working in a product / engineering / design role in a tech company. We wanted to get genuine reactions, not professional advice.
The interviews was a mix of user research and usability testing. They were 60 minutes long. Our user researcher intentionally designed the script to be simple and flexible. It focused on “themes” and “hypotheses to test” rather than a clear sequence of questions to follow. Here are a couple of these themes and hypotheses:
- General context about the user as a person.
- The usual behavior and relationship with their iPhone.
- Reactions to certain steps in the prototype.
- Reactions and feedback around the comprehensive experience.
Our user researcher did all the 4 interviews to make sure we had consistency across users. We had two cameras in the room. One was streaming a view of the phone interactions. The other one was streaming the interviewee face so we could see her reactions.
The rest of the team was in a separate room. Everyone took notes during the day using the post-it method. We distilled the core takeaways by placing these post-it on an affinity map after each interview. At the end of the day, we all debriefed together to identify the common patterns about what worked and what did not.
Learning about the process
Our team deeply cares about continuous improvement. Heck, we even built a tool in Slack to facilitate quick constructive feedback among us. As facilitators, we wanted to conduct a retrospective of the entire sprint. We came up with a simple idea.
Everyday, at the end of the sprint, we asked every team member to record a short video / audio. The team had to answer the following 3 open-ended questions:
- How do you feel right now?
- What did you enjoy today?
- What was challenging?
The day after the end of the sprint, we reviewed all the videos. We used the post it note taking method (obviously) and consolidated the main insights. This gave us a great overview of the pulse of the team emotional and physical state over the course of the sprint. We also spotted some mishaps in the facilitating process itself. It helped us to reflect on it and point out areas where we succeeded, stumbled, and failed.
We will share those learning in a series of future posts. We also reflected on our experience as facilitators. We will share insights on what we did right, what we missed, and what we failed on. For those of you thinking about running a sprint in your company, we hope that it will help you taking the plunge.
We are definitely convinced by the Design Sprint concept. We aim to apply it again in our own company on real problems some teams are facing this time. But before, we need to educate our coworkers about it and the benefits it can provide them. We scheduled an internal brown bag session to walk our co-workers over this story.
Our office promotes collaboration and cross-pollination of domain expertise. We will search and find internal opportunities to support our co-workers in overcoming challenges they face. In a similar way than Google Ventures, we also want to offer startups that are part of our Corporate Accelerator the same opportunity. We want to support them in answering a major challenge they are currently facing. Startups needs to move fast and in the right direction. It’s a question of survival. They also have strong multi-disciplinary teams. The Design Sprint model is a tool perfectly adapted to their needs and goals.
From our perspective, we are curious to learn the differences between internal design sprints and external ones with startups. We aim to run 3 more sprints before the end of the year. If you have an interest in having us facilitating a Design Sprint for you please reach out to us at firstname.lastname@example.org .
Our thanks go to (in no particular order):
- Our Design Sprint team: Carolyn, Ludo, Sara, and Gene.
- Our experts Matt and Will.
- Nadya who took the time to advise us on the process.
- The Sprint Book and its authors.
About the authors:
Gregory Veran. I am a Product guy with a balanced mix across Business, Technology and UX Design. I am currently honing my Product Design skills through multiple initiatives (running Design Sprints, building Captain Feedback and a marketplace for nanny share). You can read my latest posts on my Medium profile and follow me on Twitter @gregveran.
Antonin Lapiche. I‘m a Product Designer at Orange. I’m building expertise from the ground to infuse design (not pixelpushing) in the veins of the company. I care a lot about solving problems for people like you and me. I see technology being an enabler for solutions. I don’t see technology always being the solution itself. You can read my latest posts on my Medium profile and follow me on Twitter @airlikidh2.