In our webinar Workshop Facilitation for Design Sprints with Ben Crothers, Principal Design Strategist from Atlassian and author of Presto Sketching we had so many in depth questions on Design Sprints we weren’t able to answer them all in the webinar.
So with the help of Ben (thanks Ben!), we have collated the answers and pulled them together here so you can all benefit, as there are some nuggets of gold for implementing Design Sprints.
And yes, there was way more covered in the webinar itself. You can watch it right now here.
How big of the problem to solve is typically done in a Design Sprint given it is one week? Is there prep work before the Design Sprint?
I definitely recommend a 1-day problem-framing workshop before the sprint, for sure; 1 morning usually isn’t enough to scope up a problem/opportunity in my experience.
That said, problems best suited for 1-week design sprints tend to be problems that you can map as an experience over time, where the problem = a gap or known pain point in that experience, or an area of the experience that represents one point solution, or an opportunity to (a) improve customers’ experience and (b) make/save money as a business.
1-week design sprints are also great for testing solutions to internal process/comms/change management issues, (where you can just focus on one piece of the overall picture), and for testing new product/service concepts, just to see if they have legs before doing larger (more expensive) market research…
Problems that are too big to tackle tend to be problems with a complete end-to-end service or system. It’s much better to break these down into subproblems/opportunities.
I actually think he ‘1 week’ is a bit of a false constraint. I’d consider breaking something up and doing several 1-week sprints, or several 2-week sprints, following the same pattern of activities.
How do you get people to be vulnerable?
For people to be vulnerable, they need to trust each other, trust the process, trust that they can succeed in that environment, and trust that everyone has their best interests at heart. First and foremost the facilitator needs to model trustworthy behaviour: be affirming, inclusive, positive and optimistic.
People start to trust each other more when they find common ground, and common interests. As a facilitator, highlight any existing common ground, and do ice-breakers that help people find common interests / points of view.
Start with a simple fun question to get everyone around the room to answer (to feel a bit more comfortable with each other), e.g. What was a fav TV show as a kid? What famous person would you like to have dinner with, and why?
Do a ‘hopes and fears’ activity (~30mins). Get people to write on stickies what they hope will happen in the workshop, and what they’re anxious about / what’s risky.
Beware having alpha types clashing with the quieter types. Suss out the personalities in the room and try to encourage the quieter ones.
What if someone comes in halfway through – say Wednesday? Is there any point?
Yyyyeah… not really. They’d be missing too much context: the problem/opportunity shaping on Monday, the early ideas on Tuesday, the discussions throughout those activities… It’s like coming into the kitchen half-way through cooking the dinner, wanting to suggest what recipe to cook. 😉
Plus, it’d be too much tax on the group’s time to try to bring them up to speed properly.
How do you break up sprints over 2 weeks?
This is my preferred format, actually. You can have some days as full days (Mondays and Fridays) and the rest as half days. This makes it less pressured to be in the room the entire time.
Week 1: Have a whole day on Monday for shaping the problem/opportunity. Then half days on Tuesday to Thursday for going broad on ideas. Then all day Friday to refine+combine ideas and decide what to prototype.
Week 2: Use all day Monday and Tuesday to prototype, then Wednesday and Thursday to test. Use Friday to reflect and decide.
Would love to hear Service (as opposed to product) examples and whether/how you use Pretotyping?
If ‘pretotyping’=pre-fabbing some elements to use in prototyping, that’s a really smart idea. At Atlassian, we have UI kits and frameworks as part of our design system, for throwing rapid prototypes together. If you’re likely to do several sprints, then it’s worth investing time in a similar framework of templates, grid layouts, UI kits, image libraries to use.
Re: service examples – in my own experience, it’s been about event design and bank branch redesigns. Events – we mocked up (in small scale!) a space representing a ground floor conference event area, with colour-coded roles (speakers, attendees, concierges, tech, corp booths). We were interested in way-finding and traffic areas. We drew and cut out our own little ‘props’, but you can use something like SAP Scenes.
Bank branches – I remember mocking up some new designs of ‘internet kiosks’ and where they should be best located in a bank branch and so on. That used lots of cardboard boxes and iPads. They worked a treat, until they tested them live in the bank branch itself. The bank staff were wondering why they went well in testing but not in real life… then noticed that they’d put the kiosk right where there was an escalator, which meant lots of people could see over the shoulder of whoever was wanting to use the kiosk!
Is it possible to successfully run such sprints in less time, say 2 days?
I’d say no, it’s just not. I find it generally takes a day for people to align on what the problem even is, that they want to focus on. Even if you rushed that, you only have maybe a day and half to generate ideas, make a prototype, test it, and then reflect. It all gets way too frantic.
It’s much better in the long run to optimise for learning over speed. If it means just spending a day aligning on what the problem/opportunity is, then that’s great. If it means spending two days prototyping/refining an existing idea and then testing it, then that’s great.
Can you include “outside the room research tasks” (interviews/observations), say in the evenings or during the session, perhaps making it more than 5 days, or squeezing it in at the cost of session time?
I’ve run design sprints where concept testing happened first in Sydney, and then in the US overnight, while we slept. The following day we reflected on both sets of testing; that worked well.
One I’m working on right now has some market sizing analysis going on in parallel in the US while a team is doing a design sprint in Sydney, just to help the team assess which idea would have possibly greater market impact. That works well, too.
It’s much better to do proper research before (and separate to) a design sprint. Invest a couple of weeks at least in customer interviews and observations, a survey, or diary studies beforehand. Synthesise the results of those, and bring those results into day 1 of the design sprint, to have a more informed discussion
Interested in any experience you’ve had with process focussed sprints (vs. product or service, although they are all pretty similar).
Techniques like journey mapping are great to get people from several different areas of the business quite literally on the same page, when it comes to illustrating an insightful picture of several business processes uniting to provide a service to customers. Back-casting is also useful if the end outcome is clear and you need to work ‘backwards’ from that. Stakeholder mapping is great for getting people to understand which roles/teams provide what value to others/other teams, and where the ‘weak’ risky links are, when it comes to processes and dependencies. Lastly, Ishikawa (fishbone) mapping is good for tracing dependencies in processes, and/or cause-and-effect in problems.
How many design Sprints would an Atlassian team typically do in a year? Presumably not every Design Sprint will end up with a business plan sign off?
Great question, and honestly, Atlassian is so big now, I don’t know! There always seems to be a design sprint going on somewhere, whether it’s feature-based, or initiative-based (e.g. implementing GDPR into all our identity/log-in screens), or experience-based (improving the upgrade experience, or migration experience from server product to cloud product).
And the ‘sprints’ word is used very very loosely here. Sometimes it’s just 2 days of problem framing and generating ideas. Sometimes it’s 4 days of ideas, prototyping and testing. Sometimes it’s 2 weeks of doing the full set of techniques. Sometimes it’s 4 weeks, where extra research and iteration/re-testing is threaded into the flow. Are they all sprints? No, not really. But the main thing is framing up some area that is ambiguous where we need clarity; some product/user question to answer; something that’s risky where we need more confidence before we can make a call.
“Pressure cooker” environment – can you give a few examples?
Doing a design sprint in 5 days has always been a ‘pressure cooker’ environment, in my experience. Participants have to park all their regular work, or do their best to catch up on emails outside of the sprint hours.
Having only a day (roughly) to generate what you hope are ideas that will solve your chosen challenge definitely puts pressure on people.
Having to make a decision on carrying one idea through to prototyping puts a lot of pressure on people, too. People always worry: what if we’re choosing the wrong one? We have to be guided by the product/service strategy, and the impact that we think each idea will have, and use our best judgement, and just roll. You tend to build a backlog of ‘maybe’ ideas that you can always come back to later on.
One example that springs to mind is where a group had to generate ideas and then choose one (as above), but 3 of the group were working remotely from home. They weren’t in the room, and it added a lot of unnecessary pressure, trying to make sure the remote people were across everything in the room, trying to make sure they had equal representation, trying to quickly put everyone’s ideas in one digital space (on Mural), as well as on the wall in the room… It made things very complicated. Agh!
Regarding prototyping – just how high fidel should we go in order to get the kind of feedback that is useful? For instance: can we just use the sketches and talk the user through it or do we need to go all the way through to a clickable prototype? In other words: do you need a designer?
Having a ‘design sprint’ without a designer would seem really weird for me. 😉
You definitely need a designer, not just for prototyping, but for greater creativity, for helping bring ideas to life, for helping ideas stay grounded in what will make customers win.
Re: prototyping. Generally, I find low-fi (or sketches or basic digitally drawn mockups) are fine. You’re wanting to test usefulness and desirability, i.e. if an idea even makes sense, if it speaks the customer’s language, if it fits with how they think they want to get something done, if they’d use your idea over what they’re doing right now. You’re not testing usability, i.e. how usable something is in getting a known task done.
I generally find that when people fixate on creating hi-fi prototypes, it generates more work than is necessary e.g. more screens, more clickable areas. When you use (neat clear) screen sketches, you don’t need to worry about accurate branding and lots of regular text and images. You can focus attention only on areas of the screens where you need attention, whereas you can’t do that with pixels (i.e. a digital screen that’s trying to look like the real thing but with no logo/branding, nav, extra text and images, etc, looks distracting).
Optimise for the path that test participants need to go through, to work out if (a) they get it, and (b) they like it more than what they’re using right now. And best to get participants to actually use it and think aloud, rather than you/the team talk through it.
Any experience doing Design Sprints effectively with remote workers?
Agh! I’d rather not do remote design sprints at all; I’m always saying that if it’s important enough, we should spend the money to get everyone in the room; it’s always a much better outcome having everyone in the room together.
That said, and to be pragmatic, here are a few ideas based on my experience:
- Even if one person is remote, optimise your process + tech so that everyone has equal access to what is being generated and discussed. That means that all assets generated (stickies, ideas, voting, etc) should be digital. Have everyone use Mural.
- Assign a separate person to make sure the remote contributors are across everything going on, and that everyone knows their contributions. This means e.g. someone regularly taking photos of what’s on the walls and sharing on Slack, or printing out images of remote participants’ work so that everyone can see their work next to everyone’s.
- If you’re dealing with different time zones, play to those participants’ strengths and timezones, e.g. maybe someone in the US can do some prototyping overnight while people in Sydney are sleeping.
- It’s really draining and boring for people just to sit at a desk/computer and participate remotely for hours. Consider doing the sprint over 2 weeks, and have separate 3-hour remote working sessions instead.
As you can see, these are all pretty much compromises. I would always optimise for learning, risk reduction and quality, rather than for remote.
Other tips to get people to draw?
It’s always good to emphasise at the beginning that we’re not drawing for realism; we’re just wanting to show our ideas. If people are only comfy drawing boxes and stick figures, that’s perfectly fine. 🙂
Help people to get going by doing a bit of demo drawing on the whiteboard. Draw a few super-simple figures, poses and objects first; give them something to copy. Demo drawing a couple of screen wireframes. Demo how to do a few frames of a storyboard.
As a facilitator, feel free to make a mistake on the whiteboard, and have a laugh about it. That helps people relax a bit, too. 🙂
Recruiting Customers to test/co-design with can be time consuming. How do you approach having a Community to test with?
At Atlassian we have several recruitment companies we go through, who have tons and tons of people on their lists. We give them a screener spec, and they handle the recruitment, and then we schedule from there.
In previous orgs, I’ve had success recruiting people through craigslist.com and just generally using shout-outs on social media.
Yes you can maintain a panel/community of people to tap every now and then, but to be honest I’ve found that is a lot of effort, and people move on and roll off that list all the time. It takes constant ‘community management’, with very low ROI.
How do you know when you have a solid problem statement?
Great question! A solid problem statement should inspire a lot more action than confusion… 😉 i.e. if others read it, it shouldn’t trigger lots of questions. I tend to find people sacrifice clarity for brevity, i.e. they try to make it so short that it lacks a lot of meaning.
I tend to go with problem stories, which have elements of specific user type, goal, problem, trigger and impact. I tend to go with / look for a format like this: “A USER TYPE wants to GOAL. To do that, she does a set of TASKS. When TRIGGER happens, she experiences a PROBLEM, which has this IMPACT.”
Note, for me a problem statement should articulate an actual problem that a user/business experiences, as opposed to a design challenge, e.g. “How might we…”. The reason is that you can spawn lots of different design challenges from a single problem statement.
Don’t forget to watch the full webinar with Ben here.