No results found. Please refine your search.
No items found.
We don't always have the time or resources to conduct a full design sprint - or we just don't need the complete structure of a design sprint at that time. But we do need to prototype and test our concept - quickly and efficiently - before fully building it.
We often spend too much time belaboring this prototyping phase when we could be utilizing tools to help us test quickly and efficiently.
In this webinar, our host Douglas Ferguson (Voltage Control) unpacked a collaborative prototyping process that brings teams together to build more, faster - and supports everyone contributing in an efficient and productive manner.
Use the Outline feature in the presentation mural (below) to quickly navigate to a specific section of the webinar.
If you missed the webinar, we've got all of the resources below - including the custom MURAL template that Douglas and his team were demoing during the live session. And make sure to check out the resources section inside the presentation mural for everything else you need to take your team's remote prototyping to the next level.
Take action with the template:
Create a mural from the template and invite your teammates in to start your next rapid prototyping session. You can learn more about why this method is important and steps on how to use it in these articles written by Douglas.
Explore the presentation mural:
Did you participate in our live Q&A? We went back in and answered all of the questions that we couldn't get to during the live webinar in the (3 Kanban style) Q&A sections inside the mural.
Watch the video recording:
Follow along as Douglas shares insights into collaborative prototyping and answers questions in our live Q&A.
David Chin: Alright hello and welcome to the webinar build more faster with collaborative prototyping. My name is David Chin I'm a strategist and designer at MURAL I'll be one of your hosts today. Now often times in our process we'll uncover real pain we don't have the time or resources to conduct a full design sprint. Or you just don't need the complete structure of a design sprint right now, but you do need to prototype and test your concept quickly and efficiently before fully building it. We often spend too much time laboring this prototyping phase when we actually could be utilizing tools to help us test quickly and efficiently.
That's why I'm excited about our co-host today Douglas Ferguson because he's an expert in design sprint facilitation and has been doing some really amazing and inspiring work to innovate on the design sprint process and the prototyping aspect specifically. So Douglas is an entrepreneur and human centered technologist with over 20 years of experience and currently the president and founder of Voltage Control which is a firm based in Austin, Texas specializing in design sprints and innovation workshops.
At Voltage they are always sharing knowledge and resources and recently created a really amazing new template to help facilitate hyper effective collaborative prototyping which is what we will unpack today. So hello Douglas thanks for joining us, but before I hand it over to Douglas just a few details about our webinar today. We are trying something new, instead of waiting until the end of the webinar to have the Q&A we'll be answering questions throughout the session. The webinar is broken up into five sections and we'll do a mini Q&A for a few minutes at the end of each section. Please use the Q&A panel to submit your questions we'll do our best to answer them as we go.
Any that we miss we'll answer them offline and add the answers to this presentation Mural which you will have access to shortly after the webinar. So with that I'm going to hand it over to Douglas, take it away.
Douglas: Thanks David, as David mentioned I'm Douglas Ferguson president of Voltage Control a workshop agency based in Austin Texas and we run innovation workshops. Many of which are design sprints and we are big fans of continuous improvement and run retrospectives after every sprint. These retrospectives have led us to experiment with our own variations and risk in the design sprint structure and process. Over the last few months we've been releasing some of our favorites which you can find at voltagecontrol.co. Mural enabled us to develop a few of these ideas further and even a few that we are still road testing. Today we'll be sharing our design sprint stitcher dash board that will allow you to prototype at lightning speed.
Our prototypers often collaborate with client teams including designers, copywriters and other workshop participants during prototyping on Thursday. In an eight hour rubber prototyping session it is easy for things to get misplaced or completely forgotten. The chaos and uncertainty can also open the door for unwanted last minute changes leading to extended hours and stress on the prototyping team. In order to address this challenge we examined and experimented with many different collaboration techniques. We used the kanban system for capturing early assignments and tracking jobs but email threads were still too much for everyone to manage. We put the stitcher in charge and grew the stitcher role to resemble something akin to a scrum master from agile.
We asked the stitcher to organize efforts across the kanban board while also collecting and co letting all assets. Even though expanding the responsibility of the stitcher helped they still struggled with massive email threads so we began to use google docs to centralize our efforts. At that point we realized that google docs had two fatal flaws, it compresses images which makes them unusable on prototypes and many of our corporate clients block google docs for security reasons. We tried lots of tools to see what might work best including ether pad mural, realtime board free hand and ultimately we picked Mural because it met all our functional requirements. Our corporate clients approved its use and its facilitator friendly features are lovely to use.
Let's start with an overview of the stitcher dash board template that we created. In the top left hand corner you'll see a set of instructions or a link to a set of instructions. [inaudible 00:05:59] medium articles for details on using the stitcher dash board throughout your prototyping day. Below you'll see the kanban, on Wednesday during story boarding we write down anything that still needs to be decided as a new job on the kanban and we do this by placing stickies onto the to do column. This includes writing copy, icons, collecting assets, looking up statistics, models or other data. The story board section to the right is a replica of your story board grid created on Wednesday and we use an alpha numeric naming system to provide a quick reference to its cell. The kanban jobs, the to do stickies should reference the alpha numeric names so that we can easily refer to them without having to create complicated names.
Let's pause here for some quick Q&A and then I'll walk you through the various stages of the stitcher dash board for the prototyping session for an IOS app and we can see that prototype here in this animation of walking through the envisioned prototype that was created. David what questions do we have so far?
David Chin: Alright, well lets start with can you explain the stitcher roll a little bit more and how that came about and what that really means?
Douglas: Sure, so in the book the stitcher roll is referring to stitching the prototype together. Especially if you have multiple designers working on the prototype having this one person who's kind of overseeing all of the efforts and thinking about how it all fits together and what needs to link to what and actually doing the Q&A along the way it means that you don't have to wait until the very end of the day and do this mad dash to try and combine things together and then do the Q&A at that point. Even if you only have one designer it is nice to have someone else thinking about the flow and making sure that everything connects together. Even though the name stitcher is kind of very much derived from this activity of stitching together the screens using envision [inaudible 00:08:29] or even keynote, we just kind of for historical sake kept the name and just expanded the responsibilities.
David Chin: Great thanks and another question where can we find this template? So we are going to paste the link to this in the chat but Douglas it's also available with a breakdown of the directions on how to use it in your medium account. Can you share a little bit about what they expect to find there?
Douglas: Sure, the voltagecontrol.co is our medium account or publication and we've released articles detailing our process of kind of discovering and refining the stitcher role. There's also an article explaining how to use the templates so I had to set it up because there was a little bit of configuration upfront just before you get started and then kind of step by step guide. Basically echoing what we were talking about here today but it's a nice little quick reference when you are ready to go do it.
David Chin: Awesome, what's the interaction between MURAL and Invision?
Douglas: Interesting, so there's no direct interaction from like an API or well just no direct interaction but what I will say is there's a couple of points we'll see where the prototyper or the entire team raTher is going to be leaving notes for the prototyper. They can leave these comments either in mural or directly in envision, we also have a text area, a text box in the template where you can drop in your prototype links. So typically if we are using envision for the prototype we'll drop in the link there.
David Chin: Great, alright what is your ... this is a good one, what is your definition of prototype asking because I believe the word means something different for different people?
Douglas: Absolutely, and this is something I run into a ton because we do some prototyping for folks outside of design sprints and one thing I see a ton of is where development teams will consider prototypes being kind of a proof of concept where they are actually going to write code. I would say 100% of the prototypes we do involve no code and in fact we are just trying to figure out how to fake it before we make it if you will.
Think about it as a movie set, what's that realistic facade that's going to create the illusion that exists?That's super important that we create that illusion because we want to make something concrete that allows people to really understand what it is we are talking about building. So that we can get real reactions to it. Otherwise if there's any ... if it's ambiguous at all then we can't trust what we are learning because we may be using the same words to describe completely different things or we may be using different words to describe the same thing. Getting something that's super concrete and representative of exactly what we are thinking about building so that we can learn from it.
David Chin: Awesome.
Douglas: That can include physical prototypes, one of my favorites is when Jake and team prototyped an office hiring actors to come simulate this new kind of office environment. I would say my favorite advice on prototyping is get creative, get in that prototyping mindset and figure out how we can simulate what it is that we want to create.
David Chin: Amazing, alright time is up for that section let's move on.
Douglas: Excellent, thank you David. So after story boarding on Wednesday we add all remaining tasks to the kanban and we place ... sorry. We place stickies under the story board grid for any story board elements that will be helpful to reference. We'll copy what we've already decided on i.e sketches of visualizations and what not to the approved sections of the board. As we've story boarded out we'll place those things in so that they are there for easy reference when prototyping. The jobs will be assigned to specific individuals as needed but some jobs may be left open for grabs. We recommend assigning all high priority jobs to make sure that they get addressed first thing in the morning.
In fact some more ambitious teams will start their jobs on Wednesday evening, first thing on prototyping day we run down the list of jobs with the team and make sure everyone is ready. We also take the time to quickly review the story board and answer any lingering questions. Now we are ready to launch into prototyping. The team begins work on any jobs that are assigned to them and they indicate this by moving the card into the doing column. If they don't have any assigned jobs they can pick up jobs without an owner and ask the stitcher where they can lend a hand.
The stitcher is coordinating the team to understand who is blocked and making sure the highest priority items are getting completed first. As the team finishes jobs they'll add these assets into the story board grid and move the cards to the done column. Then they'll start another job, if the prototypers realize they need something new the stitcher makes a new card on the kanban and prioritizes it. Assigning jobs and letting the team work autonomously with full transparency builds trust early on which is required to make a realistic prototype in such a short amount of time. We are going to pause here and take a look at another round of questions.
David Chin: Okay so once the prototype is build how do you leverage Mural when testing it with users? Or do you-
Douglas: We have not leveraged MURAL in the testing phase to date but we are starting to build more and more templates to embellish our process. Stay tuned for future updates, we also currently have an asset that we've written about called the score card and that is an excel template that is a great alternative to writing posted notes on Friday. Because it's already organized and we don't have to do this kind of sifting work at the end of the day Friday when everyone's exhausted from listening to interviews. The other neat trick that it does is it focuses back on our sprint questions so that while we are listening to the interviews we can really think back to about those guiding principles or those concerns we had [inaudible 00:16:01] weekends and to kind of assess whether or not we can answer those questions accurately.
David Chin: I might have missed ... I was trying to encapsulate the answer there and if I missed it perhaps some of the attendees might have as well. Can you just recap again where does mural [crosstalk 00:16:23] testing?
Douglas: Currently we are not using mural on testing day but we do have some stuff in works so stay tuned for that. The tool we are using on testing day is the excel score card that we created and wrote about.
David Chin: Got it alright, here's a good one do you customize the score board to the anticipated structure of the prototype?
Douglas: I guess the short answer is yes, when we are working on the story board that's actually the main objective that we are trying to accomplish is to think about what gaps there are and the sketch so that we can address those gaps because we don't want to introduce any new ideas during prototyping. That's another super important concept or rule because the more ideas that we introduce during prototyping the more things are going to get slowed down the more confusion and we had to build a line around these ideas and make sure that everyone's okay with making those changes. The story board really allows us to uncover those kind of weak spots or those gaps so we can address them as a team. In fact sometimes it doesn't make sense to address them as a team and we'll create jobs. Actually Susan is going to be really great to figure out the answer to that question and provide details for the prototype so we'll just assign that to her and let her go kind of work on that first thing on prototyping there.
David Chin: Alright, how do you manage the several different creations that different people will be doing assessing their jobs?
Douglas: We'll look at some of that in the future sections of the webinar but the one thing I will say is that the output of the jobs are going to be placed onto the area on the storyboard grid where they are destined to land in the prototype. That way the prototype has a very targeted area that they go to search out assets and content for the screens they are working on. The stitcher is the one that's actually keeping an eye on things and if there's any side bar conversations about ... lets say that someone has a job to go write some hero copy for the landing page. And they write that copy but there's kind of a side bar conversation around, "Oh is that going to meet some regulatory requirements or there's an issue there?" The stitcher's paying attention to that stuff and making sure that once they come to an agreement then it's kind of green lit or marked as being ready to be incorporated into the prototype.
David Chin: Alright and it seems you do prototyping prep in Mural but not the actual prototyping?
Douglas: That's correct although I would not be surprised to run a design sprint where we do prototype in Mural as I said we are thoroughly agnostic to tools and it's about getting into prototyping mindset and figuring out what's the best way to kind of simulate the experience that we want to show the users. If a mural is the type of prototype that... so if a [MURAL 00:20:01] is the type of prototypes that makes for this design [sprint 00:20:05] then we'd absolutely use it.
David Chin: Perfect. Do you share native files? Like sketch files through this ... in the template? In the MURAL?
Douglas: Yeah, we share ... I don't know if anyone specifically put a sketch file on the MURAL before, there's no reason why we couldn't and in fact, one of my favorite things about this is that it creates a bit of an archive for the team to reflect back on and reference. So it's a great idea, maybe we should start doing that.
David Chin: Alright. So our time's up for this section, let's move on.
Douglas: Excellent. Thank you David. So now we're looking at the playbacks and revisions which is something that we feel very strongly about because I mentioned in the book ... and we even take it further, we require at least two playbacks on prototyping day. So at this point in the day, most of the tasks are either complete or underway, an approved content and copy has been flagged with green, to indicate it's safe to use in the prototype. And as each [train 00:21:25] is ready for feedback, screenshots are placed into the storyboard grid. So the team can add [accompaniments 00:21:32] directly in MURAL for the prototypers to see and adjust accordingly. The prototype has really begun to take shape, and so it's important to share with the team to get feedback. We can place a link into the MURAL just under the instructions so that any remote team members can view the prototype or folks can take a look before we actually have a full team playback.
We always make sure, as I mentioned, to have at least two playbacks before the end of the day. And that ensures that all of us are aligned and tracking toward a common goal. And as we view the prototype together, we can capture edits or visions and comments in the prototyping tool and, or add new jobs to the [Kanban 00:22:21]. Be sure not to generate new ideas as the scope create can distort the original solution and will prevent the prototype from being completed on time.
This is another benefit of assigning jobs to the team, they can keep busy and focused on completing their task rather than dreaming up new ideas to add to the prototype. Playback is also a time when the entire team is focused together and it's an opportunity to review copy and content pending approval. So in addition to looking at the prototype, we'll also review the Kanban board and we'll review any of the assets that have already been completed, together as a team. So I'd like to pause again and turn it over to David for some questions.
David Chin: Alright. So do you use MURAL to prototype an online design sprint? And do you use MURAL specifically for day one, two? Or just day three?
Douglas: So we're about to announce a MURAL template for lightning demos and there's actually two different templates that we're creating for lightning demos. One is for collecting as a facilitator all of the lightning demos and using it as a dashboard to present them and share the demos. And another is a way to kind of reflect back on them, so we sketch thumbnails each day for each lightning demo, so there's a template for that. We don't run remote design sprints through MURAL, but we have run remote workshops. And we use MURAL heavily for those. So whether it's a, you know, we're doing something like an abstraction laddering or doing some journey mapping exercises or even an AI canvas that we developed and we're working with remote team, MURAL's a great resource for that. But there's so much teaming happening in a design sprint that we haven't ventured into doing those remotely yet.
David Chin: Great. So the mock-ups that you're sharing, they look fairly high fidelity. If everyone starts prototyping at the same time, who sets the direction for the visual style? Is that pre-determined?
Douglas: Ah, interesting. It really depends on the team and the prototype. But usually someone's taken ownership of that. So sometimes we might be doing a fake brand because we don't want to bias the user in some way. Or sometimes the fake brand is because we're [pitting 00:25:29] two prototypes against each other, so we want to make sure to not have them be the same brand. So we invent a brand for that. And so whoever is working on the branding will put together a quick kind of design language or style guide that can be used by the other prototypers.
A lot of times we're building stuff using an existing brand, and so that design language is already there and we can kind of dip into those assets and those tools. And that definitely makes things move a bit faster.
And I will also say that, you know, another thing we had to keep in mind is we are seeking to understand desirability and also how this concept lands with someone. So how do they interpret it to work and what does it mean to them? And so it's not a test in usability, so design consistency, while it's important and we strive for it, we're not going to [inaudible 00:26:30] perfection. Because ultimately if we put a stake in the ground it allows us to quickly learn. And so there is a balance between, you know, not getting too perfect on that design language.
David Chin: Nice. Alright, and when you say a playback do you mean a stage of the process where you walk through the draft prototype? I guess can you explain that playback process?
Douglas: Yeah exactly. And here's a plug for Ed Catmull because I love his book, Creativity Incorporated. And he talks a lot about sharing the ugly baby and so we're big believers in exposing an unfinished product so that we can all react to it. And that also comes back from my technology and development background, is we believe in, kind of, testing early and often so that ... 'cause the earlier you discover a problem, the cheaper it is to address. And so very much the same here in prototyping, if we discover that we've gone down the wrong path early in the day, it's much easier to fix it and much less likely that we'll be up late trying to get the prototype back on track. And so we like to have as many check-ins as possible and the MURAL board's actually allowed us to do that without having these formal check-ins because as screens are getting done, we're pacing them in and we can get comments directly in MURAL, but we still do the formal full playback to the entire team at least twice during the day. So we'll have one kind of mid-way and the one not totally at the end of the day because we want to reserve time for any of those last minute changes that come up during that playback.
David Chin: Alright. Okay, so multi-part question.
David Chin: What's the most important thing to consider when running this [mission 00:28:28]? And what is the main element in the physical meeting that MURAL replaces?
Douglas: It's interesting. The most important thing to consider. I think to me the most important thing is that while this tool is about helping us define what needs to get done and track it and understand what's ready and what can be pulled in the prototype, it should not be a vehicle for inventing new work. So definitely that should be a guiding principle, that we've already locked in these decisions. There's a reason that Wednesday on the design sprint is called the sticky decision. It's a fun play on words 'cause we're using stickies to do it but it needs to be sticky, we need to stay with it, we need to not be willing to change and create more work and also turn it into Mr. Potato Head, right?
And as far as what the MURAL replaces, to me it's less about it replacing ... I think it replaces chaos, honestly. You know we've got all these email threads and I'm going to speak to that a little bit in the next session but it can be really painful if we're trying to do a lot in eight hours and we've got the whole team involved. And I think some folks have decided to, or opt more to involve less of the team but our philosophy is involve everyone and so MURAL really helps allow us do that.
David Chin: Amazing. Alright. And could you define the purpose of, I guess-a design sprint overall. Why do you run design sprints in the first place?
Douglas: Yeah, yeah. I think design sprints are a great way to bring a cross-functional team together to solve a really tough problem. And typically, you know, it's if the team is stuck in some way or they have a diverse set of priorities that all have a lot of business potential, and they're having trouble understanding which one to go after first. And ultimately what we're doing is we're helping a team adopt or either refine some of their design thinking or human centered design approaches in a real time boxed and rapid fashion. So typically getting [inaudible 00:31:00] might take six months.
David Chin: Alright. Great, let's hit the next section.
Douglas: Perfect. So essentially what we're talking about here is a [fishing 00:31:18] collaboration. And once all the tasks are completed and copies loaded, we're all in the home stretch. Prototypers and completing last minute punch list items based off of MURAL and prototype comments. And rather than having to sift through a 50 message email thread with 13 unread emails to find those last remaining assets, they're all neatly organized and can be quickly located. This turns what can easily be a stressful mad dash into a streamlined exercise of wrapping up the prototype. It's also a great way to archive all of the work that's been done during prototyping. Team members without access to the design tools can easily access all the copy and assets at any time, should they need them for development or other purposes. And after many attempts to get this write, things really fell into place once we started to use MURAL and it has completely revolutionized how we collaborate on prototypes. It's amazing how much more you can get done when removing extra busy work.
The prototype you see here was created in eight hours by one designer, supported by a team helping gather and organize all the copy and assets. I encourage you to give it a try sometime, I hope it makes as big a difference for you as it has for us. Now I'd like to take a few final moments for wrapping up some last Q&A.
David Chin: You know, actually Douglas, I'm wondering can we pop out of presentation mode for a second and go back to the working section of section four? Just because I realized that when we're in presentation mode we can't see the avatars of the remote team, so we couldn't actually see the remote collaboration that was going on. So if [Elijah 00:33:19] and that remote team, if they could go back in there and, you know, show how that actually works that'd be great.
Douglas: So I'm going to go to the demo area for O2, because it has the least amount of stuff moved already. So we can really see kind of what's happening there. So coming back to this section, just to remind everyone, where we're at is we've got a few things done and the prototype's starting to take a little bit of shape so we can see that they've already uploaded a few sketches or screenshots of art boards or pages in the prototype and they're kind of actively adding things that they're starting to complete, they're removing new jobs or starting them to do. And once they wrap up something they'll move that card into the done column. So you can notice Elijah just finished the task.
David Chin: Awesome. And generally how many people would you say is about right for utilizing this template? How big of a team?
Douglas: We've had as many as 12 people in a board before and it could easily accommodate more. I mean that's a nice thing about a system like this is that it's very visual and so you don't have to stop and co-ordinate with everyone and every individual person. And also anything that needs attention quickly surfaces, right? The [stitcher 00:35:04] can look through and find the task that they might realize that needs to be addressed and notice that it's in progress and see who it's assigned to. And so it really helps bubble up that information and it's kind of like managed by exception if you will. And the only reason that we've been limited in size is because the design sprint limits attendees to about 7 people and then, of course, the reason that we bumped up to 12 was because we'll include other people on prototyping day to just kind of add extra horse power to the team.
David Chin: Awesome. Alright. So thanks for covering that demo area again. Why don't we pop back over to that final Q&A area and we have been moving pretty fast so we can crank through these questions.
Douglas: Cool. We have lots of questions, that's great.
David Chin: Yeah, alright. So right off the bat, what was the name of that book by Ed?
Douglas: Ed Catmull, it's great, yeah. It's called Creativity Incorporated and it goes into a lot of details around processes he uses to lead Pixar. He's an amazing leader and has lots of great philosophies and advice. And another awesome thing about Ed Catmull is he's maybe ... well, from a young age, very fascinated with animation and actually got his PhD in computer science just so he could make the first computer animated feature film. And so, pretty amazing that he went to get a PhD in computer science because of that passion that he had.
David Chin: Wow. That is cool. Alright, so is it relevant just for digital products or for physical as well?
Douglas: So that's a great point. I think that MURAL may even be more relevant on the physical stuff because the physical things, unlike InVision, don't have the group commenting features. And so centralizing our efforts and all our work that are happening in the physical world and having a place to track them would be super important. And I would say instead of screenshots you might be taking photos, or sometimes physical things have a digital component. For instance, I did a prototype for a live event that my client was going to be holding. So what we did was we did renderings of the space. You could see the registration, you could see the actual seated areas of the events. So we actually had images of those renderings and then images of the kind of table tents that we were creating. And so those digital files or even photos of those physical things could be loaded up into the MURAL just for reference and feedback.
David Chin: Awesome. Why do you have the prototype assets in MURAL and not InVision or some other tool?
Douglas: So the prototype assets are going to be in InVision as far as the actual completed item. But the issue with InVision is, not everyone is in InVision, the licensing structure prevents ... there's many different reasons it wouldn't make sense to load a whole team up in InVision and then also there's this inability to kind of share and track progress and approvals if you will, get alignment, that this is a thing that you want to bring into an InVision. So I think of InVision more as an authoring tool whereas MURAL is more of the kind of alignment and collaboration tool.
David Chin: Awesome. Alright. Okay. So let's see. I was reading that a four day version came out to develop the design sprint. Is it possible that MURAL will allow the workshop to be held in four days? Okay so maybe I can help answer this. So yes, MURAL does help facilitate these shorter four day sprints, probably I guess easier and more efficient to do this I think digitally than doing this in person, you don't have to come together in the same place, you can work quickly in-person. You don't have to come together in the same place. You can work quickly. These cross-functional teams can meet, regardless of wherever they are, and what other responsibilities they have. But I think the four-day versus the five-day Sprint really can be accomplished in person or digitally, the same as the five day. It just depends on how your specific team's approach is. Doug, is there anything you want to expand on with the four-day Sprint?
Douglas: Yeah. My piece of advice there would just be to make sure to be thoughtful about that decision. The reason I say that is because, regardless if you do a four or a five-day, you still had to do the same amount of work, and so the four-day requires a bit more of preparation upfront. And the team has to be pretty aligned on that upfront work and really understand what they're getting into. There's a bit of ... One of the reasons that the four-day works is there is room. There's kind of squishiness in the schedule, and it's there for a reason because it allows the team to flex and to move as needed. And so, if there's any ambiguity or too much lack of alignment, it's going to be really hard to squish it all in the four days.
David Chin: Awesome. All right. Let's see. This one seems juicy. What's the leanest approach you can imagine to using this template? Many of my "team members" are volunteers. This person's in a non-profit, and they're looking to streamline their involvement to the minimal time required.
Douglas: Well, yeah. So, I would say something like this would be a great way to minimize their efforts. Because having a clear and kind of structured process where they know what's requested of them, it's very clear, and when their work is done, it's very clear. So, it's kind of minimizing that exchange and how and when they access that. So, I'm a big fan of process and keeping processes lightweight, but as long as it's understood. You can provide a lot of efficiencies just around people understanding what's expected of them and being able to quickly find what's needed. So, I would say, it doesn't have to be necessarily this template but any kind of system where they can easily find their assignments and easily find all the resources that they need access to get their job done.
David Chin: It's really about transparency in a way.
Douglas: Yep. Exactly.
David Chin: All right. All right. What integration with another tool, or what tool would be most desirable for you in a Design Sprint?
Douglas: Interesting. Yeah. That's a great question. I've been so focused on kind of solving some of the problems that we have been working on, I haven't really ... It's kind of nothing I'm currently stuck on. Eli, one of my lead facilitators in the room here, do you have thoughts on things that would be helpful integrations, or if ...
Eli: Yeah. I think the sort of differences of working with a variety of enterprises, really-
Douglas: That's a good point.
Eli:... that the Sprint itself because it's the process is flexible enough that MURAL and Drive, I mean you can use anything that you ask to help it.
Douglas: Yeah. There's nothing top of mind. I think, to Eli's point the process is very adaptable, and if you really lean in on the principles and what it is that provides value for the team, then a lot of the practices can be adapted. But really leaning in on those principles is what provides the real value, and so there's nothing that we really have been beating our heads against.
David Chin: Is there anything that perhaps you've come across in the prototyping phase even where you're just thinking, "Oh, if we had this, it would be really perfect"? This would be a main-
Douglas: In prototyping. Yeah. I mean there are some things in prototyping. I think Figma is really fascinating and solves some interesting challenges, but the one thing that we've run into is a lot of teams have a lot grief around putting their ... just kind of relying on the cloud. What if their Wi-Fi goes down, and they can't prototype, right? But that really is an awesome way to kind of collaboratively prototype.
We've also been experimenting with ABSTRACT, and we're really excited about where that potential might lie. So, I think ultimately it's how do you basically allow multiple prototypers to be editing the same file and not wipe their work. I think, to me, that's the biggest challenge on prototyping. And I don't think we're totally there yet because on the Figma side, you've got this challenge of fear and worrying about connectivity and trusting this kind of digital kind of or, let's say, online solution. And then, ABSTRACT and some of the other tools, the features aren't quite there yet.
David Chin: All right. And can you invite team members with no experience to be part of this, or do you need to train them, even train them in MURAL or how to use the template prior to engaging them?
Douglas: So, we usually sit down with the Stitcher and make sure they understand what needs to be done, and then our facilitator also kind of explains how the Kanban works and where they need to put their files. And if someone's confused, either the facilitator or the Stitcher can help them. It's generally we're dealing with fairly small teams, and so there's not a big training burden because if someone gets confused and does it wrong, it's easy to correct.
As far as prior MURAL experience, it's not required. Everyone kind of gets it pretty quickly, and so we just invite them to the board and a let them have it.
David Chin: All right. What advice do you have for a team who has not done a Design Sprint before?
Douglas: Oh, wow. My biggest advice is don't do it if it's not the right thing to do. I think there's a lot of hype around Design Sprints because they're effective, and they're fun and exciting and can create massive value for a company. But just don't do it just because. It's like at the Google Sprint Conference back in October, and my friend, Neha, was talking about a CEO that she spoke to recently who was like, "My main problem is that I need to figure out what to do a Design Sprint on." I thought that was really hilarious to think that that's the one problem the CEO has? I'm pretty sure there's bigger problems for your organization than what you should do a Design Sprint on.
So, instead of looking for a time to do a Design Sprint, really make sure you're focused on the business challenges and the problems you're facing, and then we can figure out if that's the right tool to address it.
David Chin: That is the key I think. Focus on the business challenges and then determine if Design Sprint is the proper way to approach solving those challenges.
Douglas: Yep. But let me give you another answer because I'm sure the person that was asking this is wanted to know some of the more tactical. And I will say make sure you have a really skilled facilitator, and if you have someone internal that you think has the transferable skills and can do this stuff, really make sure that they've done their homework and read the book. It's great if everyone in your Sprint's read the book or at least know what they're going to embark on and don't shortcut the planning. Make sure that you really think through on how this is going to go down and everything you need to do to ensure success on your Design Sprint.
We released the Design Sprint Planner that you can download from our site. That's a great place to start.
David Chin: All right. Let's see here. This is an interesting one. I keep seeing Design Sprint. What are all the type of Sprints?
Douglas: That's a great question. So, Jake Knapp was a designer at Google working on Gmail, and he had one of his 20% projects, which turned out to be Hangouts. It wasn't called Hangouts at the time. He was working on a team that was kind of distributed, an international team, and they had scheduled some time to get together and start to work more deeply on the process or rather the project. He said, "Well, let's figure out the best way to make use of this time." So, he kind of crafted an agenda for the meeting that involved some activities. It was ultimately the genesis of the Design Sprint.
And when he came home from that meeting, it really stuck with him how much they got done in that short amount of time compared to the previous year. And so, he thought, "What if all projects were kicked off in this way?" And so, he started to define the process more, and Google adapted his role to start leading these types of workshops as a way to kick off projects inside Google. He did that for a while, and then Google Ventures caught wind of it. He started to do them for Google Ventures portfolio companies, and that led to a whole series of stories about startups using this process to kind of kick off their projects or kind of get unstuck. And so, that's what we see in Jake's book, Design Sprint, or Sprint: How to Solve Big Problems in Just Five Days.
And so, the thing is is while he was at Google Ventures, Google was continuing to develop these ideas, and so you'll find some completely different language although very similar because it has very similar origins. But you'll see completely language on Google, and so that's a little bit of the confusion in the marketplace, if you will, because there are these Design Sprints that as Jake kind of perfected them through Google Ventures, and then Google's work to kind of create their Design Sprint, sorry, Master Class, and the work you see there. So, they really talk about these converge and diverge loops.
And another thing to think about is there's this very common word, sprint, in Agile development, and then people have certain different connotations of what design means. And so, I see a lot of people hear the word, Design Sprint, and then immediately kind of think about what it is. And so, there's a bit of that in the market, too. So, I think the big players to think about are Jake's work out of Google Ventures, the work that Google's doing, and then AJ&Smart, of course, is developing new ideas, and they have the Design Sprint 2.0, which is the four-day version as well.
David Chin: Awesome. So, I just want to let everyone know there was an issue with the template link, but we just updated that. So, we pasted the URL in the chat, and it seems to be working now. So, you can find the template that we've been working in here in that link that is in the chat.
And maybe we have time for one more. This is another interesting one. How do you make sure that the results of a Design Sprint will actually be implemented?
Douglas: Great question. The first thing I'll say is sometimes it shouldn't be, and that's actually the awesome result of the Design Sprint. Because if we discover that this idea is really bad, or this market opportunity is not how we understood it, then maybe we spent five days to avoid six months of work only to realize that we shouldn't do this thing. So, there is the situation where you should not implement it.
And then, in the case where you should, the most important thing is making sure there's a diverse set of stakeholders in the Sprint itself. And so, one common mistake we see is when the Design Sprint has just a bunch of designers or just the product team, so you got to make sure you have Marketing, that you have Customer Service, that you have Operations and Logistics. If it's a software project, is development in? And so, when you build this group of stakeholders, what you're doing is you're building a set of advocates that go out into the rest of the organization and help to sell this project and build buy-in for it.
Also, another critical component is the selection of your Decider, and your Decider needs to be decisive because you're going to rely on them to make quick decisions throughout the week. But also, you're looking this is the person that should have budget authority and will be able to make decisions around whether this thing sees the light of the day.
And then, I would also think about strategically because sometimes folks won't include the naysayers or the problem childs, but they could be very well the people that throw torpedoes after the fact. And so, including those, even though it may be a challenge for your facilitator, is overall going to be the best thing for your project.
David Chin: So, what you said first is a great point about having that cross-functional team. We all know it makes sense for adding different skillsets to the work that you're doing but thinking about how you now have these advocates that will go back into your company and share the knowledge and help get buy-in, that's a really, really great point.
So, with that, we have three minutes left. So, why don't you pan over to the closing area with the information about contacting you and tell us about the Meetups that you're running?
Yeah. One second, let me get over to there, that section.
David Chin: Sure.
Douglas: So, David, one thing we are going to be answering all the rest of those questions, correct?
David Chin: Yeah. So, we will. Everybody will have access to this MURAL presentation. Well, it's a presentation in MURAL and the video recording. We'll send it out in the next few days. But we'll go back in, and we will answer all the questions that we didn't get a chance here live. So, when you get this access to this MURAL, then you can float around. You can see which questions were asked in specific areas and see the answers there.
Douglas: Awesome. So, I would just like to say feel free to reach out to me with any questions or comments you might have. You can see my contact information here. You can email me or connect with me on LinkedIn. I love to meet new people and share what I've learned.
If you want to learn more about the tools that we're sharing including what we walked through today, there's articles on the Stitcher 2.0 role, the Scorecard, the Moderator Guide, the Planner, and even more on the way. So, please follow us and give us lots of Claps. It's much appreciated.
If you are in Austin or nearby, you can check out the Austin Design Sprint Meetup. Our next Meetup is on December the 5th. It'll be demoing all the Voltage Control tools, including the Stitcher Dashboard that we just saw. Also, I'm happy to announce that MURAL's going to be sponsoring this month. They'll be providing drinks and snacks, so thank you, MURAL.
David Chin: All right. Well, thank you, everybody, that our time is just about up, and, Douglas, thank you. And, yeah. We'll get you guys the follow-up shortly, and thank you, all, for another great, great session.
Douglas: Thanks, David.