Remote design sprints - Lessons from a brave new remote world (Agile Manchester).pptx
•Download as PPTX, PDF•
0 likes•114 views
Design sprints are a fantastic way for teams to rapidly explore a challenge, to come up with some potential solutions and to test these with users. However, the classic 5-day design sprint assumes that everyone is in the same room. What if this isn’t possible? In this informative presentation from Agile Manchester 2023 you'll learn about 10 key lessons from 2 remote design sprints. You’ll find what worked, what didn’t work, when it makes sense to run a remote design sprint and come away with enough knowledge to run your own one.
Recommended
Recommended
More Related Content
Similar to Remote design sprints - Lessons from a brave new remote world (Agile Manchester).pptx
Similar to Remote design sprints - Lessons from a brave new remote world (Agile Manchester).pptx (20)
More from Neil Turner
More from Neil Turner (20)
Recently uploaded
Recently uploaded (20)
Remote design sprints - Lessons from a brave new remote world (Agile Manchester).pptx
- 1. REMOTE DESIGN SPRINTS - LESSONS FROM A BRAVE NEIL TURNER NEW (REMOTE) WORLD Image by Pete Linforth from Pixabay
- 3. REMOTE DESIGN SPRINTS • What is a design sprint? • Remote design sprints vs in-person • When to run a remote design sprint • Lessons from remote design sprints • Where to find out more
- 7. WHAT IS A DESIGN SPRINT?
- 8. “A design sprint is a time-constrained process that uses design thinking with the aim of reducing the risk when bringing a new product, service or a feature to the market.” Wikipedia
- 13. “I’ve heard stories of people running successful remote sprints, but to be honest, I never totally believed it. Part of the sprint magic is being in the same room.” Jake Knapp Author of Sprint
- 16. How can we add better support enterprise customers? How can we make it easier for new users to get started?
- 19. WHEN TO RUN A REMOTE DESIGN SPRINT
- 21. In-person Remote Distributed team Lots of stakeholders Open-ended problem No remote experience
- 23. IN-PERSON REMOTE
- 24. 10 LESSONS FROM 2 X REMOTE DESIGN SPRINTS
- 25. Jeff Bazos “If you can’t feed a meeting with two pizzas, it’s too large.”
- 26. ENTERPRISE DESIGN SPRINT ONBOARDING DESIGN SPRINT
- 27. TIPS FOR REMOTE DESIGN SPRINTS 1. Keep numbers small e.g. 5-8
- 28. 4-DAYS ENTERPRISE DESIGN SPRINT ONBOARDING DESIGN SPRINT
- 32. TIPS FOR REMOTE DESIGN SPRINTS 1. Keep numbers small 2. Split over 2-weeks
- 34. ENTERPRISE DESIGN SPRINT ONBOARDING DESIGN SPRINT
- 35. TIPS FOR REMOTE DESIGN SPRINTS 1. Keep numbers small 2. Split over 2-weeks 3. Have a mix of sync and async activities
- 37. ENTERPRISE DESIGN SPRINT ONBOARDING DESIGN SPRINT
- 38. TIPS FOR REMOTE DESIGN SPRINTS 1. Keep numbers small 2. Split over 2-weeks 3. Have a mix of sync and async activities 4. Keep remote sessions short
- 40. ENTERPRISE DESIGN SPRINT ONBOARDING DESIGN SPRINT
- 41. TIPS FOR REMOTE DESIGN SPRINTS 1. Keep numbers small 2. Split over 2-weeks 3. Have a mix of sync and async activities 4. Keep remote sessions short 5. Have a co-facilitator(s)
- 43. ENTERPRISE DESIGN SPRINT ONBOARDING DESIGN SPRINT
- 44. TIPS FOR REMOTE DESIGN SPRINTS 6. Use pairs over groups
- 49. TIPS FOR REMOTE DESIGN SPRINTS 6. Use pairs over groups 7. Prepare material & brief participants
- 54. TIPS FOR REMOTE DESIGN SPRINTS 6. Use pairs over groups 7. Prepare material & brief participants 8. Set house rules
- 56. ENTERPRISE DESIGN SPRINT ONBOARDING DESIGN SPRINT PowerPoint
- 57. TIPS FOR REMOTE DESIGN SPRINTS 6. Use pairs over groups 7. Prepare material & brief participants 8. Set house rules 9. Utilise remote collaboration tools
- 59. ENTERPRISE DESIGN SPRINT ONBOARDING DESIGN SPRINT
- 60. TIPS FOR REMOTE DESIGN SPRINTS 6. Use pairs over groups 7. Prepare material & brief participants 8. Set house rules 9. Utilise remote collaboration tools 10. Provide updates during sprints
- 61. CAN REMOTE DESIGN SPRINTS WORK?
- 62. “Remote Design Sprints work! People have done remote Design Sprints literally thousands of times with great outcomes.” Jake Knapp Author of Sprint & The Remote Design Sprint Guide
- 65. SUMMARY
- 67. TIPS FOR REMOTE DESIGN SPRINTS 1. Keep numbers small e.g. 5-8 2. Split over 2-weeks 3. Have a mix of sync and async activities 4. Keep remote sessions short 5. Have a co-facilitator(s)
- 68. TIPS FOR REMOTE DESIGN SPRINTS 6. Use pairs over groups 7. Prepare material & brief participants 8. Set house rules 9. Utilise remote collaboration tools 10. Provide updates during sprints
Editor's Notes
- Thank you for joining me I’m going to talk about remote design sprints But first, I should introduce myself
- I’m Neil Turner Lead product designer at Redgate software in Cambridge, UK Designing and developing software for database development and management So, what am I going to cover today?
- What is a design sprint When to run a remote design sprint as opposed to in-person Lessons I’ve learnt from running 2 remote design sprints at Redgate And finally where to go to find out more about remote design sprints But first I have a number of questions for you…
- Firstly here we are in Manchester, home to Manchester United and City, two of the biggest football clubs in the world Even if you’re not a football fan, I suspect most of you have watched a game of football, even if it’s only every 4 years at the World Cup So, I’ve got two options for you: You can either watch a game of football at the stadium, or in the comfort of your own home Stand up, who would rather watch at the stadium? Stand up , who would rather watch at home?
- Manchester is also home to amazing bands like The Stone Roses, Oasis and The Smiths Given the choice of going to a live concert, or watching a concert on TV Who would rather go to a live concert? Who would rather watch in the comfort of their own home?
- I’ve got a third set of questions for you.. Given the choice of doing a workshop in-person, or remotely Who would rather take part in a face-to-face workshop? Who would rather take part in a remote workshop? So clearly somethings are better in-person, is the same true of design sprints? Before we explore that I’ll talk a little about what a design sprint is
- Hands up who has taken part in a design sprint?
- Wikipedia defines a design sprint as…. A time-constrained process that uses design thinking with the aim of reducing the risk when bringing a new product, service or a feature to the market
- Design sprints are nothing especially new, teams have been doing design sprint type activities for years Don’t believe me, check out the video from 1999 of the design team at IDEO, the famous American design consultancy doing a week long exercise to redesign shopping carts They call it a deep dive, but it has all the hallmarks of a what we would now call a design sprint
- The term design sprint comes from Jake Knapp’s sprint book Jake was a designer and start-up advisor at Google He wanted a playbook that teams could use to rapidly tackle a design challenge He and his team came up with the sprint, A way for team to supposedly solve big problems and test new ideas in just 5 days
- As per the Sprint book, design sprints are spread over 5 days They are run in-person, with teams spending the week Choosing which part of a problem to focus on Coming up with potential solutions Generating a protype to test ideas And then testing those ideas with target customers
- I’m a big fan of design sprints I’ve run them with success with a number of teams and with a number of companies I’ve worked at, including Redgate They can indeed be a great way to tackle problems But, given that design sprints were designed to be carried out in-person, can they still work when done remotely?
- Jake Knapp himself doesn’t seem so sure… As he says: “I’ve heard stories of people running successful remote sprints, but to be honest, I never totally believed it. Part of the sprint magic is being in the same room”.
- I was soon soon to find out because thanks to Covid carrying out an in-person design sprint was no longer an option
- With the Redgate office closed following the Covid pandemic I was forced to run two remote design sprints I’ll briefly run through these 2 design sprints and then cover 10 key lessons I learnt running them
- Those 2 remote design sprints were tackling different problems The first design sprint was exploring how to better support enterprise customers and their needs for one of Redgate’s largest products I’ll refer to this as the enterprise design sprint The second was exploring how to make it easier for new users of Redgate products to get started I’ll refer to this as the onboarding design sprint
- Each design sprint was carried out completely remotely using Zoom Each design sprint had a cross functional team of designers, engineers and product managers
- And each design sprint heavily utilised Mural, an online collaboration tool as a virtual whiteboard
- Before I go through the key lessons learnt let’s talk about when to run And maybe when not to run remote design sprints
- We looked before at whether we’d all rather take part in a workshop in-person, or remotely My personal preference would always be for an in-person workshop However, just like watching football, or a concert in-person isn’t always better There are times when doing things remotely makes more sense Let’s look at when this might be the case for remote design sprints
- The most obvious one is if you have a distributed team For example, I’ve previously worked at organisations where you’re often collaborating with people from all over the world It can be expensive, disruptive and not to mention bad for the environment to fly people from all over the world for a design sprint A better alternative is to run a remote design sprint If there are lots of stakeholders then it can often be easier to bring them into a remote design sprint as they are only a mouse click away from joining When is it not a good idea to run remote design sprints? Very open-ended problems lend themselves more to in-person sprints because they will require a lot more synchronous collaboration, which is easier to do in-person It’s also a bad idea to run a remote design sprint with a team who have little or no remote experience Although given I suspect everyone now has lots of remote experience, I suspect that is now rarely the case
- Rather than one or other, it can be a great idea to combine the two by taking a hybrid approach Carry out some of the design sprint in-person And some of the design sprint remotely This way you can get the best of both
- For example, you might have the first part of the design sprint in-person This is when there is the greatest need for collaboration, which is easier in-person The second part of the design sprint, building a prototype and testing with target users could be done remotely With remote design tools like Figma, and remote user testing it can be easier to do this part of the design sprint remotely
- So, assuming that it makes sense to run a remote design sprint What are some of the things to think about? Here are 10 key lessons that I learnt from the 2 remote design sprints that I’ve spoken of
- Hands up who has heard of Jeff Bazos’s famous two pizza principle for meetings? “If you can’t feed a meeting with 2 pizzas, it’s too large” You’d have thought that one of the world’s richest people would be willing to buy more than 2 pizzas for a meeting But Jeff does have a point, you don’t want too many people are your meetings, otherwise it becomes unwieldy The same is true of remote design sprints
- Both remote design sprints had relatively small teams 6 for the enterprise sprint, 8 for the onboarding sprint Jeff will be delighted to know that you should be able to feed both teams with 2 pizzas In fact, I’d say that a small team is even more important for a remote design sprint than in-person Because collaboration becomes harder the more people you add for remote workshops over in-person
- Which brings me to my first tip for remote design sprints: Keep numbers as small as possible 5-8 is a good range to aim for
- One of the key differences between the two remote sprints was the duration The enterprise sprint was run over 2 weeks, where as the onboarding sprint was over 4 days The main reasoning behind a 2 week sprint was an acknowledgement that it takes longer to do things as a team remotely This was also the first remote design sprint I’d done, so I wanted to give the team a bit more time to try things out
- Having the second week available for prototyping and testing allows for a more realistic prototype to be created And tested with users
- Cramming everything into 4 or 5 days can make the prototyping and test feel very rushed If anyone remembers scrapheap challenge on Channel 4 In scrapheap challenge teams had a few days to create a vehicle or device out of scrap A 1 week remote design sprint can feel like this Teams have to create a realistic protype in hours, rather than days This invariably leads to very scrappy prototypes Sure you’re going to get feedback from these sorts of prototypes, but not as much as something more realistic
- Splitting a remote design sprint over 2 weeks also allows tests with customers to be trialled and iterated Rather than having 1 shot, teams can carry out a practice run, iron out any issues And even make changes for the second round of testing
- So my second tip for remote design sprints Is to split the design sprint over 2-weeks if possible The first week should be focused on exploring the problem Identifying what to focus on And deciding the best ideas to test The second week can then focus on creating a realistic prototype And testing this with users over a number of days
- When you are running a remote design sprint You can have synchronous activities, such as workshops and collaborative design sessions Or Asynchronous activities, typically where you divide and conquer tasks and then come together as a group to discuss For example, you might split up to look at competing solutions and then get together to discuss as a group
- For the first enterprise sprint the majority of activities were synchronous This can be mentally quite taxing when working remotely So for the second remote design sprint we had more of a mixture of synchronous and asynchronous activities For example, agreeing the basic flow for the prototype so that the team could go away and work on their pages This approach worked well and whilst I think it makes sense to have workshops for most activities when carrying out a design sprint in-person For remote design sprints I would recommend more asynchronous activities
- So my third tip is to have a mixture of synchronous and asynchronous activities Think about what you have to do synchronously If you don’t have to do something synchronously, aim to do it, or at least part of it asynchronously
- Remember we looked at remote vs in-person workshops One thing that I personally find with remote workshops is that they are mentally more taxing than in-person workshops
- This is certainly something that I noticed for the first design sprint So for the onboarding sprint we had shorter sessions, with more breaks to help keep energy levels high For example, going no longer than 45 minutes without a break Having more of a mix of synchronous and asynchronous sessions also helped
- So my fourth tip is To keep remote sessions short Ideally you should have a short break every 45 to 60 minutes
- Facilitating an in-person design sprint is hard, but facilitating a remote design sprint is even harder You can’t easily read the room to see how things are going There is the technology barrier of having to use a digital board collaboration tool such as Mural or Miro You might want to split larger groups into smaller groups, something much harder to do remotely than in-person
- It’s therefore a great idea to have a co-facilitator for remote design sprints This makes it easier to run activities, and to generally keep things running I didn’t have a co-facilitator for the first remote design sprint Whilst I didn’t have a permanent co-facilitator for the second remote design sprint I did get help with some of the activities that required more facilitation
- So if you can, I’d definitely recommend organising a co-facilitator or co-faciliators for remote design sprints
- I’ve already mentioned that doing things remotely can be mentally and even physically very taxing The truth is that humans have not evolved to do things over a computer screen We naturally communicate face-to-face, and even video calls can feel quite unnatural
- For the first remote design sprint we did a lot of activities as a group of 6 We changed approach for the second remote design sprint by carrying out more activities in pairs, or even asynchronously For example, reviewing competing solutions in pairs, rather than as a group
- Whilst there are lots of things that should be done as a group, I’d recommend using pairs over groups where possible
- When it comes to design sprints planning is very important As the old saying goes, failing to plan is planning to fail I think this is especially important for remote design sprints which typically require more planning because it’s much hard to make it up as you go along
- Some of the key planning for both remote design sprints included Creating briefing material before the design sprints And kick off sessions at the start to build a shared understanding of the problem And of the goals, scope and plan
- I also spent considerable time preparing online boards before sessions We used Mural for collaborating together on these Rather than creating lots of different boards I’d recommend creating one big board so that everything can be seen together This is a bit like the virtual equivalent of a design sprint war room with sketches, post-it notes and screenshots stuck to the walls
- Another good tip is to create swim lanes for each participant This ensures that everyone has a space on the board for their input For example, here is a board capturing ideas using the classic how might we? format
- So my seventh tip is to prepare material before remote design sprints And to brief participants beforehand so that they know what to expect, and can carry out any pre-remote design sprint homework For example, reading up on previous insights
- When you’re on a video call it’s tempting to multi-task Perhaps checking your socials
- Or cooking up a little snack
- This is why it’s important to set ground rules for remote design sprints Prior to both remote design sprints I outlined the guiding principles Such as having a web cam on where possible Making quick decisions being more important than being 100% correct And that there’s no such thing as a bad idea
- With the most important to be excellent to each other
- It’s a good idea to set the house rules for remote design sprints And to make sure that everyone knows what these rules are And importantly to actively sign up to these rules
- When you’re running a remote design sprint the tools you use can make or break the sprint From video calls that keep dropping out, to design tools that are not a good fit for working remotely It’s important that you use tools designed with remote working in mind
- For the first sprint we heavily utilised Mural for online collaboration, but little else For the second sprint we used more tools to help drive remote collaboration This included Figma for real time design collaboration And even PowerPoint to collaborate on a presentation deck in real-time
- For remote design sprints it’s essential to utilise remote collaboration tools Such as Mural, Miro, Figma and even Office apps This can make it easier to collaborate remotely
- My final tip covers sharing your work during a design sprint If you’re doing a design sprint in-person, you can generally stick up lots of stuff in the room you’re working in This makes it easy to take everyone through what you’ve been doing Unfortunately for remote design sprints it’s not so easy
- This is why during the second remote design sprint we had a show and tell not just at the end of the sprint But mid-way through as well This is a great way to show stakeholders what has happened in the sprint In fact, if you’re doing a remote design sprint over 2 weeks you could have a show and tell after the first week And then after the second week
- So my final tip is to provide updates during remote design sprints Not just at the end
- I’ve run through some tips for running remote design sprints But ultimately do they work?
- Well Jake Knapp certainly seems to think so He claims that people have done remote design sprints thousands of times with great outcomes
- And this is borne out by the 2 remote design sprints I’ve spoken about Both ultimately proved successful With the enterprise remote design sprint we were able to test lots of ideas with enterprise customers With a number making it to the roadmap for the product
- With the onboarding design sprint we were able to test some ideas, including an interactive onboarding tutorial However, having only 4 days resulted in less time to explore different ideas So I’d definitely recommend a 2-week sprint over a 4 or 5 day sprint if possible
- So, we’ve looked at what remote design sprints are, how they compare to in-person and some tips when running them
- Remote design sprints are different from in-person design sprints They are not necessarily better or worse, because there are times when it makes to sense to run an in-person design sprint And times when it makes sense to run a remote design sprint The important thing is that you actively think about the best approach to take And plan out your design sprint accordingly
- So let’s recap those 10 tips for remote design sprints
- If you want to find out more about remote design sprints Check out the remote design sprint guide This is a collection of tips and advice from the same authors of the original sprint book
- The guide also include template for popular online collaboration tools Such as Miro and Mural
- So why not have a go at running your next design sprint remotely, or at least in part remotely I’ll make the slides available as soon as possible and will also post them to my website UX for the Masses If you have any questions, I’d be happy to answer them