As we move through our hands-on Articulate training covering the various settings and features of Storyline 360, we often mention, “You might want to add this item to your ‘QA’ checklist.” Many students have inquired about what is involved with creating such a list for quality assurance (QA).
Let’s discuss the benefits of using a checklist before passing your project on for either internal or customer review, and then some tips and best practices for compiling your own.
Why the Need for a Checklist?
Think about the last time you sent a course for QA. Your tester may have identified a few glitches that were basic in nature—things you may have missed because you were in a rush or just simply forgot to check. Perhaps you thought to yourself, “I should’ve checked that over more thoroughly before passing it on.”
The fact is there are simply too many items to keep track of in your head. Even if you are detail-oriented, it can be easy to miss a setting that will negatively impact the user experience. The professional approach then is to self-review your project using a checklist before passing it on to someone else.
Tips for Creating Your Checklist
Since roles and workflow vary depending on the environment you work in, we recommend creating your own design and development checklist. This will involve more work than simply copying someone else’s, but it will ensure that you capture all the tasks that are unique to your specific situation.
First, give thought to the scope of your role in a typical e-Learning project. Are you involved in the needs assessment phase? Are you responsible for content curation and storyboarding, or is your job restricted to e-Learning development only? Your checklist will differ depending on the roles you play.
If you collaborate with a team, work together and develop a standardized review checklist that all developers use. In addition to streamlining the QA process, this will result in consistency in work produced across the team over time.
Finally, organize your checklist items into meaningful categories so that new items that are identified can be slotted easily.
Best Practices and Gotchas
During Storyline 360 training, we make it a point to highlight items that are easy to miss and therefore ideal for your review checklist. Here are a couple of examples:
Revisit Settings
You may have everything working just the way you want, but what happens if the learner revisits a slide by either selecting it in the menu or clicking the previous button? Storyline defaults the revisiting setting to “Automatically decide.”
That simply means that the slide or layer will be reset to its initial state unless there is interactivity on the slide. In that case, it will resume to its saved state. This may be ideal for quiz slides, but likely not the way you want slides with interaction to behave. In such a case, you will need to manually change the setting to Reset to initial state to ensure that the learner is presented with a fresh version of the slide each time they revisit.
Tip: You can configure the revisit settings for multiple slides at once in Story View.
Remember, layers have the When revisiting setting as well. Bulletproof your interactions by testing what happens when layers are displayed a second or third time.
Navigation
We have previously addressed tips for restricting navigation. If you haven’t already taken a look at it, be sure to check it out! We mention that configuring your course menu for restricted navigation will ensure that learners cannot click Next until the timeline finishes on the base layer. However, how can you ensure that learners go through all the interactive elements on a slide before they can click Next? The answer will depend on how you have configured your interactivity. Let’s look at a simple click-and-reveal example using three icons and three layers.
First, change the state of your Next button to disabled when the timeline starts on the slide.
Next, create a Visited state for each icon.
Finally, change the state of the Next button to normal once the state of all three icons is Visited.
As mentioned, the steps may differ depending on the type of interactivity you have created. If you want to ensure that your learners view all interactive components of a slide, be sure to have a strategy and test it thoroughly.
Other Considerations
Here are a couple of other items that you may choose to include on your checklist:
- Use descriptive names for slide objects used in interactions.
- Add developer’s notes for complex slides in an off-slide text box.
- When passing your .story file on to another developer or your client, be sure to pass on the fonts used in the project.
Summary
Hopefully, some of these tips will come in handy as you compile your own review checklist. If you have any questions or would like to share items from your checklist, please leave a comment!
~Shane
Update: Please note that the interface of the faster new trigger workflow (in Storyline 360 update 3.33.20625.0 or later) will appear slightly different! While the process is the same, this article uses screen captures from the classic trigger workflow.
A checklist item I use to ensure I am ready to publish is titled Eyeball. Yukon trainers talk about “poking it’s eye out” in the classroom. This is hiding an asset in the timeline using the eye icon. This is a necessary evil when developing complex scenes/stages.
Prior to publishing I take a moment to verify eyeballs are visible. My best practice is click the “all eyes”off then click a second time to turn them back on the timeline. If a stage only has a minimal amount of assets and you can visually verify, and keep moving.
Hey Randy,
Thanks for the comment! That is a great point and something that happens often. A good tip to add to someone’s list, for sure.