Design sprints at DockYard are based on the Google Ventures model, but with a shorter four-day duration. Design Discovery (the research and strategy phase that enables us test and plan out the entire application before proceeding with Visual Design and Engineering) lasts several weeks, and has a greater scope.
While each process has its individual benefits, there are many that they share. In both cases, of Design Sprints and Discovery, we share work with the client early and often. This quick turnaround requires close attention and abstract thinking from the client (for example, evaluating an idea in sketch form rather than fully resolved designs). The benefit is that we course-correct quickly and eliminate alternatives early on.
The difference is in the scope, end objective, and the deliverables. A design sprint can encompass a specific aspect of a product. It’s a highly collaborative and budget friendly way to spike on an idea. Design discovery is a holistic approach to goals and strategy for a product.
What sprints are good for
The purpose of a sprint is not to deliver a whole product, but a realistic model of a product experience. In a few cases a product experience may be small and focused enough to be encompassed entirely in the sprint. More likely, a design sprint focuses on a specific aspect of an application, and a single user story.
A sprint might address a question like “how would a new user sign up for your service on a mobile phone?” or “In what ways could an existing customer use the web service you’re building in the course of their day?” A sprint is a rapid way to model and test specific situations, so that the product can be refined. In order to run a sprint, we make reasonable assumptions about a situation around your product, and then isolate, model, and test a them.
What a sprint looks like
Here’s what a design sprint might look like at DockYard. Let’s imagine a product that helps customers know when a farm share they purchased would be delivered.
- For the sprint, we would be focusing on sending and receiving messages between a delivery driver and a customer.
- We would only focus on the mobile view of this interaction (with an informed assumption that it’s the most convenient context for checking up on a delivery)
Monday: analyze the context
We kick off the sprint by analyzing the situation around the delivery. Who are our users? What problems do they encounter, and which ones can we help them solve?
By the end of the day, we expect to diagram the portion of a customer’s experience receiving a delivery, and any actions they might take along the way.
Tuesday: sketch and define
On day two we take the workflow we already defined and turn it into a series of hand-sketched wireframes. In this process, additional details become clear and we move toward a standardized approach to similar screens. We define a series of messages between the customer and the delivery driver as the key interaction.
Wednesday: design and prototype
On day three, we translate the sketches into visual design. We design the key screens for the messaging interaction and create a minimal prototype to test drive how the messaging app might feel.
Thursday: test and refine
On the final day, we run several quick user tests with potential customers. We give test users a scenario like “your delivery is coming - use the app to check on its arrival!” and observe how they interact with the prototype. We record any lessons learned - e.g. “user assumed the button was inactive”.
We then make any quick corrections based on the results of user testing (like making the button appear more active) and document what we learned as potential improvements or things to explore in the future.
The result of a sprint in this case is a working prototype of messaging for our specific use case, and an understanding of what role this key interaction plays within the larger context of the app.
Picking between Sprint and Discovery
To decide which design process is right, consider the job each process does well.
A sprint quickly illuminates a specific aspect of your product, for example, a single user story. A series of sprints could produce a full picture, but at some point a Discovery approach becomes more effective.
Sprints result in prototypes of your product or parts of it, and allow you to test things quickly. They are most efficient for solving shorter term business goals: validating or iterating quickly on a function of an application.
Discovery usually requires more time and resources, but shows the larger picture.
The combination of design discovery and visual design is a holistic process. It is a better investment in cases where you’re developing a new product, or have long term business goals and would like an investigation from all angles into how to achieve them.
If you have a specific question in mind, contact us. We’ll set up a short consultation meeting so we can help find out which process is right for you.
