Scotch tape and sticky-notes. Sprinting, Singapore-style.
By Jeremy Brett, Product Design Director
This is a story about a GV style design sprint. If you’ve never heard of that, you can learn more here or read the book.
We’ve been trying to adopt more agile processes at GoBear since I joined as Product Design Director in January of this year. We’ve tried various things — creating a Product Team consisting of the managers of various Business and Experience functions, co-creation workshops with users, having the design team work a cycle ahead of the development team. Whatever we tried seemed to add to our processes, further silo our teams or simply not return on our time and effort in the way we had hoped. We just seemed too busy to be agile. With so much to do, how on earth could we do it any faster? And how could we, the ones who built these processes and workflows in the first place, fix them?
But, like that guy with the funny hair said, “We cannot solve our problems with the same thinking we used to create them”.
So when an MA student at the Hyper Island Singapore campus contacted me asking whether we had any ‘wicked’ problems that we wouldn’t mind sharing as the basis of her design thinking assignment, I jumped at the opportunity.
What question did you want to answer in your sprint?
Our UX Manager and I had a think about possible problems we could propose to our eager MA student. We were all too aware that we weren’t talking to users soon enough in our product development process and that design and UX was coming at the last mile, just before software development started, and not at the discovery phase, when the problems were being thrashed out.
Tackling both these seemed a tall order for sure, but management was supportive and the team was curious about the possibilities. We worked on re-framing the problem and came up with:
How might GoBear involve users from the very start and prototype ideas quickly and iteratively given that we would need to alter the way we work today and embrace a more experimental approach?
Our friendly Hyper Island student proposed running a design thinking workshop to tackle the problem head on. That seemed like a good idea but nagging in the back of my mind was some feeling that such a problem needed a slightly different approach.
I had some coffee, and maybe a donut, or two. And then it occurred to me, it wasn’t through lack of understanding of innovative methods that similar efforts had been less than successful in the past. Heck, we use design thinking techniques like co-creation, affinity mapping and prototyping all the time. Our problem was these weren’t being applied rigorously, in a prescriptive framework, with a cross-functional team. You know, like Scrum! If our development team could work efficiently and effectively in a framework, why couldn’t the Product and Design teams?
OK, so this is where things get a little bit meta.
We decided, why not demonstrate to the team the power of design thinking, within the prescriptive framework of a Design Sprint, by grabbing an idea from the backlog and sprinting with it?
So, that’s just what we did. We would round up Product Management and Product Design in the board room, our chirpy Hyper Islander would facilitate and nothing would ever be the same again.
Except. We only had one day.
I checked the Sprint book FAQ, and, well … it was pretty clear …
But we decided to give it a try anyway. If we got some learning and insights into the chosen backlog item, then great; if we didn’t, at least we will have tried to think differently about problems.
Oh, and management said they’d buy us pizza.
Who was on the sprint team?
The sprint team was made up of members from our Product and Experience teams. Our CXO, Ivonne Bojoh, was decider and our Hyper Island Masters student was the facilitator. Then there was me, our UX Manager, three Product Designers, a Product Manager and two Product Specialists.
How did you make your prototype?
One of the main goals was to get the designers and the product team working together on a problem, from the start, and then prototyping and validating a solution.
But when preparing for the sprint, the Facilitator was concerned about time and asked me did I really think we could manage discovery, framing, prototyping and testing all in one day.
Me: ‘Uh, sure … I think we can cobble together an Invision prototype and umm … yeah … the UX Manager might need to scramble to get some users in … I think …’
This was starting to sound like we’d bitten off more free pizza than we could chew …
Then she dropped the tinsel, craft-paper and post-it-note bombshell.
Her: ‘No. There is no time for InVision and no, you can’t invite users into your nice warm and fuzzy office. The whole point of the day is to get people out of their comfort zone and to start looking anew at how they work. That means getting out of the office. After lunch you will have about 30 minutes, in pairs, to put together paper and string prototypes and then go outside — Yes, outside of the building — and do some guerrilla testing on the streets.’
Me: ‘What?! Running around Singapore’s CBD with coloured paper and post-its! Are you nuts? I’m pretty sure the Sprint book says you have to do real-looking prototypes and besides, who is going to take a 30 minute sketch seriously?’
Her: ‘You’d be surprised.’
I swear she said that with Uncle Rick’s voice.
What did you learn from the test?
So, we did it. We spent the morning framing and mapping. We sketched over pizza at lunch time. Then we split into pairs, with a designer in each pair, and each pair made one rapid craft paper, seat-of-the-pants prototype.
And it was amazing.
Lo and behold, not one person we doorstepped on the street laughed at the sticky notes and scotch tape. Instead, they were immediately engaged by the problem, instead of the look and feel. Feedback and insights flowed.
My mind was blown.
What’s next for your project?
Our one-day hyper sprint was a runaway success. The team immediately saw the value of working cross-functionally and prototyping early in the process. But the biggest take away was the value we got from our guerrilla testing. Instead of days spent drafting and re-drafting high-fidelity prototypes on Sketch and InVision, the team had received invaluable user feedback at almost no cost.
We took all the day’s insights and iterated. One week later we had our immaculate InVision prototype in the lab wowing users. And there was almost no re-drafting required as the team had kicked off, discovered and framed the problem together from the start.
If this is the outcome of a single day, we can’t wait to take the next problem on and run it through the full 5 days.
We will definitely be needing more pizza.
And scotch tape.
