Or: Some Thoughts Pre-Rapid Ideation Sprint 1 and Sprint - A Kind of Book Review
Rapid ideation
Later this week, we’ll find out the theme for our first ‘rapid ideation sprint’. Essentially, what this means is that we’ll be given a topic – could be absolutely anything – then, over the next couple of weeks, we’ll create the prototype of an artefact of our choosing, linked in some way to said topic.
The idea is to get us practising the ideation and prototyping techniques we’ve been learning about throughout the Development Practice module so far. As well as that, though, the sprint is an opportunity to try out techniques or tools that appeal to us, hone certain crafts, explore particular theories, take risks, experiment, and work outside of our comfort zone.
The idea of a rapid sprint freaked me out at first. But, having stepped away for a bit and then come back to it with fresh eyes and a fresh mind, I’m starting to feel quite excited about it. It’ll be a good opportunity to see how things might come together – to practice some of the skills I’ve been learning to create a cohesive, if not fully fleshed-out, artefact. It’ll also be good to check in with myself as I go – to see how I’m feeling at different stages, and how I react when I (inevitably) come up against challenges or obstacles, whether that’s finding inspiration, getting my prototype into a reasonable shape, or managing my time properly so I don’t end up stressed and sad (very much not the point of any of this).
Sprint
I wanted to do at least some prep over the weekend before the theme is announced, but I wasn’t sure where to start. I began by getting stressed (not the vibe I’m going for; please see above), then I decided to have a look around Falmouth’s online library for a more positive starting point. I literally typed in ‘sprint’ (I’m original like that), and then clicked on the first result with a colourful picture next to the title (I’m also fickle like that).
That book happened to be Sprint: How to solve big problems and test new ideas in just five days by former Googler Jake Knapp. In a nutshell, the book outlines an hour-by-hour process – known as a ‘design sprint' – for going from ‘big question, no (adequate) answers’ to ‘testing a realistic, functioning prototype with real users’ over the course of just five days.
I’d come across the book before but hadn’t picked it up, dismissing it as 'not for me, ‘cos I can’t do that’. This time, I read it cover to cover – and was shocked to discover a swathe of inspiring real-life stories, concepts, guidance, and practical advice that’s left me genuinely excited to start a design sprint of my own.
What is a design sprint?
Design sprints are held over five consecutive days, usually a Monday to Friday, between 10am and 5pm. Before the sprint, you think about which ‘big question’ you’re going to focus on and gather your team together – usually around seven people from across different but relevant parts of the business.
On Monday, you think about your long-term goal and the questions that need to be answered in the sprint to help you achieve it. You then map out the customer journey you’re looking at, gather information from subject-matter experts on their parts of the journey, then decide on your target – the specific bit of the journey that you’re going to focus on for the next four days.
On Tuesday, you come up with solutions to your chosen challenge, brainstorming ideas the sketching out solutions based on all the information you’ve gathered so far. The group critiques the sketches on Wednesday morning before deciding on the preferred solution, which is then developed into a fleshed-out storyboard.
On Thursday, you turn your storyboard into a realistic prototype that’s then tested with 5 real users on Friday, giving you enough insights to know where to go next.
Design sprints vs. design thinking
The overlap between design sprints and the principles and stages of design thinking did strike me as I was reading through the book. In particular, the ‘Define’, ‘Ideate’, ‘Prototype’, and ‘Test’ stages of design thinking respectively map pretty well onto the ‘Map’, ‘Sketch’, ‘Prototype’, and ‘Test’ phases of the design sprint model.
Jake Knapp is the first to admit that he actively ‘stole’ ideas from both design thinking and agile methodologies when developing his design sprint model: “Like pretty much everything, [the idea behind design sprints] was stolen from other things that already existed [...] when I talk about stealing ideas for the design sprint, the bulk of those come from design thinking.” (Walter 2017)
For Knapp, though, the key difference is that, while design thinking often requires a team of experienced design experts in order to be effective, design sprints can be used by a team of people with different skill sets in different roles within a company. In other words, design sprints are designed to be accessible to everyone, including people without any design or design thinking experience. (ibid.)
One thing I'm still unsure about is how much research needs to be carried out before starting a design sprint. Is it acceptable or advisable to ‘go in cold’, with little more than a hunch about an idea that might work? Or is it better to have already gathered detailed insights into your users' needs, so that any new ideas you develop are already grounded in a solid understanding of what users are likely to find useful?
The ‘Empathise’ stage of the design thinking process doesn’t seem to come in properly until the end, at the same time as the ‘Test’ stage. However, you could also argue that adding empathy at the end of a week-long sprint is just as, if not more, effective for gaining an understanding as to whether an idea resonates with customers or not, provided that that idea is based on at least some information the company already has about its users and their pain points. One to ponder...
Design sprint for one
After finishing the book, I decided to set myself a challenge. For this first rapid ideation sprint, I’d like to try applying as much of the design sprint method as I can to my work as a solo practitioner. Given that design sprints are primarily (if not exclusively) designed for teams, this could prove quite tricky. However, there are plenty of ideas that I think could apply equally well to a UX team of one (a.k.a. little old me).
The design sprint approach already uses quite a few of the ideation and prototyping techniques we’ve come across in the Development Practice module so far, including brainstorming, Crazy 8s, and storyboards. It also introduces a fair few new ones, such as ‘How might we…?’ questions, ‘lightning demos’ (rapid presentations of inspirational solutions used by other companies both within and outside of your industry), and expert interviews (gathering information from a diverse range of voices with knowledge about a specific aspect of the customer journey).
Quite a few of these methods, including brainstorming and ‘How might we…?’ questions, are intended to be completed as solo activities within the sprint anyway. I could adapt the lightning demos session by creating collages or mood boards of inspiring solutions and making brief notes of what I like about each. And I could gather my own ‘experts’ for the theme in question in the form of TED talks, thought-leadership articles, and podcast episodes.
A lot of the activities do involve voting for preferred solutions, which may be tricky (what if I love/hate ALL of my ideas equally?), but I can give it a go. And in terms of prior user research that I can use as the basis for my design question, I can scour forums and comments sections on relevant websites to see if I can identify any pain points to develop solutions for.
I’ve set up a Trello board to help me track my time over the next couple of weeks, including a few activities I want to complete before the theme is announced. I’ve also treated myself to some new felt tips, a load of dot stickers, and about a tonne of paper (the flat’s already overflowing with Post-Its), so hopefully I’ve got all the equipment I need.
I’m going to try not to think too much more about my sprint challenge over the next couple of days, minus a few extra preparations (including making some big sheets of paper out of A4 and sticky tape, because it was cheaper than buying the big sheets in the first place…I’m in for a couple of fun evenings). The book comes with an extremely handy checklist, so I’m just going to plan each step around work and other life commitments, giving myself at least a few days to tie up any loose ends before we share our work with the rest of the group in a couple of weeks.
So, my sprint will be spread out over two weeks rather than five days, and I will be one rather than seven. But I will give it my best shot, and learn as much as I can.
A note on the importance of writing
One last thing I want to mention about Sprint for now. In the section on sketching solutions on Tuesday, the authors explicitly call out the importance of “strong writing[, which is] especially necessary for software and marketing where words often make up most of the screen” (Knapp 2016: 115).
They call “the importance of writing” a “surprising constant” that they’ve found in their years of experience conducting sprints with startups across a broad range of industries (ibid.). To me, the fact that they found it surprising that language is a crucial element of communication and understanding within a design context points to a broader underestimation of the power of words when it comes to helping people change their lives for the better, be it through an app, a poster, a website, or a simple reminder notification. All too often, the words that make up the interfaces that we use every day are seen as an afterthought, something to be filled in after the ‘real design work’ has been completed.
I was thrilled, then, to hear Jake Knapp talk more on his realisation about just how impactful words can be on the Design Better Podcast around a year after Sprint was published: “If you look at any UI, you basically can boil it down to text [...] the most important part of what we look at on any screen, anywhere, is the words. And if you get those words right, you’ve accomplished most of what has to happen.” (Walter 2017)
I couldn't agree more.
References
KNAPP, Jake, John Zeratsky Braden and Kowitz. 2016. Sprint: How to solve big problems and test new ideas in just five days. Simon & Schuster.
WALTER, Aarron, Elijah Woolery [hosts], and Jake Knapp [guest]. 2017. Design Better Podcast – Episode 8: Jake Knapp: beyond the Sprint. Available at: https://podcasts.apple.com/au/podcast/008-jake-knapp-beyond-the-sprint/id1266839739?i=1000392938133 [accessed 20 June 2022].
The Design Sprint website: https://www.thesprintbook.com/the-design-sprint [accessed 20 June 2022].
Comments