How I Run Design Sprint for 3 Different Startups in 5 Consecutive Days
I work at a startup studio. This is basically a studio-like company that aims to build several companies (startup). There are now 4 different startups under our name. I work as a UX researcher for those startups. My tasks include design sprint, usability testing, and user/market research.
My educational background is psychology. At first, I think psychology has nothing in common with design. Only after I worked as a UX researcher did I understand the relationship between the two. Design is more than art. Design is creating products that can solve problems. When I was in college, I learned about how humans behave and think. I also learned about thinking methods such as creative thinking and critical thinking. This is what underlies my understanding in the application of design thinking. Design thinking itself is a method of thinking that focuses on collaborative problem solving.
One method for implementing design thinking in organizations is through design sprint. Basically this is an event that lasts for 5 days where the development team tries to solve the problem at hand. The process is carried out by understanding the problem, finding as many solutions as possible, choosing the right options, making prototypes, and testing the prototype. One of the most popular Design Sprint methods was initiated by Jake Knapp from Google Ventures.
Design Sprint requires all team members, whether it’s product managers, designers, developers, or quality assurances — to sit together, leaving their tasks temporarily to focus on discussing existing problems. Ideally, this is a great thing, when the whole team can sit together and share the information they have about the products they build, but the reality is that there is always work to be done and deadlines that must be met.
So asking developers to leave their laptops, even in just 5 days, is quite difficult. Another obstacle is that sometimes problems are not big enough to give up 5 working days, but large enough to be resolved if only using conventional methods. That’s why after almost a year working as a UX researcher, trying to help startups solve the problems they face, I conclude that the Sprint Design method is not always suitable for every condition. Design Sprint requires too much effort and resources if we continue to implement it every time a startup finds a difficult problem.
At first I felt overwhelmed, having a psychology education background, with little — or no — knowledge of design or technology, and having to help startups solve the problems they face, I don’t know where to start, what to do, and what to expect.
Then I read Change by Design book by Tim Brown (CEO of Ideo). The book explains about design thinking (the flows, the method, the goal). It helps me understand how design sprint is made. So now, when a startup comes to me asking for help to solve their problem, what I do is analyze the problem. Does it require that we do a full design sprint or not. Does it worth the time, resources, and (sometimes) money to do a design sprint or not.
Sometimes the Product Manager comes to me not knowing what the real problem is. They don’t know what to do and ask me for help. This is when my psychology background really helped me do my job. I ask them to tell me their stories, the situations that they face, try to analyze the problem, help them gather as many solutions as possible, and then choose the solution based on impact and feasibility.
Design sprint is cool. It has been proven to help many startups launch innovative solution that can change the world. However, it cannot be implemented in every situation. The important thing is to understand the basic of Design Sprint, which is Design Thinking, and try to find the best and most suitable method to help startups solve problem.
