Hey folks! I'm on the hunt for advice, stories, and templates for complex design projects, like branching scenarios or general narratives. I'd love to hear from you all about how long it takes you to make complex designs, how you've made it easier on yourself & your clients (like making it more efficient, reducing complexity, stuff like that), and if anyone has any templates you'd be willing to share! Thanks all!
I also have a post breaking down the time to create branching scenarios. Like a lot of things in ID, the answer is always "it depends," but the examples show how the size, multimedia, and other factors affect the writing and development time.
You can access lots of template slides from the Content Library.
If you find an interaction you like, you can redesign it to match your company standards. Then save it as your own template for future use.
There are also lots of examples/templates throughout the Forum, especially in the eLearning Challenge area.
Another tip for improving efficiency: give everything a meaningful name. It's a lot easier to edit and to troubleshoot when objects, layers, motion paths, variables, etc. have related names.
For complex interactions, also consider adding programming notes (e.g., in text off the slide or on a layer that's never shown). Those notes can be helpful when you want to reuse an interaction later, but don't quite remember how the programming works.
Christy, I know! Your post inspired me to write this! I've found Twine to be challenging, though. Do you have any like "tried and trues" for how you initially set up the branching scenario? Like, how would you guide your SME through it--do you already have an end-goal first?
Has anything changed for you since you've written the post?
Thanks, Judy! I was wondering about how you do this in your design phase, though. When you've decided that the branching scenario is the best option, and you're working with your SME(s) to craft it together.
How do you put it together? How do you make it efficient so that you're not starting from scratch every time? Do you have a template you like to use that easily helps you plot out your inputs/outcomes for the branches?
Hah! Well, glad to know my post got you thinking. I don't know how many of my other posts on branching scenarios you have read, but everything starts from having a clear learning objective. For branching scenarios, you may need to narrow it further than usual. It's like microlearning in that respect: you have to narrow the focus to a single behavior to change or task to practice. Based on that objective, the ideal ending is the successful completion of that behavior or task.
I'm not quite sure what you mean by "guide your SME through it." I don't write branching scenarios collaboratively with SMEs. Writing isn't their job, and directly involving them makes everything more frustrating and time consuming for both me and them. Instead, I interview them first to gather information on ideal performance, mistakes, and consequences. I use that interview as the basis to write the scenario.
If by "guide your SME through it" you mean during the review process, you can do a walkthrough with them in a meeting. I usually go through the ideal path from start to finish first, then go back to the beginning to show various alternate paths. If I provide the written transcript of the scenario (and I usually do provide the plain text export from Twine, in addition to the prototype), then my directions tell them to review the prototype first, going through several times to make different choices. Then, they can review the text for any needed wordsmithing.
Thanks, Judy! I was wondering about how you do this in your design phase, though. When you've decided that the branching scenario is the best option, and you're working with your SME(s) to craft it together.
How do you put it together? How do you make it efficient so that you're not starting from scratch every time? Do you have a template you like to use that easily helps you plot out your inputs/outcomes for the branches?
Short answer (which works for a whole lotta ID questions): "It depends."
On what? On the kind of info you can pull from the SME. On the type of scenario and how complicated it is. On what kind of choices and consequences are involved. And on personal programming preferences.
Hopefully, you can find your own efficiencies by analyzing how a new scenario might fit into a previously-used set up -- and recognizing how it differs.
As the "Rule of 6 P's" says: Proper prior planning prevents poor production.
That helps immensely! It's so interesting, the different styles of working. I'm pretty green to branching scenarios (you can probably tell :D), so my assumption was that the ID would write the scenario along with the SME.
Do you have a go-to Twine template that you like to use when building out your paths, or do you generally start from scratch?
I've got all these questions basically because I'm toying with doing a microlearning that's a branching scenario. Reducing the choices and getting straight to the ideal path is gonna be the real challenge, I think.
Branching scenarios aren't exactly something where a template or checklist is going to work (other than perhaps templates within Storyline or for collecting SME information). A template wouldn't make any sense in Twine.
If you're looking for a learning strategy that can be the same every time you create it, and therefore a template would be helpful, then you're looking for something that isn't a branching scenario.
The reality is that every branching scenario project is different, and the branching structures and approaches used depend on the audience, learning goals, and other constraints. There's no "this is the magic easy button." There's a bunch of "here's some considerations and factors to weigh for different approaches." If it was easy, there wouldn't be enough content for me to teach a 2-month-long course on it. :)
You might also find Patti Bryant's presentation on scenario mapping documents helpful. This is a way of collecting and organizing the information from the SME. My own interview process tends to be more fluid than this, but you might find this kind of structure easier.
You might also look at Kimberly Goh's approach. Her examples are more "interactive stories" than true branching scenarios, with a very limited branching structure. She advocates for more of a linear/fake branching/gauntlet structure (she calls it "optimized"). While I disagree with her conclusion that the limited structure is right for most situations, I 100% agree that it's easier to manage. If you're looking for plug-and-play (kind of) branching structure, then this is a better way to go. This might also be a better starting point for you than to do a true branching scenario. https://www.youtube.com/watch?v=e44I1CLlxPk
I'd actually look into Clark Aldrichs shortsim approach. Agin - "it depends" - but the shortsim methodology he's using is super-fast and makes a real difference. Mind you - storyline is extremely ill-suited for quick scenario branching compared to other tools like iSpring talkmaster og branchtrack. It's good for complex stuff involving variables, employing videos etc.
The "it depends" part of my answer relates to how complex you want your scenario to be. Not as in number of decisions made - that's easily tracked and colorcoded in branchtrack (which is easily embedded in Storyline by the way), but as in the complexity of the visual and the role they play on each slide. Branchtrack only supports images, so you'd have to create your visuals to match.
9 Replies
If you'll forgive the shameless self-promotion, I have two blog posts about this.
Managing the Complexity of Branching Scenarios is like the title says: tips for managing the complexity and keeping it from getting out of control.
I also have a post breaking down the time to create branching scenarios. Like a lot of things in ID, the answer is always "it depends," but the examples show how the size, multimedia, and other factors affect the writing and development time.
You can access lots of template slides from the Content Library.
If you find an interaction you like, you can redesign it to match your company standards. Then save it as your own template for future use.
There are also lots of examples/templates throughout the Forum, especially in the eLearning Challenge area.
Another tip for improving efficiency: give everything a meaningful name. It's a lot easier to edit and to troubleshoot when objects, layers, motion paths, variables, etc. have related names.
For complex interactions, also consider adding programming notes (e.g., in text off the slide or on a layer that's never shown). Those notes can be helpful when you want to reuse an interaction later, but don't quite remember how the programming works.
Christy, I know! Your post inspired me to write this! I've found Twine to be challenging, though. Do you have any like "tried and trues" for how you initially set up the branching scenario? Like, how would you guide your SME through it--do you already have an end-goal first?
Has anything changed for you since you've written the post?
Thanks, Judy! I was wondering about how you do this in your design phase, though. When you've decided that the branching scenario is the best option, and you're working with your SME(s) to craft it together.
How do you put it together? How do you make it efficient so that you're not starting from scratch every time? Do you have a template you like to use that easily helps you plot out your inputs/outcomes for the branches?
Hah! Well, glad to know my post got you thinking. I don't know how many of my other posts on branching scenarios you have read, but everything starts from having a clear learning objective. For branching scenarios, you may need to narrow it further than usual. It's like microlearning in that respect: you have to narrow the focus to a single behavior to change or task to practice. Based on that objective, the ideal ending is the successful completion of that behavior or task.
I'm not quite sure what you mean by "guide your SME through it." I don't write branching scenarios collaboratively with SMEs. Writing isn't their job, and directly involving them makes everything more frustrating and time consuming for both me and them. Instead, I interview them first to gather information on ideal performance, mistakes, and consequences. I use that interview as the basis to write the scenario.
If by "guide your SME through it" you mean during the review process, you can do a walkthrough with them in a meeting. I usually go through the ideal path from start to finish first, then go back to the beginning to show various alternate paths. If I provide the written transcript of the scenario (and I usually do provide the plain text export from Twine, in addition to the prototype), then my directions tell them to review the prototype first, going through several times to make different choices. Then, they can review the text for any needed wordsmithing.
Does that help?
Short answer (which works for a whole lotta ID questions): "It depends."
On what? On the kind of info you can pull from the SME. On the type of scenario and how complicated it is. On what kind of choices and consequences are involved. And on personal programming preferences.
Hopefully, you can find your own efficiencies by analyzing how a new scenario might fit into a previously-used set up -- and recognizing how it differs.
As the "Rule of 6 P's" says: Proper prior planning prevents poor production.
That helps immensely! It's so interesting, the different styles of working. I'm pretty green to branching scenarios (you can probably tell :D), so my assumption was that the ID would write the scenario along with the SME.
Do you have a go-to Twine template that you like to use when building out your paths, or do you generally start from scratch?
I've got all these questions basically because I'm toying with doing a microlearning that's a branching scenario. Reducing the choices and getting straight to the ideal path is gonna be the real challenge, I think.
Thanks so much, Christy!
Branching scenarios aren't exactly something where a template or checklist is going to work (other than perhaps templates within Storyline or for collecting SME information). A template wouldn't make any sense in Twine.
If you're looking for a learning strategy that can be the same every time you create it, and therefore a template would be helpful, then you're looking for something that isn't a branching scenario.
The reality is that every branching scenario project is different, and the branching structures and approaches used depend on the audience, learning goals, and other constraints. There's no "this is the magic easy button." There's a bunch of "here's some considerations and factors to weigh for different approaches." If it was easy, there wouldn't be enough content for me to teach a 2-month-long course on it. :)
I have a series of 9 blog posts that explains my process of creating a branching scenario from start to finish. What's on my blog actually is my process; I really don't use templates.
You might also find Patti Bryant's presentation on scenario mapping documents helpful. This is a way of collecting and organizing the information from the SME. My own interview process tends to be more fluid than this, but you might find this kind of structure easier.
You might also look at Kimberly Goh's approach. Her examples are more "interactive stories" than true branching scenarios, with a very limited branching structure. She advocates for more of a linear/fake branching/gauntlet structure (she calls it "optimized"). While I disagree with her conclusion that the limited structure is right for most situations, I 100% agree that it's easier to manage. If you're looking for plug-and-play (kind of) branching structure, then this is a better way to go. This might also be a better starting point for you than to do a true branching scenario. https://www.youtube.com/watch?v=e44I1CLlxPk
I'd actually look into Clark Aldrichs shortsim approach. Agin - "it depends" - but the shortsim methodology he's using is super-fast and makes a real difference. Mind you - storyline is extremely ill-suited for quick scenario branching compared to other tools like iSpring talkmaster og branchtrack. It's good for complex stuff involving variables, employing videos etc.
The "it depends" part of my answer relates to how complex you want your scenario to be. Not as in number of decisions made - that's easily tracked and colorcoded in branchtrack (which is easily embedded in Storyline by the way), but as in the complexity of the visual and the role they play on each slide. Branchtrack only supports images, so you'd have to create your visuals to match.