Twitter Reddit LinkedIn Facebook

This article appeared first on

• • •

“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. 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.

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

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. What the real outcome was Alignment in the team about the product/feature we would not be working towards. We will also get to this aspect in a minute.

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? 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?

Continue Reading on →

Twitter Reddit LinkedIn Facebook