Category: Automation

This year, we created a series of 90s-themed cybersecurity games to support our annual compliance campaign.

Designing the games was the fun part.

Then came the less glamorous question:

How would we track who completed them?

The obvious answer was our LMS. It was also a much bigger answer than we needed.

The Games Expanded the Campaign

Our employees already had an annual cybersecurity course to complete. The games weren’t meant to replace it. They gave people more ways to notice, explore, and talk about the campaign around it.

These were short, fun challenges or browser-based games. One took employees through a social engineering scenario. Another turned a password challenge into a character reveal.

The 90s television theme gave the campaign a personality. Leaderboard points and prize drawings added curiosity and friendly competition.

This is the approach Bianca Baumann and I advocate in Think Like a Marketer, Train Like an L&D Pro: don’t assume good learning will attract attention on its own.

Marketers create several ways for people to encounter a product. We wanted to create several ways for employees to encounter cybersecurity.

The annual course delivered the required learning. The games helped the larger campaign earn attention.

But every game raised the same tracking question.

What Did We Actually Need to Know?

As instructional designers, we’re good at building systems.

Sometimes a little too good.

A simple tracking request can quickly grow into conversations about LMS settings, SCORM packages, dashboards, data models, automation, and reporting rules.

Before building any of that, we stopped and asked:

What problem are we actually trying to solve?

We needed to know three things:

• Who completed each game?
• Who earned leaderboard points?
• Who qualified for prize drawings?

We weren’t issuing certificates. The games weren’t part of anyone’s compliance record. We didn’t need detailed data about every click or choice.

We just needed to connect a completed game to an employee.

One Form. One Question.

Each game ended with a completion result. Depending on the activity, that might be a generated code, secret phrase, puzzle answer, or character name.

Employees clicked a link and entered that result in a Microsoft Form.

That was the entire process.

Because they were already signed in through Microsoft 365, Forms captured their identity and submission details. We didn’t need to ask for a name, email address, employee ID, department, or business unit.

The form had one question:

What is your completion code?

Why We Didn’t Use the LMS

We could have placed each game in our LMS. That would have provided more formal tracking.

It also would have created more work on both sides.

Employees might have needed to open the LMS, locate the right activity, launch it, move through several screens, and confirm completion.

None of those clicks would have improved the game. They would have created more distance between “That looks fun” and actually playing.

The LMS would have added work for our team too. Each activity would need to be packaged, uploaded, configured, tested, and maintained.

Even a small change could become a project. Fixing one instruction might mean editing the source, publishing the package again, replacing it in the LMS, and testing it one more time.

With Forms, we could update an instruction or code in minutes.

The LMS wasn’t the wrong tool. It was simply more tool than this job required.

Friction Works Both Ways

We often discuss friction as a learner problem. Every field, login, and extra click asks for a little more time and attention.

But learning teams pay for friction too.

They pay through added development, more testing, slower updates, and ongoing maintenance.

That doesn’t mean we should collect no data or avoid robust systems. It means the value of the information should justify the effort required to collect it.

For required compliance training, detailed records matter.

For a voluntary game and prize drawing, a one-question form may be enough.

The tracking method should match the stakes.

Our System Wasn’t Airtight

A submitted code showed that an employee had the code. It didn’t prove, beyond all doubt, that the person completed every part of the game.

Someone could share an answer.

We accepted that risk because these were optional campaign activities, not certifications or legal records. Making participation easy mattered more than building perfect proof.

Different stakes would have led to a different decision.

Simple worked because it was appropriate, not because simple is always better.

We Added Complexity When It Earned Its Place

Later, we connected the Forms data to Power Automate. That helped us manage leaderboard points and other campaign features.

We didn’t reject complexity. We added it when it produced clear value.

That sequence matters.

Start with the smallest system that solves the real problem. Then add new parts when you can explain exactly what they improve.

Otherwise, every new layer becomes something your team has to build, test, maintain, and feed.

The Bottom Line

The games helped our cybersecurity campaign earn attention.

Microsoft Forms lets us track participation without taking that attention away.

That’s the larger lesson. Treat learning like a product that needs to be marketed. Create reasons for people to notice it, explore it, and talk about it.

Then choose support systems that fit the purpose and stakes of the experience.

Nobody talked about our form.

Nobody talked about the automation.

Nobody talked about the reporting.

They talked about the games.

That was the clearest sign that we had spent our time on the right things.