5 Mistakes to avoid during your first design sprint

Dennis van Zuijlekom

Coming through 2016 with a newly-found sense of purpose as a result of UX specializations, UX practitioners around the globe have started making giant leaps in their own digital product designs. These leaps have manifested themselves through versions and variations of practices pioneered by Google and IDEO:Design Sprints. This is the evolution of the agile, lean, and scrum development methodologies, focused on design deliverables.

I was first introduced to design sprints by a colleague, and as with all great Google things; it sounded impossible at first. Some weeks later we discovered Jake Knapp’s book, as well as New Haircut’s Duco app, and we started to realize how much of a powerhouse tool this really was.

Our design teams have always managed 8 to 10 projects at the same time, much like any traditional agency, but we still generate enough flow throughout the projects to be able to talk openly and thoroughly about any of them (yeah, we don’t sleep much). Sadly though, our internal operation wasn’t quite ready for design sprints. Yet, something inside of us craved that sweet new Google tech.

>RELATED: The problem with UX & UI distinctions

The client, the tools and the problems

The time eventually came. A very traditional print store in our city approached us and decided it was time to immerse their operation in a digital transformation. Their challenge was fairly simple and their budget could support a full senior team of agile development. I immediately approached the team leader and talked him through the opportunity we had at our hands, reassuring him how well-proven this method was within Google Ventures and IDEO.

Sure enough, one week of planning, rapid client meetings, and many cups of Hindu Tea later, we were aboard our first design sprint.

Our client? The print store’s fired-up marketing director. The challenge? To provide an integrated e-commerce experience that allows users to solicit turns and print-order deliveries. The problems? No real communication with the client’s operations department, a very tight schedule, and no real internal company culture to support a 5-day immersion with a single client.

We prepared for the worst: Constant interruption, bored clients, no real insights inside a 5+ hour meeting, incomplete prototypes, insufficient testers, or really just anything that could potentially damage our air-tight workflow.

Fateful Monday came at last.

By Diego Luque

How day one fails

It all starts…

The end-goal proved to be highly ambitious as we set out to design and prototype and test three major interactions inside the platform we were redesigning:

1. Users must be able to solicit a turn from inside the platform and use it to get physical attention inside any of the client’s print stores.

2. Users will be able to upload, print, pay, and have delivered to their homes quick .pdf files that do not exceed certain limitations.

3. Users can navigate through a complete e-commerce experience with featured products and real-time shop inventories.

Our customer journey was a convoluted mess that we re-drafted five-six times. Following that, two of our interviewees failed to be available at the time of our Monday appointment, so we settled for a single, well-structured interview with the client’s marketing & advertising team.

All-in-all, day one ended with one of our senior UX designers partially asleep on the sprint table, a very messy customer journey drawn out over 4 pieces of big paper, and some light insights on the client’s marketing needs. I felt like crying on my way home.

What day five revealed

It all comes together…

Day five started with a very clean but incomplete prototype based on a storyboard we had managed to put together. It turns out that learning a new sketching software while prototyping at 10pm is not such a good idea (who knew?). So we decided to postpone the interviews and start them at 11am, giving us some time to make a trial run of the actual prototype, and set up all the necessary equipment for further analysis.

The interviews began and we started collecting data through three sequential actions that we asked each trial customer to follow, each one validating one of the three main purposes of the platform. At this point of exhaustion we were really just trying not to give in to sleep. Gladly, our faces changed rapidly as we saw the reaction of our first interviewee. His sense of excitement while exploring our product’s features was a glimpse of happiness we’d been needing for a while.

Five of our testers went by and we collectively realized, as soon as the last one walked out the door, that we could finally stop running. What had been a lightning week of producing user interactions like a clock, suddenly snapped into a huge breath of comfort. We found ourselves at the mountain top, now seeking the best view of the horizon.

What we learned

Our Take-Away and Mistakes:

1. Insufficient team communication prior to the sprint, leads to a terrible day one: Everybody needs to be onboard with the vision and excitement that the project and methodology require, otherwise they’ll just think it’s another long meeting they’re wasting time on (e.g. why nobody should fall asleep on the main table).
2. ‘Failure’ to acquire and retain sprint members is just bad planning: As a sprint master, your role is to plan ahead so that the team you assemble will be able to retain focus on the tasks at hand. Kindly remind everyone that wants your team’s attention that they’ll have some time at 5pm to answer any of their secondary requests. Be strict about your schedules and communicate them in advance.
3. Not knowing how to physically sketch a solution is not an excuse to avoid the process all together: Any member of the team who claims he does not know how to draw is lying. Everybody can contribute to the visual features, you just have to give them the right incentives. The only real reason they’re not doing it is because they’re ashamed of their skill, and that’s something you need to handle with tenure sensitivity.
4. Voting should happen when everybody understands the solutions presented on paper, not words: Voting on solutions is not a popularity contest, and therefore you must make sure everybody understands all the concepts before they cast their stickers on the folded papers. Make sure nobody establishes their point solely through speech. Solutions must be able to prove their own worth, without too much justification.
5. Thursday is gonna need all the extra help you can get: While 12–15 screens sound like an easy project for a complete day, you might be in for a wild surprise when you find out most of your initial ideas need some higher form of UX to actually convey themselves properly. Figma is a very cool little thing, and you probably know a few other designers that would love to help you out on your Google adventure. Learn the software and plan their time ahead as well.

How we grew from all of this

A team will only be as great as its leader…
Leading is a delicate activity. Misguide your members one time and they will struggle to regain their comfort on your guiding skills. Be sure you know all the sprint activities like a script before you launch yourself in front of the action.

There is time for readjustment (Wednesday is usually it).
Actually forging decisions will put a lot of pressure on any new decision maker in the team. Kindly remind the decision maker that Design Sprints usually find time to fit all the mess they create into an array of proper insights. For our case and other sprints we’ve run, Wednesday is usually a great catch-up point if you left any of the other days’ activities behind.

Begin digitizing the prototype as soon as possible.
The lead UI designer in my team had the idea of sketching our prototype as soon as the first storyboard draft was completed. Thanks to this, it was very easy for the team to produce all the main screens in draft mode with simple keywords to remind us what each screen should contain (Thanks Andy). This way, our impossible three-way prototype had a much better chance of coming to life in a single Thursday drill.

Settle for concrete challenges.
In hindsight, we settled on a challenge that was too big. We had to run additional sprint activities to validate a wide range of micro-interactions that got left out of the main prototype. As of now, I believe it is ten times better to prototype the hell out of a small user flow than to imitate our ambition.

I hope this article comes in handy for any aspiring and/or active UX designers who come into their first Design Sprint with no concrete idea of how to guide it. I want to thank my sprint team and the rest of our internal design team for helping out during stressful times and helping me keep a straight face throughout the whole ordeal. Below is a list of digital tools used during our sprint:

Day 1 interviews: Appear.in video software amazingly good streaming and simple interface.

Day 1 customer journey: Mindmeister.

Day 3 & 4 sketching: Sketch for the storyboard and the final UI design & Figma for collaborative sketching on thursday.

Day 3 & 4 design resources: Sketch app Sources.

For any additional guidance, New Haircut’s Duco app is a very handy tool during the preparation stage. Just try not to depend too much on it upon the actual sprint execution.

If you need any other resources, or if you just want to tell me some of your own design sprint stories, be sure to drop me an email: santiago.camargo@imaginamos.com.

Santiago Camargo, Product Owner / Consultor AX Imaginamos.