01 — The Brief
I made Harland & Finch up
I wanted to start by giving myself a realistic landscape in which to build my first demo. Cyber-security training for a law firm seemed an obvious choice, as I’ve spent several years designing training for the sector. It’s also a topic where we all experience pain, both as learners and as learning designers. I don’t know anyone who has completed an elearning module on this topic without rolling their eyes and clicking through the materials as quickly as possible, hoping to scrape a pass and get back to their day job. This was especially the case for my fee-earner audience, who barely had the time to learn the time-recording software.
Using a combination of Claude and ChatGPT, I role-played stakeholder meetings and conducted a fictional TNA of my fictional law firm, giving me plausible scope to develop a course against. I used Claude to develop a prompt that bound ChatGPT to behave as an IT manager: busy, frustrated, overly technical. Essentially an SME resentful of having a training project land in his lap. I ran mock interviews and shadowing exercises to produce realistic (i.e. messy) TNA data that Claude helped me group and analyse.
The finding was familiar: employees knew the rudiments of cyber-security and could tick the correct options on a multiple-choice question about phishing. That didn’t make much difference to their day-to-day activities — the current training didn’t affect behaviour. The temptation to go for the quick fix when busy, to defer to hierarchy, or to miss the more subtle cues associated with a cyber attack, was not going to be fixed by a slideshow with a few case studies telling learners how other law firms had screwed up. It required a more immersive approach, one that kept the learner firmly in the work environment and tested their knowledge under pressure.
02 — Analysis
Is this actually a training problem?
Naturally, the TNA identified some training gaps:
“I don’t really leave training knowing what’s most likely to go wrong in my day job.”
Trainee Solicitor…but I still needed to analyse the results to figure out what could reasonably be called a training need, and what needed addressing by ‘Harland & Finch’:
“We’ve got guidance, but finding the right piece at the right moment is half the battle.”
HR AdministratorThere were a number of issues that training alone wouldn’t address, things like policy clarity, ease of reporting and good old hierarchical pressure. Some could be used to inform a more effective learning experience such as hierarchy, or the temptations of an easy workaround (logging into a colleague’s computer used to be a #1 sin at a previous firm). I was interested in how meaningful learning could reflect this environment, whilst still addressing the learning outcomes the TNA had highlighted.
It’s also fair to say that these pressures (and the mistakes they engender) vary across roles. Fee-earners experience hierarchy in a way distinct from secretaries and, generally, secretaries experience higher levels of interruption and task-switching. Employees across the board are tempted by a range of easy workarounds. My other challenge was how to acknowledge these differences without having the learner check out of content they didn’t see as relevant to their role.
I identified nine learning outcomes from the TNA, which you can view below. Or you can move on to the design section to find out what I did with them.
Nine learning outcomes, drawn from the TNA. Not all are covered in the current demo — a completed course would address the full set.
| LO | Outcome |
|---|---|
| LO1 | Analyse messages for indicators of phishing and determine the appropriate verification or reporting action before responding. |
| LO2 | Recognise the need to report suspicious messages and near-misses promptly, and follow the firm’s reporting procedure before attempting to resolve the issue. |
| LO3 | Apply a deliberate recipient-checking process to verify the email is addressed to the correct person before sending. |
| LO4 | Check attachments to confirm they are correct, necessary, and relevant before sending. |
| LO5 | Evaluate the risk of alternatives to secure sending methods and choose the approved channel for sensitive information. |
| LO6 | Assess the sensitivity of outgoing information and apply the appropriate level of protection before sending. |
| LO7 | Verify the identity of callers and the legitimacy of requests before acting on verbal instructions. |
| LO8 | Follow the firm’s clean desk and device policy when leaving a workstation unattended. |
| LO9 | Follow the correct escalation procedure when unable to complete a task safely or without appropriate authority. |
03 — Where the Thinking Happened
Decisions worth understanding
H&F had requested a refresh of their existing elearning, but it was clear from the TNA that another click-through exercise wouldn’t cut it. The learning objectives supported this logic as they sit higher on Bloom’s taxonomy than ‘remember’ and ‘understand’.
This was a clear call to develop scenario-based learning that began with a task, rather than explainer slides followed by a multiple-choice assessment. The scenarios had to test judgement, simulate workplace stressors, and acknowledge the sector-specific situations faced by different roles within a law firm.
Below are some examples of key decisions I made before and during the build. These aren’t the only decisions I made, but they’re the ones that most directly shaped what the experience became. Caveat: these refer specifically to the secretary scenario as the fee-earner and receptionist scenarios are still in development.
Mimic a busy desktop and allow the learner to interact with it freely, without penalising the learner for time taken. The Diane demo sketches the final half hour in the day of a busy employee anxious to leave for their holiday. The task list, the dynamic inbox, the clock slowly creeping towards home-time — these are all design choices I made that acknowledge the real-world environment without treating a slow response as failure.
While the whole course will (eventually) cover all nine learning objectives, the principle of three separate vignettes was to break them down by those that affected a particular audience most. It also gives the learner, whichever role they’re in, the opportunity to view certain challenging tasks through a different lens, and prompts them to consider how their behaviour could trip up a colleague.
We rarely get real-time, perfectly tailored prompts in daily life, but a lot of training interventions are peppered with them. Learners know to look for the ‘right answer’ in a multiple-choice assessment — so what do we really learn when they score 9/10 on a phishing quiz? These interactions are designed to assume some basic knowledge, and allow the learner to demonstrate they have it without an interface telling them what to click next. They learn what they got right and where they fell down at the end of each task.
Most learners switch off early on in elearning, as it tends to start with the basics and only occasionally surprises them with new information buried somewhere in the middle of the course. Personally, I am more motivated to understand something when I find out I got it wrong — there’s no reward in proving your knowledge when it’s already been laboured over in several slides. Where a lot of elearning fails is that it starts with an assumption of unconscious incompetence (you don’t know that you don’t know), whereas this approach allows the learner to match what they think they know against what they actually do. When the scenario exposes a gap the learner didn’t know they had, targeted remediation is offered at that moment (although I have yet to build it).
04 — Working with AI
What collaboration actually looked like
Claude was my thinking partner throughout this project, not a content generator — although it did write most/all of the code. I used it to pressure-test ideas and work through scenario logic, not to mention conduct a whole lot of QA testing. The exchanges below are drawn from real conversations during design and development.
The incident report frame
Claude was offering standard narrative frames for the anthology, none of which gave the learner any stake in the outcome. I wanted the frame to connect the three vignettes in a way that made the learner feel involved in and, ideally, responsible for what happened. They should finish with a sense that they either helped the firm avoid some serious cyber-sec risks, or that they let Diane and her colleagues down when they needed better support.
Pressure mechanics
Replicating the pressure of a working day without creating accessibility barriers was one of the harder design problems. Claude started with the obvious answer.
Two bugs, one rule
Late in Task 1 QA, two separate bugs surfaced. In one, a specific forward-then-forward sequence wrongly blocked the learner from completing. In another, a report-after-forward path left the Complete button disabled. Different triggers, different end-states — on the face of it, two problems. I needed to walk the two paths with a critical eye on what the learner might do that Claude would have overlooked as unlikely behaviour.
05 — The Build
Learning to direct a development team of one
In the ~2 weeks I’ve been working with Claude, I’ve gone from someone who used AI to create great recipes and fix the dishwasher, to someone who knows how to push to github, understands the rudiments of how code is structured, and, most importantly, where to let AI do the heavy lifting and where to wrest back control. It’s been an interesting journey.
A couple of aspects of building with Claude rather than authoring through Articulate stood out:
Creative freedom. I’m not a coder, I would even find writing JavaScript in Articulate 360 hard to get my head around. There was only so much I felt I could do with traditional authoring tools given this limitation. I still have to figure out how far my demo can go in terms of accessibility and LMS compatibility, but providing these work I believe I can only develop more interesting courses using AI as my development team.
Taking on a pseudo-management role. At the outset I was worried about where I would still retain control of the design and logic of anything produced by AI, but I’ve learned that those guardrails are often easy to construct with a bit of practise. Now I feel like I’m sat next to the most patient developer in the world, and gradually getting better at telling it what I want.
Learning to spot when Claude’s about to give out. We both got very confused when conversations ran on too long and the context window became too full. When I moved from chat to cowork and realised that a project retained cross-conversation memory, my blood pressure returned to normal levels almost immediately.
Having the freedom to build whatever I liked was daunting at first — when I first started in ID the temptation was to just design whatever looked coolest. But I like to think I kept my head and, without having to worry too much about the code behind the build, I was able to give my attention to proper ID considerations. Is there too much cognitive load here? Are we making it too obvious for the learner there? With each iteration I was able to properly step into the learner’s shoes and identify pain points or learning loopholes (in an early version of Task 1 the learner could hit ‘report suspicious email’ and skip straight to feedback — now they have to explain their reasoning).
The result is that I have an app that performs way beyond anything I could build myself, but still functions as meaningful learning because I’ve been able to apply my experience in the field.
06 — Quality Assurance
Every learner path, mapped and walked
I’ve done plenty of arduous UAT ahead of a dreaded deployment. This time I found it (mostly) fun.
The complexity of the build meant that there were numerous paths (some sensible, some convoluted) that a learner could follow. Claude and I created a QA matrix so that these were easier to map, and that was invaluable for surfacing design gaps — spotting branching logic that didn’t make sense, redrafting feedback copy that was too vague.
I made sure to walk all of the possible learner paths, even the ones Claude missed, and check what the learner does, what the system should do in response and what the feedback should say. I was also able to zone in on things that could improve the learner experience, such as making the scoring system logic more transparent, or showing the learner’s suspicious-email checklist alongside the email itself.
In the real world I’m sure many more fixes would surface during UAT (let me know if you found any), and I’ve had to constrain myself as to how far I can reasonably go with a demo portfolio piece, but if anyone wants to see my bug-fix logs they only have to ask.
07 — Reflection
What I’ve learned while building this demo
A portfolio that hides its gaps is a worse demonstration of professional judgement than one that names them. So: here’s what’s not finished, and here’s what I learned.
There is still plenty to do, for example the addition of tailored learning at the end of the vignette, and addressing the accessibility issues I’ve logged. And I still have two more personas (my fee-earner and receptionist) to develop.
For my next project, I will remember to:
Create a QA matrix early on. Trying to map this all out half-way during the build was painful, to say the least, and I went through several iterations before I found the right solution.
Return regularly to the brief. I am mildly concerned that, in the excitement of the build, I’ve drifted away from some of the outcomes I’d been aiming for at the outset. I think this is a common ID trap so I won’t beat myself up about it, but it’s important to remember why you’re building something. I should probably go back to my stressed out SME and ask him for his opinion.
The design decisions in what’s here are mine — the TNA reading, the scenario logic, the feedback wording. Claude patiently built it with me, it didn’t build it for me.