While being a challenge in itself, it also depends on the end user’s feedback, as we learn must what works and what can be improved. For example, it may be the case where reducing the number of features is the key to success. In that case, how can we better understand what the user needs? Is there a way to limit the risk and optimise the process? Design Sprint methodology may be the right tool for the job.
What is Design Sprint?
Let’s take a quick look at the process and concept behind Design Sprint. Pioneered at GV (former Google Ventures), Design Sprint is a five phase process within a fixed timeframe. Time is crucial here, due to its constraints as well as each of the phases’ objective. In a way, this new form of brainstorming turns into a framework for teams. A framework that uses design thinking to solve problems and test new solutions.
To put together a team, it is best to choose members with different areas of expertise, for example: engineers, designers, marketers or decision makers. Once the right team is chosen to run a Design Sprint, it is important to define a challenge along with a schedule. Design Sprints can take 2 to 5 days. Typically, one day is dedicated per phase.
A Design Sprint starts with the Understand/Review Phase – which includes a data review, mapping the problem and focussing on specific targets. The next day brings the Diverge Phase – a creative time for individual and team brainstorming, generating concepts, exploring possibilities, regardless of feasibility. After this, it’s time to narrow the ideas and chose the best solution – the Decide Phase. This is soon followed by Prototype Phase – where rapid prototyping allows users to test the ideas. However limited or inadequate the prototypes might seem after just one day, it would still be enough for testing and learning from the outcomes during the Validate Phase, where getting feedback from users and technical experts will enable validating of the solution. Depending on results the answer can lay the foundations towards a new 5-phase cycle or even a solution development and implementation.
There will be some cases where it may be possible to determine if demanded functionality is actually needed. In others, it could be about checking how certain functionality should be implemented. Or if the user interface is about to be changed; whether such updates aren’t too drastic and, in worst scenarios, would result in app usage loss. It may also be possible to find out how such changes should be introduced to users accustomed to current UI as well as how soon. Multiple scenarios are possible.
Ultimately one must think of Design Sprint as a tool that can save time and point projects towards the right direction. All the good ideas that are generated during such processes are worth a mention too as one of them could be invaluable for the product success at a later stage.
One should note that while Design Sprint is not about to overhaul current development processes, it does add significant value to product development. One may ask – how much will it actually help me? After all, it’s a long road between a prototype and the final product. Thanks to quick feedback at the end of a design sprint, it is possible to have more insight on which solution should be focused on. That may result in providing a better experience to the user, quality service and easier project maintenance.
The IT sector is reporting encouraging results in running Design Sprints and it may therefore be worthwhile taking an interest in the subject.
