The Logical Blog

A branching interaction fails when every choice eventually lands on the same slide. To learn how to create branching scenarios storyline interactions that feel credible, build the decision structure first, then use Storyline 360 triggers and variables to control what learners see next. This workflow creates a manageable scenario without duplicating your entire course.

Plan The Decision Map Before Building Slides

Start with one workplace decision that has a clear consequence. For example, a manager receives a report of a possible data-security issue. The learner can investigate immediately, ask the employee to handle it alone, or ignore the report.

Limit the first version to three decision points. At each point, document the choice, the immediate consequence, and the next decision. A simple map might look like this in your notes:

• Report the issue immediately: proceed to investigation.
• Ask for more details: delay the response and increase risk.
• Ignore the issue: create a serious consequence and require recovery.

Decide whether the scenario will have separate endings or whether learners can recover from a poor decision. Separate endings are faster to build. Recovery paths are more realistic, but they require additional slides and careful tracking.

Build The Storyline 360 Structure

Create one scene for the scenario. Add a title slide, an opening situation slide, one slide for each decision, consequence slides, and ending slides. Give every slide a meaningful name in Story View, such as `Decision 1`, `Delayed Response`, or `Successful Escalation`.

On each decision slide, add a short setup, then create buttons or clickable response cards for each option. Use the same layout and button position throughout the scene. Consistent placement lets the learner focus on the decision instead of searching for controls.

Do not create a separate copy of every later slide for every path unless the content truly changes. That approach works for a short scenario, but it becomes difficult to revise. Instead, reuse common decision slides and use variables to change feedback, status, or the final result.

Create A Variable To Track Choices

Open Manage Project Variables and create a number variable named `RiskScore`. Set its default value to `0`. This variable will record the impact of the learner’s decisions.

On the first decision slide, select the response that represents the safest action. Create a trigger that adjusts `RiskScore` by `0` when the user clicks that response. For a less effective response, adjust the variable by `1`. For the highest-risk response, adjust it by `2` or `3`.

Add the trigger before the trigger that jumps to the next slide. Trigger order matters. Storyline processes triggers from top to bottom, so the score must change before the learner leaves the slide.

Repeat this process on each decision slide. Your learner may travel through different branches, but `RiskScore` preserves the overall pattern of their choices. This gives you a practical way to create tailored results without building dozens of endings.

Add Conditional Feedback

Create a feedback layer on a consequence slide. Add a text box that explains what happened and why it matters. Then create alternate states for the text box, such as `Low Risk`, `Moderate Risk`, and `High Risk`.

Use triggers to change the state of the text box when the timeline starts. For example, change the state to `High Risk` if `RiskScore` is greater than or equal to `3`. Change it to `Moderate Risk` if the score is equal to `1` or `2`. Use the normal state for a score of `0`.

Place the highest-score condition first if the trigger conditions could overlap. A score of `3`, for example, also meets a condition of greater than `1`. Clear, mutually exclusive conditions prevent the wrong feedback from appearing.

Route Learners To The Right Ending

Add three ending slides: `Effective Response`, `Needs Improvement`, and `High-Risk Outcome`. On the final decision slide, create jump triggers that run when the learner clicks Continue.

Set the first trigger to jump to `High-Risk Outcome` if `RiskScore` is greater than or equal to `4`. Set the next trigger to jump to `Needs Improvement` if `RiskScore` is greater than or equal to `2`. Set the final trigger to jump to `Effective Response` if `RiskScore` is less than `2`.

The conditions must cover every possible score. If one score has no matching condition, the button will not take the learner anywhere. Check the maximum possible score by adding the highest value assigned at each decision.

On each ending slide, explain the outcome in workplace terms. Avoid vague feedback such as “That was incorrect.” Instead, identify the consequence and the corrective action: “The delayed report allowed access to remain active. Escalate suspected security issues through the approved reporting channel immediately.”

Test Every Branch Before Publishing

Use Storyline 360 Preview mode to test the entire scene, not just individual slides. Follow every response combination, including the least likely choices. Keep a copy of your decision map beside you and mark each path as you test it.

Verify that each choice updates `RiskScore`, each feedback state matches the score, and every Continue button reaches an ending slide. Also test revisiting slides. If learners can use the Player navigation controls, they may return to a decision and change an answer. Decide whether that behavior is acceptable. If not, restrict navigation or design the scenario so learners move forward only through scenario buttons.

Finally, review the slide names and trigger panel one more time. A well-named scene makes future edits much faster, especially when another developer must maintain the project.

A branching scenario does not need dozens of unique paths to feel meaningful. When choices produce visible consequences and your variables preserve the learner’s decision pattern, you can build an interaction that is realistic, maintainable, and ready for production.

A quiz can look finished and still report the wrong completion status. The best Storyline quiz settings are the ones that align the learner experience, passing requirement, and LMS reporting before you publish.

Start With The Results Slide

Insert a Results slide after your scored questions. Select the Results slide, open Results Slide Properties, and include only the questions that should count toward completion. This matters when you have knowledge checks that provide feedback but should not affect the final score.

Set the passing score to match your requirement. For example, if learners must answer eight of 10 questions correctly, enter 80%. Do not assume the default score is correct. A Results slide can calculate points, percentages, or both, depending on how your questions are configured.

Configure Attempts And Failure Behavior

Open the Results slide properties and set Attempts based on your policy. One attempt is appropriate when the LMS must record a single assessment result. Multiple attempts work better when learners need an immediate chance to correct mistakes before completion is reported.

For a retry, add a Retry Quiz button to the Failure layer. Verify that the button uses the trigger Reset results and then jumps to the first question. Without resetting results, Storyline may retain the prior attempt data.

Set Feedback For The Right Moment

Open each question and choose Form View. Use the Feedback area to determine whether learners see feedback by answer choice or only after submitting the question. Immediate feedback supports practice quizzes. For a scored test, limit feedback until the Results slide so learners cannot use answer-specific feedback to work through the assessment.

If you allow retries, decide whether learners can review answers before trying again. Review can be useful for remediation, but it may undermine a formal assessment. Your setting depends on whether the quiz is practice or a recorded evaluation.

Choose LMS Tracking Carefully

When publishing for LMS, select Tracking and choose Track using quiz result. Then select the Results slide you configured. Set the reporting status to Passed/Incomplete when a passing score is required. Choose Complete/Incomplete only when viewing the content, rather than passing the quiz, is the completion requirement.

Use Passed/Incomplete for a compliance assessment. Use Complete/Incomplete for a knowledge check that should not prevent learners from finishing.

Test The Best Storyline Quiz Settings

Publish to Review 360 or your LMS test environment and complete two runs: one passing attempt and one failing attempt. Confirm the score, status, retry behavior, and review behavior in the LMS record. A two-minute test before deployment prevents the far more expensive problem of correcting incomplete or inaccurate learner records later.

If you’re developing eLearning with Adobe Captivate Classic, take a close look at the text in your published HTML5 output.

Does it look just a little out of focus?

That’s the best way I can describe the problem. The text isn’t so blurry that it’s unreadable. In fact, you might not notice the problem immediately. But compare the published text with properly rendered browser text and the difference becomes obvious. Captivate Classic’s text can look slightly soft or fuzzy.

Here’s a simple slide created in Captivate Classic.

And here is how the text previews. Notice that the font is slightly out of focus.

I’ve confirmed the issue with Captivate Classic 11.8.3.8, and after quite a bit of testing, I’ve also confirmed two ways to deal with it.

First, It’s Not Your Project Resolution

One of the first things I suspected was project size.

My original project was 1024 x 768. That’s an older project size, so I wondered whether scaling the project on today’s larger displays was responsible for the slightly out-of-focus text.

I resized the project to 1280 x 720.

It made no difference.

I also created a brand-new Captivate Classic project containing a single slide with simple Arial text.

The published text was still slightly out of focus.

So let’s get this out of the way:

This problem has nothing to do with your Captivate project dimensions or resolution.

Changing a 1024 x 768 project to 1280 x 720, 1920 x 1080, or some other resolution isn’t the solution.

I also tested Scalable HTML Content, both enabled and disabled. That didn’t solve the problem either.

The issue followed the published content across different computers, browsers, operating systems, an LMS, and SCORM Cloud.

Solution #1: Upgrade the Project to Adobe Captivate 13.1 or Newer

This is my number-one recommendation.

If possible, upgrade your Captivate Classic project to Adobe Captivate 13.1 or newer.

I tested the same content after upgrading it to the new Captivate and confirmed that the slightly out-of-focus text problem goes away.

The text renders crisp and sharp.

If you’re maintaining an older Captivate Classic course and the project can be successfully upgraded, this is the solution I’d choose.

Of course, depending on the complexity of your Classic project, upgrading may not always be practical. Classic has features and workflows that don’t necessarily translate perfectly to the new Captivate.

Fortunately, if you need to remain in Classic, I found a workaround.

Solution #2: Add a Blank Variable to the Text

This one surprised me.

Create a user variable in Captivate Classic. For example:

vSharp

Leave its value blank.

Next, insert the variable reference into a Smart Shape containing text:

Preview the project again.

In my testing, the difference was immediate. The text that previously looked slightly out of looked better.

Because vSharp contains no value, learners don’t see anything extra. The variable simply sits invisibly inside the text.

There’s an Important Catch

Unfortunately, you cannot add $$vSharp$$ once to a slide and fix every text object on that slide. The variable reference has to be included in each affected text object. For example, if a slide contains five Smart Shapes with text, adding $$vSharp$$ to one Smart Shape fixes the rendering of that Smart Shape. The other four are unaffected.

Putting the variable in a separate object on the slide doesn’t fix the other objects, either. Nor can you simply put it on a Master Slide and expect all of the project’s text to become sharp.

That’s obviously not an appealing workaround if you have a large Captivate Classic project containing hundreds of text objects. It’s also why upgrading the project to Adobe Captivate 13.1 or newer remains my first recommendation.

Why Does Adding a Variable Work?

The behavior suggests that Captivate Classic uses a different rendering method when an object contains dynamic text.

With ordinary static text, Captivate Classic’s HTML5 output can make the characters appear slightly soft or out of focus.

Add a variable, however, and Captivate has to account for the possibility that the text could change while the course is running. That appears to cause Captivate to render the text differently.

The result is noticeably sharper text.

I want to emphasize that this is an explanation based on the behavior I’ve observed rather than documentation from Adobe. What I can confirm is the result: adding the variable fixes the problem in my testing.

Looking for Captivate training, mentoring, or support? I’ve got you covered!

The familiar pause after asking, “Any questions?” is not proof that participants have nothing to say. In a virtual session, silence can mean they are processing, unsure how to enter the conversation, juggling chat and shared screens, or reluctant to be the first voice heard. Knowing how to handle quiet participants means designing clear, low-pressure ways for people to respond before silence becomes the default.

Set Up Participation Before The Session Starts

Do not wait for the first quiet moment to establish expectations. In your session invitation or opening message, tell participants exactly how they can contribute: voice, chat, reactions, polls, and shared documents. This removes a common barrier: participants who do not know whether an interruption, chat message, or camera-off response is acceptable.

Open with a participation agreement that is specific enough to use. For example: “You will have several ways to contribute today. Use chat for questions at any time, respond to polls when they appear, and expect short breakout activities where each group will report one decision.” This is more effective than asking everyone to “stay engaged.”

Before you begin the main content, ask a simple, non-threatening question that everyone can answer in chat. Use a prompt such as, “What is one result you need from this session?” or “Rate your confidence from 1 to 5.” Read several responses aloud and acknowledge patterns you see. Participants learn immediately that the chat is active, monitored, and useful.

How To Handle Quiet Participants With Better Prompts

Broad questions create long pauses. “What do you think?” requires participants to interpret the question, decide whether their answer is worthwhile, and choose a way to speak. Replace it with a prompt that defines the response you need.

Instead of asking whether the group understands a Storyline 360 trigger sequence, ask: “In the chat, type A if the trigger should run when the timeline starts, or B if it should run when the user clicks the button.” Instead of asking for general reactions to a Captivate simulation, ask: “Which step is most likely to confuse a first-time user: the login, the navigation menu, or the final submission?”

Give participants time to answer. After asking a question, say, “Take 20 seconds to decide, then post your answer.” Count silently if necessary. Facilitators often fill silence after three seconds, which teaches the group that waiting is unnecessary. A stated response window makes the pause feel intentional rather than uncomfortable.

Use a sequence of low-effort to higher-effort responses. Start with a reaction or one-word chat response. Follow with a choice between two options. Then ask one or two participants to explain their selection. This progression works especially well when the group has not worked together before.

Use Chat As A Deliberate Participation Channel

Chat should not be an afterthought or a place where questions disappear while you present. Assign it a job at planned points in the session. Ask participants to post an answer, identify a risk, share a tool setting, or add a question before you move on.

When you receive chat responses, do not simply say, “Great comments.” Name the contribution and connect it to the task. For example: “Jordan selected option B because the learner must click the object first. That is the key distinction when building this trigger.” This confirms that chat participation has the same value as speaking aloud.

If you have a co-facilitator, ask that person to monitor chat and surface themes. If you are facilitating alone, stop at defined intervals to review it. A practical rhythm is to pause after each major demonstration, read two or three responses, and answer questions that affect the next step. Tell participants when you will do this so they do not repeat themselves through audio.

Avoid forcing people to unmute without warning. Directly calling on someone can work with an established team, but it can also increase withdrawal when participants are in a noisy environment, need accessibility accommodations, or are processing a complex task. Offer a choice: “Alex, if you are comfortable sharing, what did you select? You can answer by voice or in chat.” Then move on quickly if they decline or do not respond.

Give Breakout Groups A Concrete Output

Breakout rooms can either create useful discussion or multiply silence. The difference is usually the task design. Never send participants to a room with only “Discuss this topic.” Give them a deliverable, a time limit, and a reporting method.

For a software practice session, provide a short scenario and ask each group to make one decision. For example: “Your course needs a button that appears only after the learner views a video. Decide which Storyline 360 condition you would use and write one sentence explaining why.” Ask groups to put their answer into a shared chat, worksheet, or slide before returning.

Assign roles when the group is larger than three people: a facilitator, a recorder, and a reporter. Rotating roles across activities prevents the same confident participant from carrying every report-out. For pairs, skip formal roles and ask each partner to submit one part of the answer.

Visit breakout rooms early. Do not wait until the final minute. A brief message such as, “You have six minutes remaining. Be sure your recorder is capturing the group’s decision,” can restart a stalled conversation without taking over. If a room is quiet because the task is unclear, clarify the expected output rather than repeating the entire instruction.

Respond To Silence Without Making It Personal

When a participant has not contributed, avoid labeling them as quiet or putting them on the spot. You do not know whether they are observing carefully, managing a technical issue, or contributing through a channel you have not noticed.

Use inclusive invitations tied to the work. Say, “We have heard one approach. I would like two different perspectives before we choose a direction.” Or say, “If you have built this type of interaction before, add one caution in chat.” These prompts invite expertise without requiring an individual to perform.

If a particular participant needs to contribute because they own a decision or have relevant subject-matter knowledge, contact them privately through direct message. Ask a focused question: “When we reach the approval workflow example, could you share the one approval step your team cannot change?” Private advance notice is more respectful and produces a better response than an unexpected public request.

Close The Loop After The Session

End with an individual action, not another open-ended request for questions. Ask participants to post the next task they will complete, the setting they will test, or the issue they still need to solve. A prompt such as, “In chat, complete this sentence: ‘Before my next build, I will…’” gives you evidence of participation and reveals where follow-up is needed.

Review the chat, poll results, and breakout outputs after the session. Look for sections where responses dropped, questions repeated, or only a few people contributed. Those are not simply participant problems. They are signals to tighten the next prompt, shorten a demonstration, or provide a clearer practice task.

Quiet participants do not need a louder facilitator. They need a session structure that makes contribution clear, safe, and worth their time. Build that structure into your next virtual session, and participation becomes part of the work rather than a request made after the silence begins.

A well-placed interaction can answer a learner’s question without forcing them to leave the slide, replay narration, or search a job aid. This guide to Captivate widgets shows you how to add a useful on-screen interaction, configure its behavior, and test it before publishing. The example uses an accordion-style widget because it is effective for policies, product details, and process notes that learners need to review at their own pace.

Choose The Right Widget For The Task

Start by identifying the learner action you need. A widget should solve a specific navigation or content-access problem, not decorate an otherwise complete slide. Use an accordion when learners need to reveal related details, a tabbed interaction when content belongs in parallel categories, and a glossary-style interaction when a course contains terms that need quick definitions.

Avoid placing a widget on a slide that already asks learners to complete a simulation, answer a knowledge check, or make a decision. Too many clickable objects compete for attention and make it harder to tell what must be completed. Give each slide one primary task.

Before you insert anything, write the content for each panel in a plain-text document. Keep headings short and distinct. For example, a workplace safety slide might use “Before Starting,” “During Operation,” and “After Shutdown” rather than three vague labels such as “Step 1,” “Step 2,” and “Step 3.” This small preparation step makes the widget easier to build and easier to review with subject matter experts.

Add A Widget In Adobe Captivate

Open the project and navigate to the slide where the interaction belongs. In Adobe Captivate Classic, open the Widgets or Learning Interactions area from the available panels, then select the interaction you want to use. Depending on your Captivate version and installed assets, the exact panel name and available widget library can vary. Choose an HTML5-compatible interaction when your published project will run in a browser or learning management system.

Insert the widget onto the slide and immediately resize it to match the slide layout. Do not stretch the interaction to fill unused space simply because it can be enlarged. Leave room for a clear slide title and, if needed, a brief instruction such as: “Select each section to review the required checks.”

Place the widget where learners expect to find it. For left-to-right courses, a vertical accordion often works well along the center or left side of the slide, with supporting imagery to the right. A horizontal tab interaction usually needs more width and works best when labels are short.

If your project uses responsive layouts or has a mobile delivery requirement, preview the slide at smaller sizes before you commit to the design. Some legacy widgets do not scale or reflow as cleanly as native Captivate objects. If the interaction becomes hard to read on a phone or tablet, rebuild the content using text, buttons, states, and advanced actions instead of trying to force an unsuitable widget into a responsive design.

Configure Content And Learner Behavior

Select the inserted widget and open its Properties or configuration options. Add each heading and its corresponding body text. Write for scanning: use short paragraphs, plain language, and only the details learners need at that moment. A widget is not the place to paste an entire procedure manual.

Next, decide how the interaction should behave. Many widgets allow you to control which panel opens first, whether multiple panels can remain open, and the visual treatment of active and inactive sections. Set the first panel deliberately. If learners need context before choosing a section, begin with a brief introductory panel. If every section is equally important, leave the widget closed and use an instruction prompt.

Consider completion requirements carefully. Requiring learners to open every accordion panel can be appropriate when each panel contains mandatory safety, compliance, or process information. It is less appropriate when the widget is supplemental reference material. If the interaction is optional, do not make slide completion depend on it. Learners should not be blocked from progressing because they chose not to open a definition or troubleshooting note.

Check the widget’s appearance against your project theme. Update fonts, colors, and button states where the widget permits customization. Maintain enough contrast between labels and their backgrounds, particularly for active and visited states. If a learner cannot distinguish an unopened section from one already reviewed, the interaction loses much of its value.

Set The Slide Timeline Correctly

A widget can appear correctly in Edit view and still fail in the published course if its timeline is too short. On the Timeline panel, confirm that the widget remains visible for the entire duration of the slide. Extend its display time to the end of the slide unless you have a specific reason to hide it.

Then inspect any slide audio. If narration explains the interaction, make sure the widget appears before the instruction is spoken. A common production error is placing a widget late on the timeline while the narrator says, “Select each tab now.” Learners hear the instruction but have nothing to select.

For a self-paced interaction, pause the slide until the learner takes action only when that pause supports the task. If the learner must review a required sequence, a pause can prevent them from advancing before the content appears. If the widget is only a reference aid, allowing the timeline to continue is usually the better choice.

Test Widget Completion And Navigation

Use Preview From This Slide first. Select every panel, close and reopen the interaction, and confirm that text is not clipped. Test with the keyboard if your delivery standards require keyboard access. Verify that focus moves predictably and that the active element is visible.

Then preview the entire project. This matters because slide navigation, quiz settings, and project-level completion rules can affect widget behavior. Test these four conditions:

1. Open the slide and advance without using the widget.
2. Open one section, then use the Back and Next buttons.
3. Open every section and revisit the slide.
4. Test the course at the smallest screen size your audience is likely to use.

If the slide should require interaction before advancing, confirm that Captivate recognizes the required action. If it does not, use a clearly labeled Continue button with an advanced action or a completion condition that matches your project’s navigation design. Do not assume that simply viewing a widget will register as meaningful completion.

Publish And Verify In The Delivery Environment

Publish a test version using the same output format and learning management system settings planned for the final course. Browser preview is useful, but it does not replace testing in the actual delivery environment. Launch the published course, open the widget, complete the slide, exit, and resume the course to ensure the interaction and bookmarking behave as expected.

Document the widget’s purpose in your project notes. When another developer updates the slide later, they should know whether the interaction is required content, optional reference material, or part of a completion rule. That one note can prevent a quick edit from breaking navigation or reporting.

A widget earns its space when it gives learners control without adding friction. Build it around one clear job, test it where learners will actually use it, and you will create a Captivate interaction that supports performance instead of merely adding clicks.

A generic Correct layer tells learners whether they succeeded. It does not tell them why. These Storyline feedback layer examples show how to build feedback that reinforces a decision, corrects a misconception, and gives the learner a controlled second attempt.

Build The Feedback Layers First

On a question slide, select Slide Layers and create three layers: Correct, Try Again, and Incorrect. Give each layer a clear title and add a headline, a short explanation, and a button labeled Continue, Review, or Try Again.

In each layer’s properties, select Prevent the user from clicking on the base layer. This prevents learners from changing an answer while feedback is visible. Leave Pause timeline of base layer selected when the base slide contains audio, animation, or a timer that should not continue behind the feedback.

Example 1: Explain A Correct Decision

Use the Correct layer to confirm the learner’s reasoning, not merely the answer. For a compliance scenario, write: “Correct. You paused the transaction because the customer’s identification did not match the account record.”

Add a Continue button. Create a trigger that jumps to the next slide when the user clicks it. If you want the learner to revisit the decision before moving on, use Hide this layer instead. They can then review the selected option on the base layer.

Example 2: Create A Try-Again Layer

A Try Again layer works best when one wrong choice reflects a recoverable mistake. Add concise coaching, such as: “Not quite. Before approving the request, verify whether the manager has delegated approval authority.”

Add a Try Again button with two triggers. First, adjust the relevant variable or reset the interaction if needed. Then hide the layer. On the layer, set Hide objects on base layer only if showing the original choices would distract from the coaching.

Use conditions on your answer triggers so this layer appears only for the answer that deserves another attempt. For example, show Try Again when the learner selects Choice B, but show Incorrect when they select Choice C.

Example 3: Clarify A Critical Error

Reserve the Incorrect layer for choices that reveal a serious misunderstanding. State the consequence and the correct action: “Incorrect. Sharing the report through a personal file-sharing account exposes confidential data. Use the approved secure workspace instead.”

Include a Review button that hides the layer and returns learners to the question. If the error should end the attempt, use a Continue button that advances to an explanation slide instead.

Test Trigger Order

Preview the slide and test every answer. In the Trigger panel, confirm that Storyline evaluates the feedback trigger before any jump-to-slide trigger. If a learner is skipping your feedback, move the feedback trigger higher in the list or add conditions that prevent navigation until the layer is closed.

Specific feedback layers turn a standard question into a guided decision. Build the layer around the mistake the learner actually made, and your Storyline interactions will feel more purposeful and polished.

A deadline is not, by itself, a reason to select Rise 360. When should teams choose Rise? Use the decision process below before anyone creates a lesson, imports media, or assigns development work. It will tell you whether Rise supports the deliverable you actually need.

Start With The Required Learner Experience

Open the project brief and write one sentence describing what learners must do on screen. If they primarily need to read, watch, reflect, answer knowledge checks, and move through a clear sequence of lessons, mark the project as a strong Rise candidate.

Next, flag any requirement for a custom simulation, freeform interaction, complex branching, or highly controlled screen behavior. These requirements do not automatically rule out Rise, but they should stop the team from assuming a block-based lesson will be enough. Confirm the interaction before selecting the authoring approach.

Check The Content Structure

Choose Rise when the course can be organized into short lessons with repeatable sections. For example, a policy rollout might use a scenario, labeled graphic, process steps, video, and quiz in each lesson. That structure lets multiple developers build consistently without creating a different interface for every topic.

Create a simple outline with lesson titles and identify the block type for each section. If most sections fit existing Rise blocks, proceed. If your outline repeatedly says “custom layout,” “animated decision path,” or “software practice,” pause and revise the production plan before building.

Confirm Who Must Update The Course

Rise is especially useful when subject matter experts or distributed team members need to review and update content without editing a complex timeline. Assign one owner to establish the lesson structure, block choices, image treatment, and writing conventions. Then have reviewers edit only the content assigned to them.

Before production begins, create one approved sample lesson. Use it to confirm heading style, button labels, alt text, media size, and quiz feedback. This small step prevents a shared project from becoming a collection of inconsistent pages.

Run A Five-Minute Go Or No-Go Check

Choose Rise for this build if you can answer yes to these questions: Does the course follow a linear or lightly branched lesson structure? Can learners succeed with standard blocks and knowledge checks? Will a responsive, browser-based layout meet stakeholder expectations? Can the team agree on a reusable lesson pattern?

If one answer is no, document the requirement and resolve it before committing. A fast start is only useful when it avoids rework.

Build the sample lesson first, publish it for stakeholder review, and use that approval as your production standard. Your team will move faster because every later lesson has a proven model to follow.

A RoboHelp project can contain hundreds of topic files, but your published help should not feel like a file cabinet. To learn how to organize RoboHelp topics, separate the structure used by authors from the navigation used by readers. Folders keep project assets manageable; the table of contents controls what users see.

Organize RoboHelp Topics In Folders

Open the Contents or Project panel and review your existing topic list. Create folders that reflect the subject area or product workflow, such as Getting Started, Administration, Configuration, and Troubleshooting.

Move related topics into the appropriate folder. Keep folder names short and specific. For example, place Reset a Password and Change a Password in an Account Management folder rather than a catch-all Miscellaneous folder.

Do not use folders as your only navigation plan. A folder is primarily an authoring tool. Readers navigate the table of contents, search results, related topics, and browse sequences.

Build A Reader-Focused Table Of Contents

Open the table of contents and create top-level books for the major tasks your audience performs. Then drag topics into the books in the order a reader needs them.

A useful sequence is: overview, prerequisites, procedure, verification, and troubleshooting. This order works especially well for technical documentation because it answers the questions readers have while completing a task.

Use book labels that describe an action or clear subject. Configure Email Notifications is stronger than Email Options. If one topic belongs in more than one section, consider adding it as a reference instead of creating duplicate topic files that can drift out of sync.

Add Browse Sequences For Linear Content

For procedures that must be completed in order, create a browse sequence. Add the topics in the exact order readers should follow them, then enable browse navigation in your output preset if appropriate.

Browse sequences are useful for setup instructions, onboarding documentation, and multi-part configuration tasks. They are less useful for reference content, where readers typically jump directly to a specific answer.

Test The Structure Before Publishing

Generate your output and test it as a first-time reader. Start from the table of contents, use search, and follow the Next and Previous controls. If you cannot find a topic quickly, revise the book name, topic title, or placement.

A disciplined RoboHelp structure makes updates faster for your team and makes answers easier to find for your users. Build the organization around real reader tasks, then maintain that pattern as the project grows.

A responsive course can look excellent on a 27-inch monitor and become frustrating on a phone when text shrinks, controls crowd the screen, or interactions require mouse precision. This responsive eLearning design guide shows you how to build Storyline 360 slides that remain usable across screen sizes without creating separate versions of the same course.

Storyline 360 uses a responsive player, but your slide content does not automatically rearrange itself for smaller screens. The player scales the slide stage. Your job is to design each slide so that scaling does not make its content unreadable or difficult to operate.

Set Up A Mobile-Safe Slide Foundation

Start with Storyline’s default 16:9 slide size unless your organization has a documented reason to use another format. A widescreen slide gives you a practical canvas for desktop viewing while fitting modern tablet and phone displays more naturally than 4:3.

Before building interactions, establish a safe content area. Keep important text, buttons, and visuals away from all four slide edges. A useful working rule is to leave at least 40 pixels of clear space around critical objects. This prevents content from feeling cramped when the player controls appear and gives learners more room to tap accurately.

Use the same placement rules on Slide Masters. Put persistent items, such as a course title or visual header, on a master only if they serve a clear purpose on every slide. A decorative banner that consumes 20 percent of a phone screen is not helping the learner complete the task.

Build A Responsive eLearning Design Guide Layout

Treat each slide as one decision, one explanation, or one action. If a slide requires learners to read a paragraph, inspect a detailed diagram, and select from six choices, it may work at full size but will become demanding on a phone.

Build from the center outward. Place the primary instruction first, then the required interaction, then supporting detail. This creates a visual hierarchy that still holds up when the slide stage is reduced. If an object is optional, consider placing it on a layer that learners can open with a clearly labeled button such as View Example or Show Details.

Use font sizes that can survive scaling. For body text, begin at 20 points or larger. For headings, begin around 28 points and adjust based on the typeface and amount of content. A 14-point font may look acceptable while authoring, but it becomes a poor choice once the slide is viewed on a narrow phone screen.

Keep paragraphs short. Instead of placing five sentences in one text box, write a concise instruction and reveal the supporting explanation after the learner selects a button. You are not hiding essential information. You are controlling when detail appears so the slide remains readable.

Replace Mouse-Only Interactions

Drag-and-drop activities are common trouble spots in responsive Storyline projects. They can work on touch devices, but they demand accuracy and may be difficult for learners with motor limitations. When the learning objective is recognition or decision-making, use a tap-friendly alternative.

For example, replace a drag-and-drop sorting task with a button set. Present one item at a time and ask the learner to select the correct category. Use states to show Selected, Correct, and Incorrect feedback, then use triggers to continue after a response. The learner accomplishes the same decision-making task with a simpler interaction.

Also review every object that learners must select. A small text link or icon may be easy to click with a mouse but difficult to tap. Increase the clickable area by placing a transparent shape behind the visible object and assigning the trigger to that shape. Name the object clearly in the Timeline so you can identify it later.

Avoid relying only on hover states for instructions or feedback. Touchscreen learners do not hover. If a learner must know what an icon means, add a visible label, provide an accessible tooltip alternative, or open the explanation with a click or tap.

Simplify Images And Screen Captures

Detailed screenshots often fail on mobile screens because the learner cannot read the interface labels. Do not shrink a full application window until it fits. Crop the screenshot to the exact control the learner needs to find, then add a highlight box, callout, or numbered marker.

When a process includes several controls, use multiple slides or layers. Show one action per view: select the tab, choose the command, then confirm the setting. This approach makes screenshots larger, reduces cognitive clutter, and gives learners a better chance of following the procedure on any device.

For diagrams, favor clear shapes and short labels over dense illustrations. If every label is necessary, divide the diagram into labeled sections that learners can reveal one at a time. Storyline layers are especially useful here because they preserve the main slide while letting you present detail at a readable size.

Configure The Player For The Smallest Screen

Open Player Properties and review the player as if the course will be completed on a phone. Keep only controls learners truly need. If your slide includes custom navigation, remove duplicate player navigation. If you use the built-in Next and Previous buttons, do not add competing navigation buttons to every slide.

Use descriptive labels for player controls and custom buttons. Labels such as Continue, View Procedure, and Try Again tell learners what happens next. Labels such as Click Here and More do not.

For accessibility, verify that keyboard navigation follows the visual order of the slide. Open the Focus Order window and move decorative objects out of the order when they do not convey meaning. Make sure buttons, hotspots, and form controls have meaningful accessible names. A responsive design is stronger when it works for touch, mouse, keyboard, and screen-reader users.

Test In The Right Order

Do not wait until the project is complete to test responsiveness. After you create a representative slide with text, an interaction, feedback, and navigation, publish a temporary version and test it before duplicating that pattern across the course.

Test at least these conditions: a desktop browser at normal zoom, a tablet in portrait orientation, a phone in portrait orientation, and a phone in landscape orientation. On each device, check whether learners can read the instruction without zooming, tap every required control, recover from an incorrect answer, and move forward without confusion.

When something fails, resist the urge to simply shrink it. First remove unnecessary content. Next split the slide or move supporting material to a layer. Only then adjust object sizes and spacing. This sequence protects usability instead of forcing more information into less space.

A polished Storyline course is not the one with the most objects on a slide. It is the one learners can complete confidently on the device they actually have in front of them.