Retained knowledge · Storyline production systems

Master Slides in Storyline

Updated 24 August 2026

For years I began Storyline projects by dutifully creating master slides, then gradually abandoned them as the course became more bespoke. The problem was not the feature. I was asking the master to behave like a finished template instead of treating it as one layer in a design system.

Slide masters become useful when they hold the decisions that really are stable across a course: visual foundations, recurring layout structure and persistent interface elements. Interaction logic, scenario-specific behaviour and content-level exceptions belong elsewhere. That separation is what makes a system reusable without making every screen look identical.

01

What slide masters are good at

Articulate continues to describe Slide Masters as the Storyline mechanism for applying a consistent look and feel across slides and creating layouts for different content types. That is the right level of responsibility for them: shared presentation and structure, not every behavioural decision in the course.

  • Shared backgrounds, brand framing and persistent visual elements.
  • Layouts for recurring screen families such as section openers, content, scenario setup and assessment framing.
  • Theme-level typography and colour decisions that should not drift slide by slide.
  • Placeholders and alignment structures that make the intended composition obvious to the next person authoring the course.

02

Use a small architecture, not a giant template library

A production system becomes harder to use when every possible screen has its own layout. I prefer a small number of masters and layouts that express genuinely recurring structures, then reusable components for the variation inside them.

  • Start with one core master and add another only when a section has a genuinely different structural need.
  • Name layouts by purpose rather than appearance: Section opener, Content + media, Scenario decision, Assessment frame.
  • Keep the layout list short enough that another developer can choose correctly without opening a separate manual.
  • If a layout exists for only one slide, question whether it should simply be a slide-level composition instead.

03

What belongs on the master — and what does not

The useful boundary is stability. If changing an element should change every slide using that layout, the master is a good candidate. If the element depends on the meaning, state or logic of one interaction, it normally belongs at slide or component level.

  • Master: stable brand frame, recurring background treatments, layout geometry, persistent labels and carefully chosen global interface elements.
  • Slide/component: scenario logic, conditional triggers, local variables, content-specific states, one-off media and interaction behaviour.
  • Do not place logic on the master simply because it is technically reusable. Reuse is valuable only when authors can understand and safely modify the behaviour later.
  • Treat feedback, navigation and accessibility behaviour as systems in their own right; a master can support them but does not remove the need to test them.

04

Design-system thinking is the real advantage

The strongest benefit is not saving a few minutes while duplicating slides. It is moving recurring decisions out of individual course screens and into a governed foundation.

  • Define type roles and colour roles once, then use them consistently rather than styling objects ad hoc.
  • Use predictable spacing and alignment rules so layouts feel related even when their content differs.
  • Name masters, layouts, layers and reusable objects so their purpose survives handover.
  • Version the starting file and record meaningful changes. A template without a known version quickly becomes several unofficial templates.

05

Accessibility still has to be designed and tested

Consistency helps accessibility, but a shared layout is not an accessibility guarantee. Storyline’s own release history continues to include fixes involving text styles, screen-reader behaviour, focus and content placed on master layouts. That is a useful reminder that the authored system and the published experience both need checking.

  • Use proper text styles and a logical heading hierarchy rather than treating typography as visual formatting only.
  • Check focus order and keyboard behaviour on representative slides using each layout.
  • Do not assume an object inherited from a master is automatically exposed to assistive technology in the way you expect.
  • Test the published output after Storyline updates when a course depends on persistent master-level interface elements.

06

A practical build sequence

  1. 01

    Define the visual foundations: type roles, colour roles, spacing and recurring frame.

  2. 02

    Identify the small number of screen families that repeat across the course.

  3. 03

    Create masters and layouts for those families, using names that describe their purpose.

  4. 04

    Build reusable interaction components separately from the layout system.

  5. 05

    Create a short example scene that stress-tests every layout with realistic content rather than placeholder text.

  6. 06

    Check keyboard, focus, text styles, contrast and responsive player behaviour in published output.

  7. 07

    Save and version the starting file only after the system survives that test scene.

07

The rule I use now

If a future developer has to remember a convention, the system is weak. Put stable visual and structural decisions where Storyline can inherit them; put interaction behaviour where it can be seen, understood and tested. The goal is not to force every slide through a master. It is to stop every slide becoming a new design decision.

Current product references

Sources checked for this refresh