MADE for U of T | Ep. 06 | Christy Tucker

Listen to the podcast: Building a branching scenario with Christy Tucker

Or read the transcript:

Prefer to read rather than listen to the podcast? Below is a transcript of the interview.  It has been condensed and edited for clarity.

Christy Tucker (CT): Branching scenarios in particular, are good for more strategic decision making skills rather than things that are specific or are just procedural.  So things that ar, where there is some nuance to it where you can have potentially a good and an okay choice, a partially correct choice, or maybe an acceptable choice and a better choice and a best choice. Things where there's just a very clear black and white right and wrong, with no shades of gray aren’t impossible to write for branching scenarios. But, honestly, there are generally better and easier ways to develop those learning experiences.  For those sorts of skills. I think it's also topics where it is risky to fail. Um! So things where there is a significant cost of or a risk of injury or a big, fine, even a big financial cost or loss of relationship. Those things are good in branching scenarios to practice it because you can practice in that safe environment, and you can choose to go through and make all the worst choices and choose to fail, and then go back and see what would happen when you do it right. So those are the sorts of things. I also think for people, especially people getting started with branching scenarios.   One thing is I've found is I’m teaching people how to do branching scenarios in in workshops, and I have an online class, is that if you are just getting started, it is easiest to pick a really narrow skill definition.  Not to say we're going to teach all of project management in a branching scenario, right? Because that's an enormous task. But maybe the skill that you're going to focus on is how to handle stakeholder requests, for out-of-scope changes. That is a decision with some nuance. There are multiple correct ways to handle that, but it's also a much narrower topic, and I find that one of the places that people get stuck is in not defining the behavior specifically enough.

Inga Breede (IB): Right, and I think you've naturally led me to my next question which is, what are some of those challenges or limitations that designers typically come across when they're building a branching scenario?

CT: So one is, as I just said - that idea of starting with too broad of a topic, that’s a common mistake that I see people do that. It's just too big, and the big problem with branching scenarios is generally that the complexity gets to be so much that it's just unmanageable, and you can't even you can't keep track of it.  You can't figure out how to um do revisions like any stakeholder, feedback, or request for a change ends up breaking your whole structure, and you don't know how to do that. So the figuring out how to manage the complexity is the other piece of it. Some of that is that, you know, having a narrow topic to start with. There are also specific things that we can do to kind of manage the scope in a branching scenario.  In the way that you do your topics, in the way that you do the structure.  Sometimes when we think of a branching scenario, you think “Okay, I've got one decision with three choices. Each of those three choices leads to three more choices, and each of those leads to three more choices.” That exponential growth gets to be extremely cumbersome to manage very quickly. Early on in my consulting work, it's now ten ago, I built a branching scenario that had fifteen different endings. I mean it's in my portfolio because I still like that, and even though it's ten years old, I actually do still like that scenario, and there are a lot of good things in it. And it was probably good that I both wrote it, and then was building it in Captivate at the time and that I was not trying to make some other developer understand that structure, to try to go build it afterwards. If I was going back now, I would collapse more of those endings together, or do a little bit of, you know, handle really, some of those endings were just different because of feedback things that I would handle it with variables and consolidate things a little bit more, and be smarter about my structure, and yes, having extra passages and slides, where it added more to the learner experience, but consolidate some of that together where it was very small nuances that probably didn't need to be there.

IB: Right, ok so Christy, can we talk a bit about the planning? So clearly planning is so key in any of this before you even begin. What are the key components to consider in the planning stage?

CT: So, like all instruction design things, knowing what your learning objective is, is really, really critical. And again, this is now the third question where I've answered, figuring out what your goal is, is the answer, but also getting the learning objective right is really important. Because everything we do should go to that learning objective. So we have those, the learning objective. I tend to think of it in in the planning as four C's: the characters, the context, the challenge, the consequences. Your protagonist or main character should be somebody the learners identify with somebody. This is understanding your audience as learners. And who are they? And what are the challenges that they faced? Context matters because if I’m teaching conflict management in a nonprofit organization that volunteers with teenagers, I'm going to do conflict management differently than if I’m talking about conflict management in a software Development Company, right? Even though there's similar principles, it's going to look different, and the details of the story will be a little different. The challenge is really that the key part of this of what are the challenges that your character faces? What are the places where the learners get stuck? What are the places where people do this task wrong?  I have a long list of questions that I use to interview subject matter experts when I’m doing the planning and the initial analysis. Often as instructional designers, we spend a lot of time talking about the right behavior, right? What's the desired behavior? And how what do you want it to look like? And admittedly, sometimes we do too much of what are the general principles without drilling into the specific behaviors. But assuming that you are doing okay on drilling into specific positive behaviors in branching scenarios, you really need to do analysis also on the mistakes. What do people do wrong? Where do they get stuck? Where are they confused as part of your analysis, And that becomes part of the planning to at least know, like, Okay, these are the really critical mistakes that we've got to include in this scenario. These are a few others that may or may not be included depending on how the structure fall comes out. You also need to know the consequences of these changes, because in a branching scenario we're not giving feedback that just says, “That's correct” and then just move on right here.  And maybe there is a best choice. And it may be that you actually do tell them that is the best route here because of the way that you want to balance things because of the tradeoffs that you're doing and in a particular organization they might prefer that you do tradeoffs in one way or another, and value it that way. Or maybe there is an ideal solution even if there's partially correct things. But it's also not just about telling learners whether they got it right or wrong. It's also about showing them the consequences of their actions. If it's a simulated conversation, simulated conversations are one of the topics that tend to work really well in branching scenarios, because it is that, what do you say? And how do you say it? Because, a nutritional counselor doing, work with a client and needing to get information about regular eating habits. Ask a question about family eating habits can be done in several different ways. Right? You might know that. Yes, you need to ask a question about,  what do you do for breakfast? But there are different ways to ask that are going to get different responses.  Asking a closed yes or no question of “Do you eat breakfast every day?” is going to get you a different limited amount of information. Then, as a nutritional counselor, saying, “Tell me about what you eat for breakfast every day,” the open-ended question is going to get things differently. So you've got that simulated conversation. The consequence of that is going to be the information you get, the response from the other person in the conversation. If it's certain sort of troubleshooting a device, the consequence is going to be you run a test. You do a diagnostic. And here's the results that you get from that or the project management, you know you agree to the scope change, and then  the consequence is that your delivery date gets pushed out two weeks, and we are putting in branching scenarios. We are putting the learning in context. We know that the learning transfer is improved if we can have it similar to the real environment. So, having it in the context, that's that fourth “C,” having it in the context that looks like their work environment, or whatever their performance environment will be helps improve the learning, transfer to that work, environment, or wherever the performance will be.

IB:  So Christy, when you are ready to build, what are some of your favorite platforms that you enjoy working with? So to build branching scenarios you mentioned ten years ago you were working with Captivate. I know that you have experience with Twine.  What are you using these days?

CT: So Twine is definitely the tool that I at least start planning and writing in.  I do almost all of the writing of ranging scenarios, passed the design document because I’m a consultant, and I work with different organizations. If I’m doing this for a client, I will give that a summary, I don't necessarily spell it out as characters, challenges, consequences, and context in a design document for a client. But I do end up with a one paragraph summary of the main character, the context and the situation they're in. And here are the challenges they're going to face, and then probably some sort of list of the ideal path of what the behavior is supposed to look like. And here are some of the mistakes and consequences that I plan to include. I get them to sign off on that before, but Twine is the tool that then, once they've signed off on that, I use Twine for all of the writing.  Twine, if you're not familiar with it is a free, open source program for creating interactive fiction and independent games. There is a ton that can be done with Twine, and I admit even several years into it, I barely scratch the surface of what is possible in Twine. There are a lot of game developers doing some really cool things in this. For the most part I use it because it is faster for me to write something nonlinear in a tool that's designed for nonlinear text. I have done writing things out by hand in a notebook. I have done word documents with tables. I have done excel spreadsheets, PowerPoint slides with links to different places. I have tried to building it directly in the tool. I have done index cards and move them around. I have done post-it notes! I have tried all the things, and Twine is the tool I come back to. Part of that is that in writing, because in writing a branching scenario, the tricky part is always those connections, especially if you have a more complex structure where the paths cross a lot, and so in Twine it's extremely easy to do a passage of text, and then to link to another passage. It literally is, you type double brackets, and then it creates a new passage for you with a link to it. The other reason I really like Twine is that it gives you a functional prototype pretty easy. It'll just be text based, you know you can do a very easy text base, get the text of it, but with functioning links, and I find that in order to get subject matter experts and stakeholders to understand branching scenarios, to get them on board, and to get through reviews - the faster I can get a prototype in front of them where they can click through and understand “Oh, that's what you mean by branching scenario,” the better off I am. And so even just kind of plain text click-through it. Increasingly I have been playing with Twine as a way to do finished products, too. You certainly can. There are plenty of visual development that can happen with it, and Twine is an active, open-source project. There was a significant update this year, so if you haven't used it recently, the big update came out in August (2022), and so the interface has changed. They've reorganized things, and it's really good.  Final products I have built, I probably build in Storyline. I’m at least planning it and doing the prototype in Twine, and then often building final products in Storyline, as much as I like twine. If I’m doing more complex animations and images and things, Storylines still easier for me to do that in.  But there are some other good tools out there. I've done a number of things even, I have a sample on my blog, that is built into Google form because you can use.  Most survey tools have some option of, if you choose “B,” jump to this other section, and so you can build them even in survey tools. If you're looking for another free option, I still think Twine is the better free option for most things.  But I know in lots of education there is often a lot of the restrictions of, you know, you have to use the free tools, because this is what's in the budget, or you're already using lots of Google tools, in which case Google forms might not be a bad plan? There are a lot of tutorials and things that are out there right now are now outdated, and everybody's working on updating them. I have some stuff on my blog and I am in the process of updating it, because it does mean that every screenshot I've ever taken of Twine is now outdated, and I’m going to do some of the updates. There is documentation. There is a cookbook. And there's information on different story formats depending on how technical you want to go.

IB: Awesome!  For learning designers who are interested in scenario building, where would you suggest they begin their journey of discovery?

CT: There are several people honestly talking about branch engineers right now, I mean, really, there's some really good things out there.  I learned quite a bit from Cathy Moore's material, her action mapping and her information Twine it. Cathy Moore has used Twine, and that's actually where I found the tool. I have several things on my blog about things I have. I have a bunch of blog posts on branding scenarios. I do also have a whole series of blog posts that has a start-to-finish on how I created from planning through prototyping and Twine, and then building it in Storyline, where I did step-by-step. Here is a branching scenario. Karl Kapp has a one hour course on branching scenarios in LinkedIn learning and that's a that's a pretty solid overview of things. Kimberly Goh has some good information, hers is more interactive stories and a little bit less branching. I also think if you want to dig in a little bit more, see if I can find the book quickly. Ruth Clark has a book on scenario-based learning, which, if you want to dig into the research and how to do these, the when should branching scenarios be used. When are they good things? Different ways to provide feedback on. How to do that? I have lots of information free on my blog. I have past presentations that I've done, too. I have a whole collection on storytelling and scenarios, posts, and there are specifically things about branching scenarios. I also have a collection of past presentations and podcast interviews that I've done as ways to do things. I think if you're really getting started, go through some of these resources, pick a narrow topic, get Twine, and try building something for yourself. The best way to learn Twine is to have a project. You can watch tutorials and read through blog posts and things, but there is a certain amount that you just can't learn until you go try it.

IB:  Exactly!  And everyone, I’m sad to say, we’ve reached the end of the interview. Christy, thank you so much again for spending your morning speaking with me, meeting the members of MADE; we really do appreciate it!

CT: Thank you!
 

How do I join MADE?

If you're interested in joining the conversation, please fill out the Request to Join M.A.D.E. form and you'll be added as soon as possible.  Can't wait to see you there!