How to Teach Software Through Real-World Scenarios

A professor preparing to speak with a student about an exam has several kinds of work ahead of them. There is information to review, an expectation to check against the instructions students received, and a conversation to begin. Each requires some care. The words used in an invitation can affect the meeting before either person has entered the room.

When I design a software workshop, I want to begin close to that work. I choose a situation people might encounter in their roles, give them something to consider, and introduce the software as its relevance becomes clear. Navigation comes into the lesson alongside the reason for navigating.

For a faculty workshop involving Honorlock, the situation was a conversation about an academic-integrity concern. The workshop, Communicating Academic Integrity, had two objectives: prepare for a conversation with a student and conduct a constructive dialogue. Those objectives gave the session its direction. Knowing where to find information in a proctoring tool would matter because faculty needed to understand what they were bringing into a consequential conversation.

The case gave us a place to begin.

A situation worth attending to

The workshop materials included a scenario card and a sample email from a professor to the student. In the case, an online exam had produced four flags. The observations included looking away from the screen, faint whispering, an electronic alert, and briefly handling an object resembling a phone.

Fictional practice scenario from the Communicating Academic Integrity workshop. Open the full-size scenario card.

Even in that short description, there are different degrees of certainty. A sound was detected. An object resembled something. A glance was visible, but its meaning remained open. The case called for attention to the difference between an observation and the explanation someone might attach to it.

A flag alone does not establish academic misconduct. The handout accompanying the workshop explicitly asked faculty to consider disabilities and accessibility needs, which can affect behavior during a proctored assessment. It also directed them back to their test instructions: the resources allowed, the time limits, and any particular requirements students should have understood before beginning.

I wanted the task to hold those considerations together. Faculty would need to review the available information while leaving room for what they did not yet know. The student would need an opportunity to explain. The institution's process would shape what happened next.

That is a useful starting point for a workshop because it gives the technology a specific place in the work. Participants have a reason to examine what the system makes available, and a reason to be careful about what they conclude from it.

Let the need introduce the feature

The opening activity asked participants to review the scenario card and the email at their table, then discuss the student profile and flagged behavior with their group. The next prompt placed them at a particular moment: the student had arrived for the meeting. They were asked to consider how they would begin, keeping their attention on the situation rather than moving into a general argument about cheating.

This is the sequence I aim for in software instruction. A task brings a question into focus. The question gives a feature a purpose. Then I can show the navigation needed to use it.

In the Honorlock case, the purpose is preparing to discuss the specific concern accurately. Reviewing proctoring information belongs within that preparation. Being able to explain how the relevant information was captured belongs within the conversation. The handout makes that connection explicit when it asks faculty to be ready to discuss how the proctoring solution works in relation to the behavior they are addressing.

I can therefore introduce a control at the point when someone needs to reach or examine that information, explaining the action as I take it. The route through the interface has an immediate use. I can return to the case afterward and ask participants to decide what the information helps them say, what still needs clarification, and where their judgment must remain open.

What does your learner need to decide before they need to know where to click? For anyone adapting this approach, the preparation is quite concrete. Take one step in the task and write down the information a person needs to complete it. Identify the part of the tool that supplies that information, then choose the shortest useful demonstration. Other features can wait until they serve another step, or go into a separate reference for later exploration.

Practice the conversation the tool supports

A case becomes more useful when learners must do something with it. In this workshop, the action was a conversation, beginning with the invitation.

The sample email identified the recent exam, explained that the professor wanted to discuss the proctor's findings, and invited the student to arrange a meeting. Its stated purpose included clarifying misunderstandings. Placing that email beside the scenario extended the activity beyond reading a report: participants could consider how a concern would be communicated to the person affected by it.

The accompanying handout then offered a sequence for the conversation itself. Begin by addressing the situation. Present the relevant evidence and explain the proctoring information. Give the student an opportunity to offer their explanation, listening calmly. Consider that explanation with an open mind. If the concern remains unresolved, explain the applicable institutional process and possible consequences.

There is room for judgment throughout that sequence. A participant has to choose an opening that is clear without treating the conclusion as settled. They have to describe what they have reviewed in terms the student can understand. They have to listen for information that might change their understanding, and recognize when a matter needs to proceed through the institution's established process.

These are useful places to pause a workshop. After a demonstration, return to the decision it was meant to support. Ask participants to compose an opening, explain the relevant observation, or identify what they would need to clarify before taking the next step. A short response can make their thinking available for discussion.

I would keep the same connection in another software workshop, even if the task were less sensitive. Following a demonstration, give learners a small piece of the actual work to attempt. The activity should let them use the feature for the reason it was introduced. Where the task involves interpretation, make space for that interpretation rather than ending as soon as the correct screen is open.

Give the work somewhere to continue

The two-page faculty handout carried the workshop's structure beyond the session. Its preparation section covered reviewing test instructions, considering accessibility, establishing the purpose of the conversation, and notifying the student. The next page set out the conversation sequence and brought together resources, including the academic-misconduct form, the Digital Learning & Academic Innovations homepage, and access to the slides.

I think of a handout like this as something a person should be able to use at the moment the task returns. The headings need to help them locate their place in the work. Someone preparing for a meeting should be able to find the preparation steps quickly; someone considering the next stage should know where to find the relevant institutional resource.

For a workshop built around another tool, I would make the reference follow the same path as the task. Include what to check before beginning, the decisions that deserve care, and the resources someone may need afterward. Brief navigation reminders can sit beside the steps they support. That keeps the explanation of the tool connected to its use, even when the workshop itself is over.

Explore the workshop materials

Explore the workshop slides to follow the activities and discussion prompts.

Open the fictional scenario card. Read the case, then consider what you would clarify before beginning the conversation. The student and all details in the scenario are fictional.

Explore the faculty handout (PDF). Use the preparation steps and conversation sequence to plan a constructive discussion.

A small plan for your next workshop

You can try this approach without rebuilding an entire course. Choose one task that participants recognize from their work and write an objective that names what they will be able to do. Build a case with enough detail to make that task concrete, while protecting the people whose experiences may have informed it.

Before opening the software, check five things:

• The case gives participants a clear action or decision.

• The relevant information is available, and any deliberate uncertainty has a purpose.

• Each feature you demonstrate helps with a particular step.

• Participants will attempt a meaningful piece of the work themselves.

• The reference they take away will help when they face the task again.

Then teach the sequence in that order, allowing the case to determine when the tool enters. You may still show where a button lives, how a setting works, or how to move between screens. Each of those details now belongs to a task the learner has already begun to understand.

In the Honorlock workshop, the task required faculty to attend closely to both the available information and the student who would sit across from them. That responsibility shaped the learning objective, the case, and the supporting materials. It is the starting point I want to preserve when I teach a tool: someone has work to do, and the workshop should help them do it with understanding and care.