Design Sprint Done, Now What?

“As with every product/feature vision that is built as a prototype you always have to rethink what (parts) to build first afterwards. This implies that the delivered product is nearly never 100% close to the prototype” says Oliver Pitsch, Head of User Experience at Trusted Shops GmbH.

But wait, what are the outcomes of Design Sprints and, secondly, what to do with it?

Design sprint: A very short primer

A design sprint is a very hands-on way to explore solutions to a real problem, build and test it with real users. The design sprint is very similar to the design thinking process. However, the sprint was made to last one week, to start on Monday and to finish on Friday.

As for design thinking, design sprints can be used for any type of problem, whether in Smallco or Bigco. The sprint is meant to be an experiment for a problem at hand. It’s fast, iterative and about focus - insane focus. As with any innovation session, the team that drives the initiative is the most important part. A growing body of research shows that cultural diversity in teams make teams and its companies more creative. Alas, the more diverse the sprint team, the better, e.g. where expertise from finance, design, engineering come together. A group of about 6-8 people, practice shows, seems to be the best size.

As a short refresher, a sprint follows these steps:

1. Monday: Define a problem and ask the right questions
2. Tuesday: Generate a variety of potential solutions
3. Wednesday: Decide which idea to pursue for testing
4. Thursday: Build a quick and dirty prototype
5. Friday: Test it with real users

Outcomes of sprints

On the last day of the sprint your team will end the 5 days with one tested solution for the given problem. Alas, your team will have a fairly good understanding whether the solution they tested was well received or not. Furthermore, everyone involved will have discussed and thought through many other ideas that may solve the very problem at hand.

The main outcomes:

• A small group of potential evangelists or potential customers (the testers)
• A set of artefacts, whether that is around design, tech or process
• A (project) team that can work together well (or not so well)
• One solution tested, resulting in
  • (Very) positive feedback or
  • (Very) negative feedback

And many other solutions conceptualized, sketched out and discussed.

Different teams have different approaches and value these outcomes quite differently as we will see further down.

The team around Oliver Pitsch at Trusted Shops isn’t too much concerned about having something tangilbe in hand at the end of the sprint: “For us the outcome always would be rough-edge prototypes that work for the Friday interviews, nothing to really built out afterwards. The real outcome was alignment in the team about the product/feature we would not be working towards."

At IFM in Essen, Germany, UX designer Guido Schröder and his agile team actually use a lightweight “design sprint” in order to come up with interaction design concepts for specific (!) user epics. “We then take these concepts and do a ‘design and engineering workshop’ with the product owner and developers. Those colleagues then give their product and engineering critique to validate the concepts against their requirements and feasibility.” says Guido.

Testers, users or customers

In an ideal scenario, the testers who joined the sprint came out of the network or community your team or company already has. This would make it easier to acquire the same type or new testers for another testing session soon after. The team could test an improved version of the very same prototype with the same set of testers.

In our experience, a handful of testers who participated in the sprint testing won’t be available one or two weeks after the initial test. The only option here, therefore, is to recruit new users or customers. Not a bad thing, but more effort nonetheless.

The artefacts

What about the actual prototype, the thing that your team built (one way or another)?

Post-its are great but does their content survive the sprint?

If a prototype was tested negatively, the actual prototype can then act as reference material for any work that comes thereafter. If, though, all went well and the team got positive validation for a hypothesis, then that very prototype can, of course, be the source for any further development.

“Guido Schröder and his team actually use a lightweight design sprint in order to come up with interaction design concepts for specific user epics.”

It’s a given that, even if a testing session went well, the prototype needs much more work to clarify the initial assumptions, improve interactions or an adjustment of the use case. The part of the team that actually ran the testing session can welcome testers to join another round of testing one or two weeks thereafter.

The team

An important aspect of such an exercise is the fact that teams might not have worked together before. This is more likely the case in bigger companies than in smaller ones, naturally. To our experience, this is often overlooked or does not get enough attention.

Often, the sprint participants come together from different departments across the company (unless the company is relatively small). We recognize that it's easy to request a diverse team, but it's very hard indeed to commit 5 full days of everyone's time, especially in corporate environments where a sprint might require a senior/ manager level participants. That in itself is a huge commitment. The participation, though, is an indicator of faith that the Sprint methodology will deliver valuable results.

Then later on, depending on the type of problem that was addressed, it can be very beneficial for the project outcome that the team (or main parts of it) remains working together. But we notice the likeliness that this won’t be the case (esp. in bigger companies). We think that in regard to the outcome, the company has a real opportunity at hand to form a new project team. Granted that the participants get along well together, this team could make a real difference (for the project or long-term for the company).

Post-its are great but does their content survive the sprint?

The risk that the team (and potentially their solution) falls apart as they go back to their regular work after the actual sprint is indeed real. Oliver Pitsch added that “this is true in parts though. Yes, the CEO and Head of Sales”, for example, “return to their day jobs and do not actively push the product/feature further, but the insights and excitement gained from the Design Sprint always helped the product team a lot moving forward.”

“The remaining piece this puzzle would require is a truly committed (innovation) leader, someone with drive and perseverance,” says Yanna Vogiazou, “to keep pushing the process of experimentation in order to build better products and services.”

The solution

The most important aspect and the actual goal of the sprint is to come up with a solution to a problem that receives very positive feedback from real users. The stakeholders may ask after the sprint week: “Did it go well with users (or did it not)”? Of course, everyone expects the former. But is that actually the right question to ask?

Well, I think that there are two sides to this question:

1. If your team or stakeholder expect the outcome to be this stellar new product, then everyone is likely to be disappointed.
2. If your team or stakeholder only accepts a prototype/product/service to be tested positively (even if not a stellar new product), then the expectation isn’t set correctly.

Setting too high a bar (ie. a stellar new product) as the outcome of the sprint will mostly likely turn into a bummer, ie. it will disappoint the team. Why? If the stakeholders/sponsors expects a new stellar, earth-shattering product out of a 5-day innovation exercise, why would the sponsor then expect the team to work for them in the first place? Each team member could simply run their own 5-day sprint and then start their owns successful company (if it were that easy).

Setting too low a bar is apparently also not encouraging enough for the team, nor a valid initiative from an economic perspective. And furthermore, it would not require an exercise that expects 6-8 people to set aside 32 - 40 hours each (~200 - 250 hours per team/sprint).

It’s not the sprint that matters, it’s what you do after it’s done!

The real yardstick for the sprint is to ask whether the team was able to validate an hypothesis or assumption, whether good or bad. Yanna Vogiazou would add “to keep pushing the process of experimentation in order to build better products and services.” What we mean by this is the fact that even a negatively received prototype/solution produces value. A value which indicates whether a solution that “everyone wanted” did not work. How would you have known without testing?

Having validated a solution—that the team was convinced would fly, but did not—within one week ain’t too shabby to be disappointed about.

It's not the sprint that matters, it's what you do after it's done!

A hands-on conclusion

Where does this leave us? The combination of a solution that validates a team’s assumptions (whether expected or unexpected) and a team that potentially keeps working together is a real winner. This, of course, does not mean that the team is all set.

“The remaining piece this puzzle would require is a truly committed (innovation) leader, someone with drive and perseverance,” says Yanna Vogiazou, “to keep pushing the process of experimentation in order to build better products and services.” Additionally, she adds: “If you look at the methodology and the process, a Design Sprint does generate an outcome that can be taken further in a detailed design phase. It delivers a promising direction (but not a fully fleshed out solution) for follow-up design and customer validation work, saving time and effort”.

I personally would add that, as we outlined above, a promising direction does not mean that you got a winning solution in your hands. It may very well be a losing proposition but your team is surely one or two steps ahead in making the whole service or product a winning proposition.

Oliver adds great insight to this as well: “As with every product/feature vision that is built as a prototype you always have to rethink what (parts) to build first afterwards” he says. “Most prototypes I’ve seen show an entire process and can easily be cut into pieces for delivery. During that time things happen and this means that the delivered product is nearly never 100% close to the prototype. I think that’s a good sign you are doing it right.”