Design Dash: What, Why and How?
Explaining what exactly a Design Dash is, why it’s important, and how we are going to make it all happen in 5 days.
🤷 What is a Design Dash?
A Design Dash is a shortcut to learning.
This strategy is based on the 5 Day GV Design Sprint.
A typical work flow
Usually a project starts by reviewing the corresponding MVIs with a Project or Product Manager. The requirements are then broken up into tickets across multiple teams. Miscommunication tend to make this stage particularly complicated. If changes to requirements are not communicated clearly to everyone, teams may end up wasting efforts unnecessarily.
At this point designs are created, and then reviewed with Product owners. Typically additional edits to the design are needed.
Any edits are then made to the designs, and once it has been finalized, the development team begins coding. The build is then tested and released.
This whole work flow can take multiple months.
It is only once the design has been released to the public that the learning really begins.
The Design Dash work flow
In a Design Dash there is a dedicated group of people working on one problem. This team will establish the long term goals and list all the questions they have. Some of these unknowns may even be answered within the Dash team! By addressing the questions at the beginning, the team can collectively reach a mutual understanding. During the Design Dash the team will also interview experts about the problem which gives them an idea of where the opportunities lie. The team will then map, sketch and storyboard the entire user flow together so no pieces are left out.
The team will then create a prototype and user test their design.
This whole process only takes 3 days, and learning occurs at every stage.
🤷 Why we should Design Dash?
No context switching
Everyone knows context switching kills productivity. Having a dedicated team collaborating to solve a single problem provides both efficiency and allows the team to output quality work.
The DesignDash relies on constant communication between its members. Whether you are sketching or dot voting, the team is constantly aware of each others thoughts and ideas.
Decisions are make quickly
A huge problem in large businesses are the decision makers often don’t have full disclosure into all the complications that occur along the way. If a team discovers they are unable to meet one of their requirements, they have to explain the problem to the decision maker. If changes need to be made to the requirements of other teams, the decision maker needs to explain the problem again.
Since the decision makers are a part of the entire sprint, they are able to quickly make decisions that are well informed.
Everyone owns the project
The outcome of the Dash is a direct reflection of the team’s efforts. Everyone feels that their opinion has been expressed and taken into consideration. When the Dash is over, there are multiple people who have the same depth of understanding.
Learn fast and fail less
Although some “flashy” concepts can seem like a great idea at the time, this process will expose any pitfalls early on. By abandoning these ideas in the beginning, the team avoids wasting their time on over complicated concepts that provide little additional value.
🤷 How does a Design Dash work?
Day 1: Understanding
The first day is all about understanding the problem. The Design Dash team sets a Long Term Goal and writes out all the Questions they don’t have an answer to. The team then Interviews Experts on the problem to get an idea of their vision, any customer research, and/or previous efforts and technical limitations. The team then makes a Map of the possible user flows. By the end of Day 1 the Decider will have picked a Target to focus on.
Day 2: Creating the Story
The second day is all about creative problem solving. The Dash team will sketch possible solutions and then let their ideas speak for themselves. They will post their ideas up like an art gallery and the team will vote on their favourites. Once the decider has selected their favourite sketches, the team will begin creating a storyboard of how the user will encounter their product. By the end of Day 2 the team will have the wireframe for the prototype the Designer will create.
Day 3: Prototyping
During this time the Designer will create a Prototype based on the storyboard the team created on Day 2.
Day 4: Prototyping + Trial Run
By the end Day 4 the prototype should be ready to test. It is important that the team do a test run with the Dash Team to make sure no changes need to be made.
Day 5: User Testing
Day 5 is all about User Testing. During the user testing the team will be taking notes looking for patterns in behaviour.
At the end of Day 5 the team will organize the notes collected during the interviews, and summarize the patterns found. At this point the team will reflect on the Questions they asked on Day 1 and see how the outcome of the Dash aligned with their Long Term Goal.