Recently I was asked to design and facilitate a workshop for a governmental institution. They were looking for a new online platform to promote and support their start-up innovation program. The initial aim was to use a user-validated brainstorm approach, like a (Google) Design Sprint, where we would generate and validate different platform concepts. However, during several conversations in preparation of the workshop, it turned out that it was not yet decided whether they would develop the platform from scratch or preferred to leverage an existing market solution.

Conducting a market consultation to explore what is available in the market can be a tedious exercise. I have experience with using Journey Maps and User Stories instead of creating long requirement lists. This makes a market consultation more user oriented, tangible and fun. That is how the idea popped-up; what if we use a Design Sprint to work towards a list of User Stories? This way we would be able to conduct a market consultation to explore possible alternatives, while at the same time getting a better understanding of our users, alignment of our own expectations and, above all, room to come-up with creative and innovative ideas.

What is a Design Sprint?

A Design Sprint is a five-day process for validating ideas and solving big challenges through prototyping and testing with (potential) users. Following the standard setup, the five days are roughly built up as follows:

1. Understand: Map out the problem and pick an important area to focus.
2. Ideate: Sketch out competing solutions.
3. Decide: Make decisions and turn your best idea(s) into a testable hypothesis.
4. Prototype: Build a realistic prototype together.
5. Test: Get feedback from target users.

One of the strongest aspects of a Design Sprint is the built-in feedback loop with (potential) users through a prototype. It allows you to validate possible solutions quickly and with little resources, thereby avoiding the common pitfall of pursuing a wrong direction for too long.

The downside is that you do need to make quick decisions in order to get to a testable prototype in a limited time. This makes it hard to explain the (underlying) decisions that were made during the Design Sprint to outsiders. As such, it is recommended to include decision makers in your Design Sprint team (next to engineers and designers) to ensure the outcome of the Design Sprint has a big enough support base within the organisation. However, this does not cater for the possible need to gather additional input and feedback from stakeholders who were not involved in the Design Sprint or, in this particular case, for setting out a market consultation.

Blending in Agile Scrum

Agile Scrum is a framework for developing, delivering, and sustaining complex products. It is an iterative, incremental and customer-first approach, focused on delivering tangible value as soon as possible (instead of focusing on documentation and negotiation). A key ingredient of the most common application of Agile Scrum is the User Story.

Agile Scrum and a Design Sprint start - and end - with the perspective of the user (customer) in mind. This overlap allows for a smooth transition from a standard Design Sprint - that aims to create a user-validated prototype - towards a customized workshop - with the goal of creating a structured list of user-stories.

In both approaches the focus is first on understanding the context and the user(s). From there, you diverge from and converge on a multitude of ideas and directions to form concrete solutions (concepts). The key difference between the two approaches lies in the last two steps. In a standard Design Sprint you work from a selected solution towards a prototype which you test (validate) with real users on the final day. In the customized workshop outlined below, you work from a selection of different ideas and solutions towards a prioritized list of user stories.

Mapping the different User Stories underneath the Journey Map

In short, the outline of the workshop is as follows:

Understand

• Define the Long Term Goal and (if desired) the Principles and Questions.
• Based on Expert and User Interviews one or more Empathy Maps are filled in.
• Based on the set Goal and the different personas from the Empathy Maps a Journey Map is created. Make sure to include all primary actors (personas) in the Journey.
• Define a focus based on the How Might We’s (HMW’s) captured during the Expert and User Interviews by making a voting-tree [optional].

Ideate

• Start with the Lighting Demo’s for additional inspiration and input.
• Each participant sketches out their individual ideal concept (4 steps: notes, ideate, crazy-8, solution sketch).

Decide

• Create the “Art-Museum” by placing all solution sketches on the wall. Ask the participants to go over each solution and put any questions they might have on distinct post-it’s. Different from the regular Design Sprint, there is no heat-map voting yet.
• The facilitator summarizes the different solutions and addresses any possible questions that were written down. Ask one of the participants to write down the big ideas during your summary [optional].
• Everyone votes for their favorite ideas within the different solutions via heat-map voting. There is no “super-vote” where the participants vote for their favorite solution.

Define

• Each participant transforms the ideas for their solution with (the most) votes into User Stories. Make sure these are all formatted in the same way: As a <Persona> I want to <Goal> so that < Reason>.
• Each participant reads/checks/adds User Stories for each-others solution [optional].
• Map the different User Stories on the applicable touchpoint(s) of the Journey Map. Remove possible duplications and re-write/merge/split User Stories where needed during this exercise.
• Check if there is a (important) part of the Journey Map which is not covered.

Prioritize

• Define different categories and order the User Stories in these buckets. This also allows the team to have one last validation on the quality and added value of the User Stories.
• Prioritize (high, medium, low) the User Stories.

After the workshop the facilitator translates the output of the workshop into a structured list (see below). All the different elements defined during the session (e.g. category, touchpoint, etc.) are captured in this list as part of the User Stories. The Journey Map with the different touchpoints is digitalized as a reference point for the User Stories on the list.

Snapshot of a few User Stories on the list

What we learned

Looking back, I expected the translation of the different ideas into User Stories by the participants to be difficult. However, this went surprisingly well. Because the format of a User Story is simple and we had clearly defined persona’s (users), nobody had a hard time making this translation.

However, there are a couple of points to take into consideration:

• During a normal Design Sprint you build and validate a prototype with actual users on the last day. This is a very powerful feedback mechanism. In the approach outlined here, the team interviews experts and users on the first day of the workshop, but there is no user validation afterwards.
• A User Story tells you what you want, not how it will be achieved. With translating sketched ideas and concepts into User Stories, you lose the “how”. The advantage gained here is that external parties can come-up with their own fitting solutions. At the same time, you have the risk of losing some good ideas from the participants along the way.
• Conducting the iterations with the team on the User Stories to get to a high quality and consistent list is intense. By using different ways of iterating (via rotating participants, using the journey map, introducing categories and applying a prioritization), you keep it engaging. However, we squeezed the workshop in two days, which made the last part a real pressure cooker.

How you can use the same approach

By blending Agile Scrum ingredients in a Design Sprint, we created an engaging, productive and inspirational workshop where we were able to generate a comprehensive list of desired features.

If you consider following a similar approach, I recommend the following:

• Use this approach only if there is a direct need to gain input and feedback from additional stakeholders other than the participants of the workshop, or if you plan to set up a market consultation.
• Combine it with a follow-up Design Sprint where you mix-in a selected external party and / or additional stakeholders after the initial market consultation / round of feedback.
• Make sure to reserve enough breathing space and time to get to a high quality and coherent list of User Stories, which is likely to require several iterations.

In this particular case, a structured list of user stories proved out to be way more valuable than a user-validated prototype. In other creative workshops, we worked towards a theater play to be able to show-case our ideal concept to a wider audience. Don’t be hesitant to mix-in different types of formats, frameworks and interventions.

What type of workshop-cocktails have you used in the past?