Our client is over the ocean, our client is over the sea / Oh, how nice a Design Sprint would be. We went against all advice and ran a remote Design Sprint. Here’s why and how.

Bringing in the Designer

When I joined [e-spres-oh], +1 year ago, one of the projects that I became part of as a designer was well on its way. The team, mainly made out of developers, was working closely with the stakeholders. It’s worth mentioning that [e-spres-oh] functions as a flat organizational structure, so each team is directly responsible for the product they are building and the relationship with the client. When I stepped in, they asked me to review the UX/UI, meaning to look at the user flows and see how we can improve usability. And, of course, make it pretty.

We redesigned some of the flows, trying to alter what was already built as little as possible. Since we already had hundreds of users on the platform, we could get quick feedback and analyze the improvements. Our approach was to make quick changes and see the results. That usually works well when you already have the features implemented, a pool of users, and some good, patient developers. Which we luckily had. Some flows were easily improved with small changes. We had to get back to the drawing board for others, and it took a long time to redefine. That can be a bit (“a bit”) frustrating for the people who had already worked for months on those features. But hey, that’s the product world, right!?

As with all products, it sometimes felt like we were going in circles. That’s usually about the right time to start thinking about a Design Sprint. It was hard to sell the idea for something that we had already developed. But the moment arrived that we had to build new features to the platform, so it seemed like a great time to give it a try.

Wait, What’s a Design Sprint?

Oh, just Google it! It’s their process anyway, and it’s on everybody’s lips lately. But just so we all know what we’re talking about, a Design Sprint is a 5-day process in which you bring the product team in one room (reps of development, marketing, design, etc.), together with some stakeholders and have them go through a series of workshops that would define a problem and generate solutions for it. By the end of the week, you should have a prototype to test with some real users and get some precious feedback.

Google Venture Design Sprint Process — Image from the “Sprint..” book.

In short, here’s how it goes:

Day 1: Understand the problem you’re trying to solve by talking to people (experts) that have relevant opinions on the matter. By the end of the day, you should have defined a Sprint Goal and built a map showing the steps your users take to accomplish their goals.

Day 2: Get inspired by looking at different products and presenting your findings to the team. Having done that, everyone is ready to start sketching their own solutions via a guided exercise that will help even those shy “drawers” get their ideas out on paper.

Day 3: Vote on the solutions and decide what gets included in the prototype. Take all the bits and pieces and stick them together into a storyboard, so you’ll have a clear view of what to build the next day.

Day 4: Build the prototype! Quick and dirty but real enough to get some relevant feedback.

Day 5: Bring in the users and have them mess around with your prototype. Take notes & learn from your mistakes!

Why do that? Because you only spend 5 days, instead of months of development, before getting something in front of the user. You get a much clearer direction, and you bring everybody working on the product on the same page. You can read some more about how these things work here.

Why Did We Decide to Go for a Design Sprint?

As I previously mentioned, we were going in circles for some of the features we were trying to improve. Sometimes the stakeholders didn’t agree among themselves on how some things should work. And that’s what usually happens when you have more than… well… one person deciding. It’s normal. But that also means that you might lose the money you’ve invested in the development. At least some.

We were just about to start building a new part of the platform for different user types. The perfect moment for a Design Sprint. It would help us understand what we were trying to build, get our ideas out on paper, and test with some new users. The clients agreed, but…

..Remote!?

One of the reasons Design Sprints are quite hard to sell to clients is that most people are busy (wow, take that for a memorable quote!). If you want to play it by the book, a sprint takes 5 days — 8 hours per day. It’s a full-time job. For stakeholders, taking that much time off to be in a room with you seems crazy. Especially since we kind of wanted all 3 of them to be there. And where would “there” be? Our team is in Timisoara — Romania, and they are in the US.

We decided to compromise and try the thing that most people advise against. A remote Design Sprint! Such rebels! We had 3 people from the Timisoara team, 3 stakeholders from the US, not enough time, 7 hours, and 7000 km between us. How was that supposed to work?

How Did It Work?

Well, first of all, you need some planning. Obviously, all Design Sprints need planning, but this one had to consider all sorts of different things.

Day 1

We were lucky enough to be in just 2 different locations. The US guys were in one room, and we, the Timisoara people, were in our office. We reduced the day to 4 hours, which would be convenient to both time zones (not easy), and went on defining our Sprint goal and understanding the problems we were trying to solve. After just a few hours, the stakeholders were already happy to have gotten into this and started seeing the value of the whole process.

By the end of these hours, I had prepared some homework for everyone: finding other similar products to get inspired from and adding snapshots of them to an InVision Board that we would all review the second day.

Using Google Draw to build the Journey Map & InVision to present and vote on solutions.

Day 2

Everybody had done their homework, so by the time we got together again the second day, we already had The Lightning Demos (as they call it in the Sprint book) ready to present to the group. After we went through everyone’s findings, we separated again so that each of us would come up with their own solutions and sketch them.

That’s one of the best things about the Design Sprint. Usually, people use brainstorming to find ideas. In a room full of people, you’ll always have someone taking over the conversation and people who don’t talk that much. So allowing everyone to express their ideas silently will get you more solutions. And since it’s an individual exercise, all have the flexibility of working on it in our own time and space. Convenient.

Day 3

On the next day, we all uploaded our solution sketches in InVision, and we voted on the parts we liked most by using the comments feature. It looked a lot like voting with dots on paper, the way you’d do it in an actual “same room” sprint. After prioritizing the solutions we voted on, we built a storyboard on our actual whiteboard in the office and reviewed it with everyone.

Day 4

Well, this was mostly my job. Having the storyboard, I built the prototype that we’d test with users. I had a full day to work on it, and we had a couple of meetings to review what I had done. In the end, we had a clickable InVision prototype, ready for users to play with.

“Day 5” — Testing

Normally this would be a full day of testing, having at least 5 users that go through your prototype while the team takes notes. With our timezone difference, that would have been almost impossible. We did schedule interviews over the next 2–3 days so that most of us could attend. It was a bit chaotic, but in the end, it worked. We had feedback!

Aftermath

So, did it make sense to chop up the process like this? Well, yes. I’m not saying it could replace an actual Design Sprint. Actually, even the stakeholders understood how much more valuable it would have been having everyone in the same room. But since this option wasn’t available at the time, having our compromise sprint was still a great start.

Testing with actual users provided us with some very good feedback. This didn’t really mean that our prototype and product were great already, but rather that we could understand where we made the wrong assumptions, and we could see what the users wanted and expected from the platform. In the end, most of our testing sessions turned into larger user interviews, and we gathered truly relevant data that would help us build the new feature.

Going through a full Design Sprint certainly pays off. We’re currently trying to integrate it as part of our process in any project. But every project and every stakeholder is different. As a process, a Design Sprint can and should be adapted to their needs. There’s no real recipe for building a product. It’s all about being able to adapt…and being creative about it.