Trying a Google Design Sprint
Reflections on a week with a Design Sprint
In my day to day work I mostly solve problems related to software development. A PO hands down a feature request and the team my team and I try to find the best solution to the problem and then implements it. I guess this is how software development are done many places.
But a couple of week ago I got to be part of a completely different process – a Google Design sprint. This is a process developed at Google and they describe it as:
The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers
This is starting a couple of big steps before I normally start problem solving. It was both a frustrating and fun week – and after a couple of weeks’ reflection I think I learned something about myself and the people around me.
On Monday, you’ll map out the problem and pick an important place to focus. On Tuesday, you’ll sketch competing solutions on paper. On Wednesday, you’ll make difficult decisions and turn your ideas into a testable hypothesis. On Thursday, you’ll hammer out a high-fidelity prototype. And on Friday, you’ll test it with real live humans.
The first day was way out of my comfort zone. We were presented whit an overall problem and should try to narrow the scope and find one place to create a solution. I find it very hard to assume a lot things about people that I not feel I have a lot in common with. I generally don’t like to talk if I don’t think I can bring something qualified to a discussion. On the other hand, some of the team members is very much the opposite of me, talking a lot and don’t mind saying the same thing multiple times to get their idea picked.
This was quite a difficult day for me because I didn’t felt like I contributed a lot and didn’t really like the solutions we found. That day I went home in not the best of moods.
The next days was getting better as we were getting closer to some concrete problems to solve, and I felt I could contribute a lot more.
The Crazy 8
This was a fun small exercise where you have to sketch out 8 solutions to a problem and you only have 1 minute for each. Our facilitator was feeling generous and gave us 2 minutes for each.
This IS a crazy exercise and you can almost not do anything in 2 minutes. Some of my solutions were useless, but I got to some solutions I would not have found if I had more time to think about it. And I released some creativity I didn’t knew I had.
I had not worked together with any of the other team members beforehand. I knew a couple of them and some of them were complete strangers. We were a mix of developers, designers and product persons. I like the close collaboration with other groups than my own profession. I very much enjoy working close together with other groups in a project, and the feedback loop gets very narrow – which is great.
This was my first exposure to the process and I don’t feel I can pass a final judgement on whether it works or not, but I have my sincere doubts.
This process favours the types of people who likes to talk and are dominating in a group. It’s not a good method for letting all ideas be heard.
Our high-fidelity prototype was not made to be tested on real humans, but instead to be shown to management (I know, I know – management are real humans too) to convince them we should continue the work afterwards. In my eyes if kind of invalidates the purpose of the process.
The following week management got back to us and told us they very much liked the idea! But they would like us to turn the focus of the solution 180 degrees and do a new prototype… Successful?
I might not be 100 percent satisfied with the process and the result, but I’m happy that I got to try this process.
It became obvious to me that my strength is not to find the problem to solve, but instead to solve a stated problem. I properly knew this beforehand, but it’s always great to test it. And from time to time it’s also great just to be thrown out in the deep end and have a project out of your comfort zone.