Building Storyline Preferences That Stick

Client

BrightPath Learning By Design – LXD studio [conceptual]

Role

Instructional designer · eLearning Developer

Deliverables

Technical eLearning tutorial · guided Storyline build walkthrough · job aids · custom GPT

Tools

Articulate Rise 360 · Mighty for Rise · Articulate Storyline 360 · Canva · OpenAI GPT Builder

Self-paced eLearning has to work for people engaging with content under different conditions. Extra guidance may help one learner. Reduced motion or fewer visual distractions may help another. Audio-on-demand can be useful in some courses and completely unnecessary in others.

The problem is deciding which of those adjustments deserve to become learner preferences in the first place.

Storyline makes it relatively easy to add another layer, variable or control. That doesn’t mean adding one improves the experience. Too many optional settings can create the very thing they are meant to reduce: clutter, cognitive load and extra decisions for the learner.

Designers therefore need to distinguish between three things: what should be part of the default experience, what is genuinely useful as an optional preference, and what is better left out.

I designed a technical learning experience in Articulate Rise that teaches developers how to decide what should be adjustable, then build those preferences reliably in Storyline.

Rather than starting with variables, layers, states and triggers, the tutorial starts with the design decision:
what should stay in the default experience, what should become a learner preference, and what should be left out. From there, learners follow the pattern through to implementation →

Annotated Storyline examples then break down the technical side of the build, while short explanations make the logic clear: what each component does, why it’s there and how the pieces work together.

I wanted experienced Storyline users to leave with a repeatable approach they can use to make the design call first, then build the preference cleanly – without forcing them through basic software training they already know.

I used an Action Mapping-style approach to work backwards from the performance I actually wanted.

“Understand learner preferences” was too vague. The more useful behaviour was discrimination: given a course context, can the designer decide whether an adjustment belongs in the default experience, should be learner-controlled, or shouldn’t be added at all?

That gave me a much clearer chain from judgement to build. Designers first need to identify the learner need, judge whether the proposed preference would meaningfully help, check that the default experience remains sound, and weigh that benefit against the extra interface and development complexity.

I used four questions to frame that judgement: need, benefit, default integrity and trade-off.

That stopped the learning from becoming a catalogue of things Storyline can do. The point is knowing when not to do them.

A learner preference should change the presentation of the experience, not repair a base course that was incomplete to begin with.

That became an important design rule throughout the tutorial. The default view still needs to carry the required content, meaning and navigation and meet accessibility requirements. Preferences can then add controlled flexibility around that foundation.

For example, extra guidance might sit on a layer and appear only when selected. Decorative motion might be removed for learners who prefer a quieter visual experience. Optional audio controls might be added without permanently taking up interface space.

This also helped clarify what learner preferences aren’t. They aren’t a substitute for accessible design, and they don’t change the learning objective or create a different instructional pathway.

The default does most of the work. Preferences earn their place around it.

Once the design decision is sound, the technical side becomes much easier to teach.

Instead of running through Storyline features one at a time, I show how the pieces behave as a system: a variable stores the learner’s selection; layers or states hold the adjustable elements; conditional triggers apply that choice where it is needed.

The course uses visual models, comparisons and embedded Storyline examples so designers can understand the logic before getting into the mechanics.

I then use the add and remove patterns to show how the same basic architecture can support different preferences without duplicating slides or maintaining separate versions of the instructional content.

Learners can try the preference from the learner side, then open the sandbox file and inspect exactly how it was built.

That build-side view mattered. I wanted the interaction to feel less like “follow these clicks” and more like something a developer could pull apart, understand and adapt.

04 · Give developers something they can actually reuse

The hardest part isn’t building the toggle