THE CRAFT
The craft
Learning I have designed and built, shown with the decisions behind it. Most portfolios show the finished thing. The finished thing is the easy part. What is worth seeing is the analysis that came before it and the argument that produced its shape.
Some client work is shown in extract or as a single screen. Some is not shown at all.
01 · ANALYSIS INTO DESIGN
The brief, and what was underneath it
The problem. The brief asked for a longer induction. The analysis found eight pressures underneath it: thirty per cent attrition, first contact resolution under eighty, quality below target, a training team under-qualified on its own survey, content dense and misaligned to the work, scarce labour mid-pandemic, delivery split with an external contract, and the core technology changing mid-flight. Any one of those is a training problem. Together they are a system under strain.
The decision. Argue against the brief. A longer course would have produced more of the wrong thing and worsened the attrition it was meant to fix. So analyse the work first: 194 distinct enquiry types, drawn from call volume, quality monitoring and team leader input, mapped into a skills-routing model and a competency progression.
What it became. Nine weeks rather than ten days, four weeks of common entry capability then five specialised, with checkpoints through rather than an assessment at the end, and the delivery team's own capability built deliberately because a program that only works when I am in the room is not a program.
02 · STORYBOARD INTO FINISHED PIECE
Architecture, then artefact, then build
The problem. A payroll system release arrives as a module list. Somebody hands you seven functional domains and asks for training on each, which produces seven courses nobody finishes and a helpdesk queue that does not move.
The decision. Design the system of assets before designing any asset. Map every functional domain against five asset types, tag each by format and delivery mode, then decide what each domain actually needs rather than giving all of them the same treatment. Name every artefact in the user's language, not the system's: finding your payslip, not Pay Summaries module.
What it became. An architecture, then a self-help guide built from it, then eLearning built from that. Three stages, each traceable to the one before, which is the part most portfolios cannot show because the decision was made once and the rest was production.
03 · eLEARNING
Built, not commissioned
The problem. [The capability gap, and the constraint: time, literacy spread, dispersed workforce, regulated content.] The decision. [Why this interaction rather than a page of text. What you designed for accessibility from the start rather than retrofitted.] What it became. Built in Articulate Storyline and Rise, to WCAG 2.1 AA, deployed through the LMS.
04 · VIDEO AND ANIMATION
Naming the moves as they happen
The problem. Planners had to introduce the roster of care, the schedule of a person's daily supports, to people who had never heard of it. The usual response is a communication module. But nobody learns to run a conversation by reading about conversations, and telling someone afterwards that they were not empathetic enough is too late to be useful.
The decision. Do not script it. I gave two planners the things that had to be conveyed and let them find the words live, then annotated the moves beside the recording as they were used. Question types surface first, leading, closed, probing. Relational moves accumulate beneath: empathy, active listening, respectful, empowered, explain. The learner watches technique become visible in real time rather than being told about it afterwards.
What it became. Ninety-one seconds, short enough to watch between one task and the next. The turn that carries it was not planned: the participant says she does not know what a roster of care is, and the planner explains it without making her feel foolish for asking. You cannot script that, which is exactly why it was worth recording.
05 · FACILITATION, SHOWN AS DESIGN
Teaching people how to talk to each other
The problem. Finance business partners were trusted with numbers and not with judgement. The gap was not technical knowledge, it was the conversation: they answered the question they were asked rather than the one underneath it, and so stayed transactional.
The decision. Treat the conversation as the thing being designed. Give people the moves rather than the mindset, named and scripted, with question stems they can use in the meeting they are walking into. Start. Tell me more. Challenge. Clarify. Summarise. Build. These are talk moves out of dialogic teaching, and there is no reason they should stay in classrooms.
What it became. A fourteen-page coaching toolkit: conversation tactics with stems, five strengths-based strategies with starter questions, and personal strategies organised around being adaptable and being curious. Facilitation designed as an artefact somebody can pick up and use, not a workshop that only works when I am in the room.
06 · ASSESSMENT AND COMPETENCY
Making a framework operate
The problem. Several contributors were building learning across an enterprise systems program, most of them not learning designers. The APS Learning Quality Framework already set the definition of quality: purposeful, user-centric, adaptable, impactful. What it did not do, and what no framework does, is make anyone design to it. Review stayed opinion and rework stayed constant.
The decision. Build the mechanism underneath the standard rather than write another standard. A written reviewer protocol so review was a procedure instead of a preference, a six-dimension rating instrument covering impressions, navigation, multimedia, accessibility, technical performance and overall judgement, and testing applied while the courseware was being made rather than at sign-off, when the only options left are ship it or start again.
What it became. Quality that held across contributors who did not design for a living. The framework was the Commission's. The machinery that made it operate on the program was mine, and that is the harder half.
07 · INTERACTIVE TOOLS
Things that run, not things that describe
Link the four existing tools: Learning System Quick Scan · Learning Design Map · Cultural Safety Evidence Landscape · The Language Problem
Four working tools, built and hosted here. Each one takes something that normally arrives as a report and turns it into something you use: answer a set of questions, get a result shaped to your situation.
Learning System Quick Scan. Where a learning system is strong and where it is thin, across the full cycle.
Learning Design Map. What a piece of learning is actually being asked to do, before anyone opens an authoring tool.
Cultural Safety Evidence Landscape. What counts as evidence in a domain where the recipient, not the provider, decides.
The Language Problem. What our words are doing when we think they are neutral.
Built in React against the Claude API, with a graceful fallback when the model is unavailable, because a tool that fails closed is not a tool.
ON WHAT IS SHOWN
Client work is shown in extract, as a single screen, or redrawn with organisation-specific detail removed. Some material is not shown at all, because it remains under review, carries a protective marking, or belongs to the people who commissioned it.
That is not a disclaimer. Knowing which category a piece of work falls into is part of the job.