How To Organize a 3 Day Design Workshop inspired by Google Design Sprint
Running a design sprint requires preparation, research, and series of facilitation and workshops to nail down the problem. Prepping the overall experience involves going through a series of steps and validating findings and reserach with business stakeholders and users. Finding the right solutions to problems involves critical thinking, validations, primary and secondary research to do so. For my own banking project, I went through the necessary steps to establish the right solutions for a banking application.
Preparation: Kickoff, research and interviews
Before going into the specifics, organizing details such as planning user research interviews, business stakeholder interviews, and organizing a kickoff meeting in the beginning is essential. Make sure to communicate to the right departments such as marketing, engineering, and business so that all the important stakeholders are there for the sprint.
For the kickoff meeting, preparing a list of questions to ask such as:
What problem are we trying to solve?
Why are we solving the problem?
How are we going to solve the problem?
Where can we improve on existing solutions?
When are we going to meet and the deadlines?
Conducting primary research involves gathering findings from user research interviews to find out what the user finds painful and irritating in the existing product. Finding out what the user finds helpful and useful to them will enable them to have a more satisfying experience.
Finding out research about similar solutions related to your problem will help you understand the context of the user and how to improve on existing solutions. Know what the competitors lack and what their strong features are.
Planning the Sprint Schedule
Once the research, interviews and data is compiled for the project, we planned for three days to cover the design sprint. Some sprints might last for longer or shorter, but for this project we wanted to focus on the generation of ideas and establish a strategy for a banking app as we are in the very beginning of the project with certain constraints apparent.
For day one, I wanted to flesh out the details of where we need to focus on such as an overview of what we already know, long term goal, potential user journeys, and fleshing out what journeys we should be be prioritizing for the project. Along with these points, its a good opportunity to let the stakeholders ask some questions and for you to clarify on unknown constraints.
The second day is to show what kind of solutions and ideas the team can come up with and then based on those fast iterations and sketches we could hopefully decide on features and flows for each one of them. Its a team building activity to decide upon where to go forward based on voting and showing our ideas to the team.
Storyboarding the entire experience based on the main ideas that were derived from the day before. We decide on the final flows and experience that we should pursue in the next design of the wireframe
Define: Personas, Review goals, user journeys, user stories
Based on the research, personas need to be shown for the stakeholders to understand who we are targeting this product for and why they need to use the app. Showing the goals, user journeys and user stories will help business stakeholders understand more about the research that has been done.
Diverge: Sketching, Crazy 8’s, Heatmap Voting
This step involves getting the entire team togther to flesh out many different solutions to find the right one. For my scenario, we decided on three main stories as a team to sketch out. First, we sketched out all the possible ideas for one flow. Then we progressed into Crazy 8’s to select an idea and do different versions of the idea. From all the versions, pick the favorite one and sketch it out so that it can be easily and simple. From that, another designer and I would facilitate the conversation around each solution and pick out the best features.
Storyboarding the experience is one of the final stages for this design sprint as we gather all the favorite features from the stakeholders and compose a flow together. Based on the three flows that we have decided, I drew on the whiteboard what the experience would look like guiding through the stakeholders in the room for each interaction. This will ensure the stakeholders give enough feedback to establish a basic look and feel of the experience. There could be other ways to prototype such as using Invsion but for the interest of time we decided to whiteboard the experience instead.
Validate: Ongoing initiative after sprint
After storyboarding the experience, our team had enough insights, feedback, and recommendations to start designing a low fidelity prototype. Validation would be ongoing as each week there would be some meetings on iterations. But the flows that were done on the board would be a base for validation in the future
When running a design sprint, there needs to be some research derived of the initial problem in order to build your solution with different stakeholders in the project. Organizing a design sprint is a process and there is no one way to do it and also depends what the purpose of the design sprint is. For my design sprint, it was relatively short but we were able to flesh out a strategy and a starting point of what to build as a bank application. Going forward will be continuous iteration through business and user feedback based off our initial solution.