Google Design Sprint is briskly gaining ground in IT industry and becoming an inherent item in UX tools set. The framework is just made for software development with its 5-day product design process enabling to quickly create a testable prototype. But as in all design methodologies there are also challenges we need to face while implementing GDS. We asked Jule Helal from Delodi and Maria Borowy, our UX Designer who conducted together a design workshop based on Google's framework how to do it successfuly and what you should consider if you decided to use it.
What is Google Design Sprint (GDS)?
Jule Helal (JH): The sprint is a five-day product design process for answering critical business questions through design, prototyping, and testing ideas with customers. Google Ventures came up with this set of methods first and it’s been used in many variations, to help teams sharpen and test their ideas.
Maria Borowy (MB): Google Design Sprint framework divides the design process into five days. We start with the analysis of the problem then we generate ideas to solve that problem. Because we need to select the final solution to the test, in the middle of the week we work on priorities, structure and make decisions. The fourth day is devoted to prototyping and the last day to tests. In that way, we cover the whole process and at the end of the week, we know what we can improve.
How does it differ from other design methodologies?
JH: It’s very targeted on prototyping and testing an idea, so it's perfect in business development and innovation context.
MB: It is also very useful in the Agile environment. The team can verify the idea or solution before programming. The whole process could be adapted to the development schedule.
Why Google Design Sprint is so popular in the IT industry?
JH: Markets in IT change rapidly and so do customers’ needs. The GDS makes it possible to create a testable prototype and verify an idea very fast so the development process can start and the product can be launched quickly.
What are the main advantages and disadvantages of this method?
MB: If it comes to advantages, apart from mentioned above fast verification of the idea, Design Sprint enables the team to get to know the product better. This can speed up the whole design and development process. As a disadvantage, I can point out the necessity of good planning. The other disadvantage or rather challenge is to convince clients to one-week long design workshops. Some are not convinced of the idea of devoting 5 days for something different than UI design or development. For those, who use this methodology it is obvious that this approach saves a lot of time and money that could be spent on needless or too expensive solutions.
How did you plan the workshops and the agenda? Did you follow strictly to the plan defined by GDS?
JH: There is a very detailed description of GV about a 5-day-sprint, which makes it easy for not so experienced facilitators. But these defined parameters are not always reality, i.e. clients give you only a 2-day slot for the workshop, or the group is not thinking about a new idea but evaluating existing products. Then facilitators need to adapt the process to the clients’ needs and then it's more about knowing your methods than about following the defined process. We are working agile at Delodi, so it is our daily business to find the best suitable way and constantly improve our own processes, and that is why we like the method-set of GDS and we create an individual workshop structure for all needs. This is also what we did for our client here!
Who took part in the design workshop?
JH: In general interdisciplinary teams create the best results because all views on the product as well as internal needs can be brought into the prototype. That is also what we had in our design workshop.
MB: The best approach is to invite real users for the session. In this case, we worked with people who represented different departments of the client company and with target users of the final solution.
How did participants create prototypes?
MB: We started with the sketches of the solution. Participants could discuss it before the prototyping began.
JH: We love the UX tool - moqups to create interfaces for testing. Here also technically inexperienced teams can create a clickable prototype and make it look like it was a “real” piece of software. But there are many ways to create a prototype, from a simple list of phone numbers to pitch the product to a coded interface.
Weren’t you afraid to leave the designing process to employees without professional design experience?
JH: No, because the workshop was about sharpening the concept and make the ideas of future users visible. A shiny surface can cover up insufficient concepts, but a good concept can convince users without much design.
What is the role of a professional designer in the process then?
JH: A design will come as a next step, to excite users even more. But the core and flow of the software are set so the designer can focus on UX without being an expert on every detail of the client work field.
MB: The best ideas are generated within the interdisciplinary teams. Different points of views, expertise, and experience can bring very fruitful results. The designer can’t be an expert in all fields that is why he or she should listen, observe, learn and eventually shape the final product.
And what about the moderator? What was your responsibility?
JH: The moderators are on the one hand responsible for the meta layer, they decide about the goal for a day which points to the goal of the whole design workshop. On the base of this, they decide about methods the participants will be guided through. And within every minute of the workshop day, they are responsible to lead discussions, ask a lot and adjust the plan if the group needs it. This can be because of an unexpected topic that needs to be discussed or if a group works very fast and there is room for more. In general, the moderator gives the frame within the participants create the content.
What was the outcome of the workshop session?
MB: First of all we and the client get a solid confirmation of the main idea of the project. Target clients gave very useful feedback about the functionalities. Moreover, during the interviews, users shared a lot of information about their experience and problems. The result of the whole Design Sprint was a prototype with a list of improvements that should be done in the final version.
What kind of difficulties you and participants met during the workshop?
JH: Our biggest difficulty was the language, as the participants spoke mostly polish in discussions, it was not possible for us to follow and lead them. Luckily we had Maria with us, who was perfectly doing this job!
MB: Another challenge was to keep the schedule. Our participants were really great. They were energetic and full of enthusiasm. Their discussions were very dynamic but we had to keep to the agenda so moderation work was crucial here.
Has something surprised you?
JH: The group was very good and they had a lot of ideas. This is not always the case, so it was fun, also for us as facilitators. The mentioned difficulties with language skills did not have any negative result on the dynamic of the workshop, what we feared in advance.
MB: Before the workshops, I wasn’t sure about the flow of the workshop that is conducted in two languages (or rather three: German, Polish, and English). Surprisingly it was really smooth. Together with Jule and Niklas from Delodi, we managed to communicate with this multilanguage group of people and cooperate as a team.
I am also impressed by the energy participants had through the whole 5 days of workshops. In spite of intensive work, they were truly engaged and this energy has a positive impact on us as well.