Typically we work through our design challenges virtually. We have 27 people scattered across the planet and we spend our days in Google Hangouts, HipChat discussions, GitHub repos and putting notes on Trello cards. We were starting to realize the limits of these virtual discussions as we tried to use more of a design thinking approach to our solutions. And then right about this time Google published their Design Sprint book and we immediately realized the potential.
This post chronicles our first ever Design Sprint where we brought ten people together from three teams and four different countries to solve a big problem and test a solution in just 5 days.
A Design Sprint is a five-day process used to target critical problems, done through discussion, design, prototyping, and testing a solution with real customers. It fast-forwards through long debates, and instead compresses the process of testing a new idea into a single week.
Our first target up to bat was the process for adding images and video to a presentation, and creating a slideshow from them. The goal was to find a way to make this process more intuitive and test it through our Design Sprint.
Every Sprint consists of a Decider and Facilitator. The Decider is there to make the big decisions. They know the vision of the product or company, and can confidently make decisions about its direction. Our Decider knew both our product and our customers so he was well positioned to make the tough decisions.
Our Facilitator was responsible for running the show. He was familiar with the Design Sprint process, he knew the problem we were there to solve, and so he was able to filter discussion and ensure that the Sprint ran on track.
Day 1: Planning and Discussion
According to Google Ventures (GV) Design Sprint Guide, Monday was the day for planning and discussing. We would first discuss our goal, decide on a target and then talk to our experts - these were people with insights into either our product, our user, or both.
First thing on our agenda was recapping the goal of our Sprint. This was an important step as our goal would define the scope and build the foundation for the week. We had a rough idea of our goal before we began the Sprint, but we thought we should review to ensure that everyone was on the same page.
Discussion kicked off with talking about our short-term and long term goals - what did we want to achieve six months from now? A year from now? The answers were abstract and ranged from the ability to support all video formats to allowing users to add captions to their content. Then we discussed the pessimistic outcome; where could we go wrong, what opportunities could we miss out on? Our new features could never get used, or our users could dislike the changes.
Then we summarized the answers to these questions to form our long term statement which outlined the objective for our Sprint. Our long term statement read; “In 2 clicks or less, Miranda (a fictional user) can add Images and Videos to a Display, they show up on Displays with 99% or better reliability, and the cost of delivery to the Display is controlled and non-variable. As a result we decrease costs and increase subscribers.” This became the point of reference throughout our Sprint, defining both the scope and target for the events of the week.
Once our goal was set we began mapping the context of the problem that we would solve by defining a simple storyboard of the area we are focussing on and how we would like the user to move through it. Once finished, we brought in other experts from throughout the company to review our map and goal.
The experts came back with insights about our customers and about the features we should consider incorporating into our final prototype. As they spoke, we took notes on how we might go about tackling our goal based on what they said. We then used these notes to help vote on our target. The notes were divided into categories, and we voted on the categories we felt were most important to address if we wanted to be successful in achieving our goal. Our votes, along with the Deciders final say pointed our target at “2 clicks or less” and “Improving Image/Video selection”.
Day 2: Sketching
Tuesday was all about sketching solutions that would achieve our goal.
The day started off with Lightning Demos - a show and tell exercise where each team member could show off features they liked from two other solutions. These were meant to inspire ideas for the sketches that followed. The team ooed and awed at the dazzling features of various photo editors, and the upload processes of other applications.
Our favourite was Canva’s fish animation while it uploaded your photo, (definitely out of scope, but oh so cool). The big takeaways were giving users the ability to adjust aspect ratio, providing upload processing bars on the artboard, and creating auto-generated thumbnails next to each Placeholder.
In the afternoon we went through several sketching exercises, each time iterating on our ideas. By the end of the day each member had sketched a full interface and accompanying user flow.
Day 3: Deciding
Wednesday is where things got interesting.This was the day to decide on a final sketch for prototyping.
First thing in the morning, we had an “art gallery” where everyone got the chance to walk around and see the ideas of their peers. Then they would vote on the ideas and features they liked best. The feature(s), or individual sketch with the most votes would be the one we would prototype and test.
Most of the votes were placed on individual features of the sketches; like click and drag, or including thumbnails and one sketch (“The Humdinger”) and all of it’s features had received quite a few votes.. But the votes for individual features outnumbered the votes on The Humdinger, so we decided to build a new solution (sketch) comprised of the sum of the features on all of the sketches that had received the most votes. And this is where things went wrong.
During the sketching phase, we had become caught up in adding features such as aspect ratio controls, and fit-to screen buttons, that we forgot about the goal and didn’t consider ways to make adding a Playlist simple. The Humdinger did however tackle the process for creating a Playlist, but no one wanted to abandon ship on our new solution, and the two weren’t compatible designs so combining the sketches wasn’t an ideal option.
The problem with creating a Playlist was that it required a Placeholder to mark the spot for the Playlist. But, our average user doesn't know what a Placeholder is, and making them add one isn’t an intuitive step and would not accomplish the task in 2 clicks or less. This lack of planning created a block in the flow of our Sprint. It sent team members off into side discussions.
Our Decider began pitching The Humdinger to anyone who would listen, and we even had one team member go off and start their own storyboard. Needless to say, tensions were high and we thought we might be starting over from square one.
The debate continued on for about an hour or so. And then someone who had sat back and kept quiet through the back-and forth, proposed that we focus on simply getting the flow down, that way we could fill in the details once we knew what should go where. So we sketched up a user flow that followed the same principles as our map but instead of being focused on what we currently do, it marked out how we want it to be.
After we had the flow down, the other features began to fall into place. We even managed to incorporate features from The Humdinger. After an hour and a half delay, our storyboard was finished and ready for prototyping.
We decided to add Image, Video, Text and a "More Widgets" button in the place of the “Add Widget” button that was there. This would cut out more steps and eliminate the need to go searching through the store for common Widgets. The solution looked promising, spirits were up, friendships reconciled, and we were ready for day four!
Day 4: Building the Prototype
Thursday was focused on building the prototype. The previous day, the team decided it would be easier for us to build a working prototype with code. We had numerous developers and UX designers present who could write code faster than they could add buttons to a prototyping tool so it seemed like a better solution. We divided and conquered.
Each team member was given a role from writing copy, to development, to UX. We worked away for a few hours and our prototype was done and ready by lunch. While building the prototype, we decided to cut back on the number of clicks required to add images or video, by automatically adding a new Placeholder when our user created a blank Presentation. This ended up being a harmful decision down the line...
Day 5: Testing
Friday meant it was time to test the solution we had been working on. Throughout the week we had been organizing interviews for five existing Rise Vision users to come in and test our prototype. We were excited.
We set up our participants in a room with a computer that was open on the Rise Vision Editor. We gave them two tasks: adding a logo to a Presentation, and creating a Playlist from a folder of images on the computer's desktop. During the testing, our team was sitting in another room watching a live feed of the interview through the computer's webcam. We were also live-broadcasting the interview to our entire company, so anyone in the company could tune-in and watch, regardless of if they were in the Sprint or not.
Our first interview kicked off at 9:00am. The boardroom felt like a Sports Bar during an intense game. The team ooed and awed, yelled, shouted encouragingly, and crossed our fingers as we watched the participant navigate the prototype. The participant managed to complete the tasks we had given him but he encountered some difficulty.
The four interviews that followed weren’t very successful.The participants liked the fact that we had clearly marked buttons for common widgets but they couldn’t get past the concept of adding a “Placeholder”. This was an important realization for our team. The word “Placeholder” had confused people. It was something we came up with within our company and the average user has no idea what it means.
We also noticed that our participants were confused by the Placeholder we had automatically added for them. Users were confusing this Placeholder with the artboard, and when they were required to add another one for a separate task, they had no idea that 1) they needed to, and 2) what a Placeholder was because they didn’t need to do it the first time.
We concluded that our Sprint was more along the lines of what Google Ventures calls an “Efficient Failure”. Maybe our Prototype wasn’t 100% successful but we had just learned so much about our users, our apps, and how to bust out a design in only 5 days! That being said, we’ve learned where we went wrong, and we are working on building a variation of our solution. So you can expect some new changes to our editor soon.
Despite the temporary disappointment, we left the room at the end of the day just as happy as we had come in. And now we are planning for each team to have their own Design Sprint at least once a quarter.