Analyze
The performance problem
The goal was to get staff to turn on 2FA for their district Google accounts. The task itself is seven steps. But the module spends a whole section on something else first: is it safe to use my own phone for this?
That tells me what I was designing against. The barrier is not only "how." It is worry. The module answers a worry before it teaches a click.
I am reading this analysis back out of the finished module (built in February 2026). Each row below is something the design visibly responds to.
| Barrier I designed against | Where the module answers it |
|---|---|
| "What even is MFA?" | Section 2: plain-language definitions and a deadbolt analogy |
| "Will the district see my photos and texts?" | Section 3: a can/cannot-see table and a three-question FAQ |
| "I'm signed in to two accounts and I'm not sure which one this changes." | Section 4: Steps 1 and 2 each name this pitfall |
| "Which method do I pick?" | Section 5: a Best / Better / Good hierarchy |
| "What if I lose or replace my phone?" | Section 5: backup guidance and a new-phone callout |
Learner profile
- Adult district employees: teachers, office staff, administrators.
- Mixed comfort with security settings. The module defines MFA from scratch.
- Often signed in to a personal Google account in the same browser. Two steps warn about it.
- On different devices. The materials list says "computer, Chromebook, tablet, or phone."
- Busy. The module promises 10 to 15 minutes and keeps to it.
Constraints
- Self-paced. No facilitator in the room.
- No LMS required. Three plain files and a link. No libraries, no login, nothing to install.
- Any device. The layout reflows at three widths, down to a phone.
- Printable. The one-page quick guide prints on its own, with the rest of the page hidden.
Design
Five objectives, mapped
These are the objectives as written in the module. I built the matrix below by reading each quiz item and asking which objective it actually tests.
| # | Objective (verbatim) | Taught in | Assessed by | Coverage |
|---|---|---|---|---|
| 1 | Define multi-factor authentication (MFA) and two-factor authentication (2FA) in plain language. | Section 2 | Q1 (multiple choice) | Direct Recognition, not recall. |
| 2 | Explain why 2FA matters for district email, files, payroll/HR access, and staff communication. | Section 2 ("Why It Matters in Schools"), Section 7 | None | Gap No item asks why. |
| 3 | Enable 2FA for a district Google account using Google account security settings. | Section 4 (seven steps) | Q3 (scenario) | Partial Tests one step of seven. A quiz cannot watch someone do it. |
| 4 | Choose a 2FA method that fits your daily work and comfort level. | Sections 3 and 5 | Q4 (multiple choice) | Partial Tests which is strongest, not which fits you. |
| 5 | Use backup options if a phone is lost, replaced, or unavailable. | Section 5 (backup guidance, new-phone callout) | Q5 (true/false), Q6 (scenario) | Direct The strongest alignment. |
| – | No objective states this. | Section 3 (personal-device reassurance) | Q2 (true/false) | Unstated An item with no objective. |
Two things stand out.
- Objective 2 has no quiz item. Learners are told why 2FA matters but never asked. I would add one.
- The reassurance section has no objective. It addresses the biggest barrier and has a quiz item, but none of the five objectives names it. It is an attitude goal I designed for and never wrote down. I would add one: State what the district can and cannot see when you use a personal phone.
Sequence
- Concept (Section 2). Give the learner a mental model before any clicking.
- Reassurance (Section 3). Remove the worry that would stop them at Step 1.
- Procedure (Section 4). Seven steps, one action each.
- Choice (Section 5). Compare methods and set up backups.
- Check (Section 6). Six items, scored on the spot.
- Job aid (Sections 7 and 8). A summary, a help script and a one-page guide to keep.
The order is not perfect. Step 6 asks the learner to pick a method, but the guidance for picking one is in Section 5, after the steps. I list the fix below.
Design device: Best / Better / Good
A menu of four methods invites a stall. A ranked list turns it into a recommendation. It also respects comfort: a person who would rather not use a phone sees at once that the top choice is a physical key.
- BestSecurity key. Strongest sign-in protection.
- BetterAuthenticator app or Google Prompt. Strong and convenient for daily use.
- GoodSMS/voice (if available). Better than password-only, but usually less secure than key or app methods.
Design device: the can/cannot-see table
Section 3 is a two-column comparison. Putting the two lists side by side lets a nervous reader see the boundary, not just be told it exists.
- Whether 2FA is enabled on your district account
- Successful or failed district account sign-in attempts
- That a prompt, code, or security key was used
- Your personal photos
- Your text messages
- Your personal apps and app content
Develop
One analogy, used three times
The module explains 2FA once, with one image, and then reuses it in the wrap-up and the talk track.
"2FA is like adding a separate deadbolt to your house with a separate key."
Followed by: your password is the regular lock; if someone gets it, they still cannot get in without the second key.
Every step has a pitfall and a visual cue
Each of the seven steps carries three parts: the action, a common pitfall (how people go wrong) and a visual cue (what the screen should look like when they get it right). The pitfalls are the predictable failures. The cues let a learner self-check without asking anyone. Two examples:
Click your account
Click your profile icon in the top-right corner to confirm which account is active.
Common pitfall: Multiple accounts are signed in and the wrong one is selected.
Visual cue: A small account panel opens with account names and email addresses.
Select your option
Choose your preferred method (Google Prompt, authenticator app, SMS/voice if offered, or security key).
Common pitfall: Choosing a method tied to a device you do not always have with you.
Visual cue: Google shows method choices and setup instructions for each.
Choices I can point to in the build
- Plain language. MFA is "proving it is you in more than one way." The three factor types are "something you know, have, or are."
- Chunking. Eight sections, one idea each, with a side menu and a "sections viewed" meter.
- Disclosure, not a wall of text. The FAQ and the answer key sit inside expandable panels.
- Keyboard and focus. Real buttons and links, native radio buttons, and visible focus styles on the menu.
- Responsive. Layout changes at three widths. The wide table scrolls inside its own box.
- Print. A print mode hides everything except the quick guide.
- No dependencies. Vanilla HTML, CSS and JavaScript.
Implement
The module is built to be handed out in three ways.
- A link. It opens in any browser, with no login. Open the module and try it.
- A printed page. Section 8 is a one-page quick guide with a checklist and privacy quick facts. Its Print button prints only that page. Go to the job aid.
- A 60-second talk track. A short script a coach or leader can say aloud or paste into an email to introduce the training.
"Please turn on 2FA for your district Google account today. It adds a second sign-in check, like a separate deadbolt key for your account."
The script goes on to repeat the privacy reassurance and to point staff to the help desk for other methods. In this public demo the help-desk contact reads "your district IT help desk."
Evaluate
The knowledge check I built
Six auto-graded items: two multiple choice, two scenarios, two true/false. Each has an explanation in an answer key. Two examples, with their explanations as written:
If I use my personal phone for district Google 2FA, IT can read my personal texts.
- True
- False
"Account security checks do not provide IT access to personal texts."
You got a new phone and cannot receive old authenticator codes. Best next step?
- Wait and try tomorrow
- Use backup method/codes, then update 2FA settings
- Create a brand-new district account
- Share your password with a coworker
"Use a backup method, then update your 2FA setup on the new phone."
The wrong answers in Item 6 are not random. They are the things a stressed person might really do. That is what makes a scenario item useful.
Tiered feedback
| Score | Message the learner sees |
|---|---|
| 6 of 6 | "Great work - you are ready to enable 2FA." |
| 4 or 5 | "Nice progress - review the answer key for the missed items." |
| 0 to 3 | "Review sections 2-5, then try again." |
The remediation is targeted, but only by block. It sends a low scorer back to Sections 2 to 5, not to the section behind each missed item. Item-level routing would be better.
Kirkpatrick evaluation plan
| Level | Question | How I'd measure it | Status |
|---|---|---|---|
| L1 Reaction | Did staff find it clear and worth the time? | A 2-question pulse at the end of the module | Planned |
| L2 Learning | Can they do what the objectives say? | Score distribution on the knowledge check, and which items are missed most | Planned |
| L3 Behavior | Did they actually turn on 2FA? | Percent of staff accounts with 2FA enabled, from the admin console, at 30 days | Planned |
| L4 Results | Did it make accounts safer and support easier? | Fewer account-compromise and lockout tickets | Planned |
What I'd do differently
- Record the quiz results. Right now the score appears on screen and is never stored, so Level 2 cannot be measured. This is the first fix.
- Add an item for objective 2 (why 2FA matters), and write an objective for the reassurance section.
- Add a branching scenario for the lost-phone case. A "what do you do first?" path would test objective 5 as a decision, not a fact.
- Move method guidance ahead of Step 6, or link to Section 5 from that step.
- Route low scorers by item, not to a block of four sections.
- Test the click-path against Google's current screens. The steps name specific menus. They will drift, and I'd re-check them on a schedule.
- Make the "sections viewed" meter honest. It counts scrolling past a section, not understanding it.
What this shows for instructional design roles
- Starting from a performance problem and a learner's barriers, not from a topic
- Writing measurable objectives and checking them against the assessment, gaps included
- Building job aids and scenario-based items, not just slides
- Planning evaluation at all four Kirkpatrick levels, and saying plainly what has not been measured yet