Wouldn’t it be nice to own a time machine that lets you nip quickly over to the future to see if your service or product takes off or not? Google Design Sprints can really accomplish this, testing the viability of your new service in just four days.
For example, the goal of one of my first sprints my last Design Sprint was to create a new prototype for joining Estonian Governmental Data Exchange service X-road and help improve our country’s e-services even further. I led a full four-day Google Design Sprint, closing myself into a meeting room for a week with a six-member team from the Information System Authority (RIA). At the end of day four, a realistic prototype had been created tested on end-users.
But what is a Google Design Sprint?
As suggested by the name, Google Design Sprints originated from Google Ventures from around 2010 and begun as a software developing tool used to spur on projects that were stuck in a vicious circle of discuss-test-discuss. A product design process can take several months in an average company. The first half of the time is spent on business analyses, monitoring end-users, several discussions, workshops and the creation of service models, requirements and a prototype. From there, the prototype is handed over to a development team. What often happens is that the process returns to the discussion phase, additional information is considered and the process starts dragging on and on.
A Design Sprint, however, lets you have a quick look into the future by constructing a prototype product or service from scratch in just four days and testing it on real users. This allows for feedback on the potential of your solution before any money is spent on programming. Thus, the best definition is that a Design Sprint is a problem solving tool where teams can experiment with their solutions quickly and effectively.
A sprint that feels like a marathon
The Sprint lasts for four days and has been jokingly called the ironman of design. The Sprint is preceded by a preparation period where necessary information is gathered, challenges are agreed upon, a problem is worded as specifically as possible and a Sprint team is gathered. An ideal team would consist of up to seven people. The preferred team member roles are product owner and decider who has finances and power to develop service, lead programmer, sales, customer service and customer management specialists and a couple of other experts. One person can fit into several roles here, depending on the company and the challenges posed. It’s important to have the entire team take part in all the Sprint stages, which means having to take off almost a week from their main work. The Sprint leader has an important role as a specialist of the Design Sprint method as well as an experienced trainer and, ideally, a good designer who is able to create a prototype for testing.
So yes, it would be nice to own a time machine that lets you nip quickly over to the future to see if you need to contribute time and resources into developing your product in its current form.
Please see more case studies on our main page by clicking here