Skip to main content

Instructional Design: Rationale and Decisions

Dagmar Mikmekova
Troubleshooting Unexpected Search Results
Independent portfolio project · Articulate Rise 360

This document explains the instructional design decisions behind the course, from defining the learning goal and structuring the learning journey to choosing activities, interactions and assessment methods.

1. The learning goal​

I wanted the course to teach a practical way of approaching an unexpected search result. The focus is not on teaching the learner how to configure a search engine, but on helping them investigate the problem before making changes.

The main idea is simple: start with the evidence, narrow down the possible causes, and only then decide what to investigate or change.

2. How I structured the learning journey​

I started with the basic questions a support or customer-facing team would need to ask:

  • What did the system receive?
  • What information is available in the product data?
  • Is the product missing from the results, or is it there but ranked lower than expected?

The lessons then build on these questions. The first lesson introduces the basic checks. The second puts them into a concrete customer situation and asks the learner to make decisions based on new evidence. The third introduces a slightly different case, where the product is present but appears lower in the results.

This gives the learner a progression from understanding the approach to applying it.

3. Keeping the content focused​

I tried to avoid putting too much information on the learner at once. Each section has one main idea or decision, with short explanations and examples.

I deliberately left out detailed search-engine theory because it was not necessary for the goal of this course. I wanted the learner to leave with a practical troubleshooting approach rather than a large amount of background information.

4. How the scenarios work​

The second lesson is built around a customer scenario. The learner first sees the customer's problem and has to decide what to check. They then receive additional evidence and have to make another decision.

I chose this format because it is closer to what someone working in technical support or customer-facing technical roles actually does. Instead of simply reading a list of troubleshooting steps, the learner has to use the information available and decide what to do next.

The scenario also allows the course to show that the answer can change as more evidence becomes available.

5. Why I included knowledge checks​

I used short knowledge checks at points where the learner has enough information to make a decision. The questions are intended to reinforce the troubleshooting approach rather than test detailed technical knowledge.

I considered adding a separate final quiz, but decided against it. The course already contains questions and scenario-based decisions, and another quiz would mostly repeat the same ideas. I preferred to keep the course short and let the activities themselves provide the assessment.

6. Language and clarity​

I wrote the content with a global audience in mind. I tried to use short sentences, familiar words and direct questions, and to avoid unnecessary jargon.

This was particularly important because the intended audience may include people who are not native English speakers. The learner should be able to understand the situation quickly and focus on the technical decision rather than on interpreting complicated wording.

7. Visual and interaction choices​

I used a fairly simple visual style and tried not to add interaction just for the sake of interaction. The different interaction types have a purpose:

  • Flashcards introduce the three initial areas to investigate.
  • The scenario gives the learner a realistic situation in which to make decisions.
  • The process interaction presents the troubleshooting sequence in a way that can be explored step by step.
  • Knowledge checks give the learner an opportunity to confirm their understanding.

I also used a different visual treatment for the customer scenario to make the change from explanation to practice clear.

I also experimented with audio narration in parts of the first lesson, giving learners another way to engage with the content while following it on screen.

8. Iteration and design decisions​

The course changed during development as I looked at it from the learner's perspective. I removed some repetition, simplified several explanations and changed the summary so that it reflects what the learner actually encountered in the lessons.

One of the decisions I made was not to keep adding content simply because it could be added. The aim was to make the course useful and easy to follow, rather than comprehensive.

9. Accessibility and future improvements​

I kept accessibility and readability in mind when designing the course, particularly through short content blocks, consistent headings and clear visual hierarchy.

This is not a formal accessibility audit. For a production course, I would also check keyboard navigation, focus order, alternative text, colour contrast and screen-reader behaviour in the final Rise 360 version.

10. Tools and production​

The course was created in Articulate Rise 360. I used the project to practise developing a complete learning experience, from defining the learning goal and structure to creating the content, scenarios and interactions.