Design sprints 2.0

In Useberry, we love design sprints. We love doing them, discussing them, and obviously writing posts about them!

Our first post set the tone for the rest of the blog posts that we are going to be writing about this topic. If you want to reread our first post on design sprints you can find it here.

It is considered a fact that design sprints work. They have been excessively employed and tested by thousands of companies around the world anyway. But, as is usually the case, when a system or theory is tested over and over, specific patterns are identified; thus, this process finally leads to the optimization of this system (or theory) or the reformation of it. 

The Design sprints 2.0 update was suggested by AJ&Smart after completing, according to their words, something around 200 tests. But what exactly does this update mean to us? 

AJ&Smart believes that a shortening of the sprint will possibly yield better results for the companies because it will reduce fatigue, capitalize on the momentum and get things done faster. 

Now, since this post’s goal is not to convince you that you should (or shouldn’t) adopt the recent update, it is up to you to decide if it is something that will help you and your team. To optimize your decision we strongly suggest that you watch this video by Jake Knapp on when it is good to say no to design sprints 2.0.

Guide to Design Sprints 2.0

There is no particular change in the sprint essentials as they were defined in our first article. The recommended constitution of the team is again 5-7 people (called experts) with 2 being appointed as the decider and the facilitator. 

Before the update, the sprint’s required time for successful completion was 5 days (Monday to Friday). Now, the cycle is reduced to 4 days by combining some activities as we are going to see later on.

First day

The first day is again divided into 2 sessions (morning, afternoon) with the difference being that at the end of the day, 2 days instead of 1 are going to be completed as compared to the traditional theory. 

Morning

In the morning you begin as you would normally begin your sprint, doing the interviews and asking HMW questions. By completing this process faster, you then immediately go on to defining the long-term goal plus the sprint questions, and finally do the map (FYI the first update was first mapping and then defining the goal).

Afternoon

In the afternoon you actually do what you would normally do on the 2nd day of your traditional sprint. That is, doing the lighting demos and the 4 part sketching (take notes, come up with rough ideas, 8 variations or crazy 8’s, and concept realization).

That was it for the 1st (really intensive) day. 

Second day

The second day is also divided into 2 parts and you perform the activities of the 3rd day of the traditional sprints, speaking in an analogical sense. 

Morning

In the morning you have to do the presentations of the solutions, the voting process, and, of course, the decision making. 

Afternoon

Coming back from the break, you start elaborating on your recommended solution by designing all possible user flow steps.

Third day

The third day is the prototype day (4th in the traditional sprint) which is, in essence, the first depiction of the recommended solution. 

Final day

Testing the prototype. You want to make the tests with Useberry as they give by far the most advanced results and allow you to use your own prototype tool integrating all of them into a shared system called WebGL. You can start testing your prototypes now for free. I am confident that you are going to love it as much as I do.

Thoughts on design sprints 2.0

Okay, first things first. This new system, theory, framework, whatever you call it, was developed, IMO, for 2 very important reasons:

1. To reduce the amount of engagement needed by the people that constitute the team. Since the people that form the team are in general “experts” in their fields having them do meetings for an extra day implies an opportunity cost. Likewise, top management will get easily fatigued and this is something that should be avoided.
2. The other reason is that the team might become more efficient by the momentum that has been created and move quickly in the right direction.

This update has received some criticism (some of the potential pitfalls are implied above) but as you already know different things might work differently in different situations so we strongly suggest that you at least give this new update a try.