AI Is Making Your Training Look Like Everyone Else's. That's a Problem.

Last week I posted on Substack (Trident eLearning Weekly Grumble) about something I had been noticing on LinkedIn. Designer after designer was sharing screenshots of what they had built using Claude Design — and they were all excited about it. Faster development. Cleaner layouts. Professional-looking output in a fraction of the time.

There was just one problem. They all looked identical. Different organizations. Different industries. Different audiences. Different learning objectives. Same course. Dark navy background, three cards evenly distributed across the center of the screen, burnt orange accent text, the same clean sans-serif font. If you scrolled through the posts without reading the captions, you would have had no idea which designer built which course, which company commissioned it, or what the learner was supposed to walk away knowing.

That is the AI design problem nobody is talking about.

Faster Isn't Better If Faster Gets You to the Same Place as Everyone Else

Let me be clear about something before this turns into an anti-AI argument: it isn't one. AI is genuinely useful in the development process. It can build templates, generate layouts, suggest color palettes, and cut production time significantly. Used well, it is a powerful tool that lets designers spend more time on the things that actually require human judgment — the analysis, the strategy, the decisions about what learners actually need.

The problem isn't the tool. The problem is what happens when designers let the tool make the decisions that should be theirs to make.

When you hand AI your design choices, you don't just save time. You also skip the process that builds your eye. You skip the iteration. You skip the moment where you look at something and decide it isn't quite right — and then figure out why, and fix it. You skip the development of taste, instinct, and the ability to look at a design and know, without being able to fully articulate it, whether it's working.

Those are not skills you can outsource. And if you never develop them, you will always be dependent on whatever the tool produces — because you won't have the foundation to evaluate it, improve it, or know when it's wrong.

Developing Your Own Style Is Part of the Job

One of the pillars of good instructional design is developing your own style — a design voice that is recognizable, intentional, and specific to the work you produce. That doesn't mean ignoring trends or refusing to use tools. It means knowing why you're making the choices you're making, and being able to defend those choices on the basis of learning design principles, audience needs, and brand context — not because it was the default.

Your style is what makes your work identifiable. It's what makes a client trust you with their brand. It's what makes a learner feel like a human being made this, not a machine running a prompt.

AI can give you a starting point. It cannot give you a voice. That part is yours to develop — through practice, through iteration, through the slow and sometimes frustrating process of building something, deciding it isn't right, and building it again.

If you hand that process to a tool, you will produce training faster. You will also produce training that looks exactly like the training the person across LinkedIn produced this morning, using the same tool, with the same defaults, for a completely different audience and purpose.

What the Learner Experiences

Here's the part of this conversation that gets dropped most often: the learner.

The purpose of an instructional designer is to create a welcoming environment that engages the learner and stimulates as many senses as possible. That is the job. Not to produce a course. Not to hit a deadline. To create an experience that reaches the person taking the training, so he or she absorbs the material.

When everything looks the same, you are not stimulating the eyes. The learner has seen this before — the same dark palette, the same card layout, the same visual rhythm — and their brain registers it as familiar background noise rather than something worth paying attention to. When the narration uses the same cadence, the same phrasing, the same AI-generated voice patterns as every other course they've completed this quarter, you are not stimulating the ears. And when the layout requires nothing more than mindless mouse clicks to advance through screens that look identical to the ones before them, you have not created a learning experience. You have created a compliance checkbox.

That recognition happens fast. A learner who feels like an afterthought will behave like one — clicking through, half-present, retaining little, and returning to the work that was waiting for them before the course launched.

The Question Worth Asking

Before you accept the first layout AI gives you, ask yourself one question: would a learner who has taken ten courses built this way feel anything when they open mine?

If the answer is no — if your course is indistinguishable from the assembly line — you haven't finished designing it. You've just generated a starting point.

Use the tool. Don't let the tool use you.

Training Shouldn't Start With the Course…

Special Contribution by Reena Baumann, Co-Founder of Learning Elements and ILP Asia Pacific Fellow

When we first started designing training programs years ago, the requests were often fairly straightforward.

"We need a course on this."
"We've launched a new product and people need to understand the benefits."
"We have a new system. Can you train everyone?"

So we designed the training.

That was also indicative of how training was often viewed: as a transactional service. A need was identified. Training was requested. A course was developed and delivered. Job done. Except, over the years, we learned that the job wasn't done at all. A one-off training intervention rarely creates sustained behaviour change on its own. People naturally forget information. They return to busy workplaces, old habits and competing priorities. So our approach at Learning Elements has changed considerably.

We start before the training

Our Training Needs Analysis can become quite detailed depending on the scope of the work. Before developing anything, we want to understand:

• What problem are we actually trying to solve?

• How does this training fit into the broader program or business objective?

• What does the role require?

• What decisions do people need to make?

• What do they need to do differently?

• What are they doing now?

• What evidence tells us there is a gap?

• What could prevent the new behaviour from being adopted?

• What resources and support will be available afterwards?

• How is performance already being measured?

• Who needs to be involved?

• What already exists?

• And importantly: why is training needed?

Sometimes the answers change the original training approach, which is a good outcome.

Then we think beyond the training room

Learning needs reinforcement. That might mean reviewing important information within 24 hours, revisiting concepts through spaced repetition, creating opportunities to practise, or managers testing and reinforcing knowledge during meetings, coaching and team stand-ups. And then we look at what happens on the job. Training data can tell us part of the story. Operational and performance data can tell us another part. Bringing them together can help identify where a program needs improvement and where an individual may need additional support. That's a very different approach from simply asking:

"Did everyone complete the training?"

Training isn't the outcome

The outcome might be fewer errors, improved customer experiences, reduced risk, faster competency, or a sustained change in behaviour. Whatever the outcome is, we need to understand it before we start designing the training. Training should never exist simply to tick a box. It should address a genuine gap, be designed with the people who influence the outcome, and create evidence that helps us understand what happens next. That's the shift from delivering training to developing.

—————-

Reena Baumann, co-founder of Learning Elements and Fellow member of ILP Asia Pacific has worked in learning and development for over 25 years, building deep expertise in how organisations develop capability and drive performance.

Her experience is grounded in coaching, training design, facilitation, establishing and leading teams in the Asia Pacific region. Over time, her work has evolved into leading strategic program development, implementation, and the use of data and analytics to understand and improve outcomes.

Known for her ability to simplify complexity and take a practical, considered approach, Reena works closely with clients to turn ideas and challenges into structured, effective programs that deliver real results.

Connect with Reena onLinkedin subscribe to her Substack and visit the website to learn about how Learning Elements can work with you.

The Most Expensive Phase Nobody Wants to Pay For

A manager contacts you with a request. His team is underperforming. Errors are up, productivity is down, and morale is suffering. He's watched it get worse over the past several months and he's reached a conclusion: his staff doesn't know how to do their jobs. He wants a continuing training program — something ongoing, something structured, something that will fix the problem.

Before agreeing to build anything, you do what you're supposed to do. You conduct an analysis.

You interview new staff members. You talk to experienced employees who have been doing the job for years. You sit down with the managers and supervisors who oversee the work every day. And across every group, the same answer keeps surfacing — not "we don't know how to do our jobs," but something entirely different: we don't have any personal time. We never have space to breathe, to reflect, to work on the things we know we need to improve. We are always rushed. We are always overworked.

And when you dig into the performance data, the picture becomes even clearer. The employees know their jobs. They know the processes, the expectations, and the standards. They are not performing poorly because of a knowledge gap or a skill deficit. They are performing poorly because there aren't enough of them to do the work.

The solution isn't a continuing training program. It's more staff.

As it turns out, the manager was already looking at a separate question — whether he needed to double his workforce. The analysis didn't just redirect the training request. It answered a business question he had been sitting on for months and gave him the data he needed to make the case for the hire.

That is what a proper needs analysis does. And it is the phase that almost nobody wants to pay for.

The Assumption That Breaks Everything

The single most common failure in instructional design isn't bad course design. It isn't poor narration or weak interactions or a Level 1 survey that asks the wrong questions. It is the assumption — made before a single question is asked — that the problem is a training problem.

This assumption is so deeply embedded in how organizations think about performance that it functions almost like a reflex. Something goes wrong. Someone underperforms. A process breaks down. And the immediate response, at every level of the organization, is: we need training.

It feels logical. Training is how you fix people who don't know things. If performance is the problem, knowledge must be the gap. Build the course, close the gap, fix the problem.

Except most performance problems aren't knowledge problems. They're system problems. Resource problems. Process problems. Management problems. Communication problems. Motivation problems. Environmental problems. And a training course — no matter how well designed — cannot fix a staffing shortage, a broken workflow, a tool that doesn't work, or a culture that doesn't support the behavior the organization says it wants.

The analysis phase exists to figure out which kind of problem you actually have before you commit time, money, and organizational attention to building a solution that may not address it.

What Analysis Actually Looks Like

A proper needs analysis isn't a formality. It isn't a checkbox before the real work begins. It is the real work — or at least the beginning of it.

It means talking to the people doing the job, not just the manager who commissioned the training. It means talking to new employees and experienced ones, because they experience the same environment differently and their answers will reveal things neither group could tell you alone. It means talking to supervisors and managers, who see patterns across the team that individuals can't. It means asking questions that don't assume training is the answer — questions about workload, about tools, about processes, about what people would need to perform better if a course were taken off the table entirely.

It means being willing to bring back an answer the customer didn't expect and didn't ask for. In the example above, that meant telling a manager that his staff didn't need more training — they needed more colleagues. That is not a comfortable conversation. It is also the only honest one.

Why It Gets Skipped

The analysis phase gets skipped for two reasons, and both of them are understandable even if neither of them is acceptable.

The first is stakeholder pressure. A manager who has already decided the problem is a training problem does not want to spend time and money on a process designed to question that conclusion. They want the course. They want it soon. And an L&D professional who pushes back on that request — who says "before we build anything, I need to understand what's actually causing the problem" — is going to face resistance. Every time.

The second is that analysis produces a document, not a deliverable. There is no course to click through at the end. No completion certificate. No polished module to show the executive team. There is a report, a recommendation, and sometimes the unwelcome news that training isn't the answer. That is a hard sell in organizations that measure L&D success by the number of courses produced and the hours of training completed.

But consider the alternative. A continuing training program designed to address a knowledge gap that doesn't exist. Weeks of development time. Hours of employee time. Budget spent. And at the end of it, the same staffing shortage, the same overworked team, the same declining performance — plus a completed course that demonstrably did nothing, because it was solving the wrong problem.

The analysis phase is not overhead. It is the thing that keeps you from building the wrong solution at full cost.

The Question Worth Asking Before Anything Else

Before the next training request turns into a course outline, ask one question: how do we know this is a training problem?

Not rhetorically. Ask it directly, with the expectation of a real answer supported by real evidence. If the answer is "because people are making mistakes," follow up. Are they making mistakes because they don't know what to do, or because the system makes it difficult to do what they know? If the answer is "because performance is down," push further. Is performance down because of a skill deficit, or because the team is understaffed, undertooled, or working in an environment that doesn't support the behavior the organization wants?

Those are not the same problem. And they do not have the same solution.

The analysis phase is how you find out which one you're actually dealing with. Skip it, and you're not saving time. You're spending it on the wrong thing.

I Wanted to Teach Physics. The Navy and Life Had Other Plans.

I went to the University of Wisconsin to study physics. I wanted to be a high school physics teacher, and I still remember the lecture where we walked through Einstein's proof of E=mc². It was surprisingly simple — but only because we already knew where we were headed. Working backward from a conclusion always looks obvious. Getting there first is the part that's actually hard, and it's a little humbling to sit in a room decades later and realize how much genius it took to arrive somewhere that now takes an hour on a whiteboard.

I couldn't afford my last two years. Finishing the degree meant transferring back to an in-state school in Indiana, and by that point I'd grown too much to go back. A lot of my friends were engineering students heading into the Navy as submarine officers, and they suggested I enlist as a nuke instead. So I did. I went to Basic Training in Orlando on November 16, 1992, as a Machinist Mate.

Nearly two years of A-School and Nuclear Power Training later — Orlando, then Charleston — I finally made it to the fleet. My first boat was the USS Ohio, SSBN 726, Gold crew. As a Machinist Mate, my division of about fifteen people owned every gas and liquid system supporting the reactor, the steam plant, propulsion, and electrical generation. If it moved fluid and kept the boat running, it was ours to maintain and operate.

I also happened to be the guy who kept the division's training records. That detail matters more than it sounds like it should.

One of my supervisors wanted to become an officer, which meant finishing a bachelor's degree. He found a program Southern Illinois University ran on base — sailors could earn a degree in what the program called Workforce Education and Development, teaching them how to develop, deliver, and manage corporate training. In the mid-90s, that was a genuinely new specialization for a four-year degree. He knew I'd wanted to teach high school physics. He also knew something else about me: I didn't dislike kids exactly. I disliked other people's kids. And he'd watched me manage the division's training records well enough to notice I had a talent for it. He suggested I look into the program.

It took me a couple of years to actually go back to school. The degree itself wasn't hard — it just took time, especially once I transferred to my second submarine and started going to sea for extended stretches, rearranging which classes I could take and when. If I'm honest, I wish I'd started years earlier than I did.

One requirement of the SIU program was a corporate internship, and that's where everything actually clicked. I did mine at CEVA Logistics in Jacksonville in 2006, and for the first time in my life I knew exactly what I wanted to be when I grew up: an eLearning instructional designer. eLearning itself was barely past its toddler phase at that point — nobody had settled on what "effective" was even supposed to mean yet. CEVA wanted to stop buying generic off-the-shelf training and start building its own library internally, and they needed people who could move fast. I learned what actually went into building eLearning and running an LMS, and I loved every minute of it. That internship is also where I met Diane Elkins, one of the people who genuinely shaped this industry — a friend of the training manager I was working under, who introduced us.

From there I went to shore duty in San Diego, teaching fellow submariners damage control and quality assurance in a classroom, and finally finished my bachelor's degree. I started a master's in the same field while I was there. That BS and the work toward my MS got me my first civilian job — training coordinator at Rio Tinto's Boron Operations, the world's second-largest boron mine and the original home of 20 Mule Team Borax.

I've held a few other jobs since then. It always came back to instructional design.

I didn't set out to become an instructional designer. I set out to teach physics, ended up maintaining a submarine's reactor plant, got noticed by a supervisor who saw a skill in me I didn't know I had, and only found the thing I actually wanted to do once I was standing in the middle of someone else's training department, watching it get built from scratch. Twenty-something years later, I'm still doing the thing that internship convinced me to chase — just with a lot more scar tissue and a much stronger opinion about needs analysis than I had at twenty-six.

Your Portfolio Shows What You Built. It Should Show How You Think.

A Pretty Portfolio Isn't a Portfolio. It's a Highlight Reel.

Let me start with something uncomfortable: AI can now generate a polished eLearning sample in less time than it takes most designers to write a single learning objective. It can produce Articulate Rise outputs that look professionally designed; it can build Storyline interactions with clean branching logic; it can generate slide decks with consistent color palettes and thoughtful typography; and it can design job aids that are clear, well-organized, and visually appealing.

None of that tells you whether the person who submitted it can actually do the job.

This isn't an argument against AI in instructional design. It's an argument about what a portfolio is supposed to demonstrate — and why the rise of AI-assisted output has made that question harder to answer and more important to ask.

What a Portfolio Is Actually For

A portfolio exists to display a creator's abilities and complement the résumé in the application process. The résumé is designed to quickly convey the applicant's experience and qualifications — where they've worked, what they've done, what credentials they hold. The portfolio is meant to show something the résumé cannot: that person's style, their design sensibility, and the depth of their abilities in practice.

The problem is that "style and abilities" means different things depending on who is doing the evaluating. A hiring manager reviewing an instructional design portfolio isn't just trying to determine whether the candidate has taste. They're trying to determine whether the candidate can diagnose a performance gap, design a solution that addresses it, build something that delivers on that design, and evaluate whether it worked. They're also evaluating whether the candidate's design aesthetic and production capabilities would be a good fit within the existing team and meet the demands of the work that needs to be built.

That is the ADDIE process combined with a practical assessment of fit. And a portfolio that only shows the D — the developed artifact — is hiding four-fifths of the job.

What AI Changes About Portfolio Evaluation

Before AI-assisted design tools became widely accessible, a polished output was at least weak evidence of skill. Producing something that looked professional required some combination of design sense, tool proficiency, and time investment. It wasn't proof of instructional thinking, but it wasn't nothing.

That signal is now nearly worthless. The same tools available to every instructional designer today can write a well-constructed A-B-C-D learning objective from a rough topic description. They can generate a complete Articulate Rise course — modules, interactions, knowledge checks, and all — in a matter of minutes. They can write custom JavaScript for a Storyline branching scenario that would have required a developer or significant self-study not long ago. They can clean up an existing lesson by standardizing fonts throughout, adjusting color combinations to meet WCAG contrast requirements, and reorganizing content structure — all from a single prompt.

None of that requires the person submitting the prompt to understand why the learning objective is structured that way, whether the Rise course addresses an actual performance gap, how the branching scenario connects to a behavioral outcome, or whether the color changes actually make the content more accessible to the learners who need it most.

A candidate with six months of experience and the right tools can produce output that rivals the work of a seasoned designer. The output looks identical whether it came from someone who deeply understands learning design or someone who has learned to write good prompts. This doesn't make AI-assisted portfolios dishonest. It makes them incomplete. And it makes the evaluator's job significantly harder if they're only looking at outputs.

What a Portfolio Should Actually Show

If the output alone no longer tells the story, the portfolio needs to show the work behind the output. Specifically:

The needs analysis. What problem was this designed to solve? Was there a genuine performance gap, or was training the solution someone assumed before the analysis happened? Does the portfolio include a Performance Gap Analysis showing that a training solution was — or was not — the correct response, along with the supporting documentation that led to that conclusion? A portfolio piece that includes this level of documentation tells you immediately whether the candidate understands that training is a solution to a specific type of problem, not a default response to any problem.

The design documentation. A design blueprint, a storyboard, a content outline — something that shows the candidate made intentional decisions before opening their authoring tool. What were the learning objectives? How were they connected to the performance gap? How was the content structured and why? These documents reveal instructional thinking in a way that a finished module cannot.

The evaluation plan. How was effectiveness measured? What did Level 1 look like, and did it go beyond a five-question satisfaction survey? Was there a Level 3 plan — any attempt to measure whether behavior changed after training? A candidate who includes evaluation documentation is demonstrating that they understand training is a means to an end, not the end itself.

The reflection. What would they do differently? What constraints shaped the final product? What did they learn from building it? A short written reflection on a portfolio piece separates a practitioner who thinks critically about their work from one who is simply presenting deliverables.

On My Own Portfolio

I put real effort into making my portfolio visually appealing and engaging — the design decisions were intentional, and I care about the experience someone has when they review my work. And yes, I used AI to help me create the samples. I will always be honest and upfront about that fact. I am incorporating AI into my content creation process, but it is not a crutch. It is a tool — one that allows me to produce work more efficiently without replacing the thinking, the analysis, or the design decisions that make the work effective. What I also made sure to include is the full picture of how I work: from the needs analysis and supporting documentation through the design and development to the evaluation plan. I included those documents not because every portfolio needs to look exactly like mine, but because I wanted anyone reviewing my work to see that I understand the entire process, not just the part that renders in a browser.

What Hiring Managers Should Be Asking

If you're evaluating instructional design portfolios right now, the question to ask isn't "does this look good?" It's "can I see how this person thinks?"

Ask candidates to walk you through a portfolio piece from analysis to evaluation. Ask what the performance gap was and how they confirmed it. Ask what they would change if they built it again. Ask what the evaluation data showed — or, if there wasn't any, ask why not.

The answers to those questions will tell you more about a candidate's actual capabilities than any number of polished Storyline modules. And in an environment where AI can generate the module in twenty minutes, those are the only questions that still reliably separate the practitioners from the prompt engineers.

You Don't Need a Training. You Need a Job Aid.

A manager contacts you with a request. Their team is selecting the wrong option from a dropdown menu in an online form — consistently enough that it's become a real problem. The two options sound similar. But one routes the form down one path, triggering one set of outcomes, while the other routes it down a completely different path. Selecting the wrong one doesn't just fail to solve the customer's need. It creates downstream chaos: internal rework, misdirected follow-up, and a customer experience that erodes trust in the organization.

The manager wants a training course.

You ask the right questions. Does the team understand the process? Yes. Do they know what the form is for? Yes. Have they been trained on the system before? Yes. Do they know the difference between the two scenarios the dropdown is meant to distinguish? Most of them do. They just can't remember, in the moment, which label maps to which scenario. The options are named in a way that feels interchangeable until you know exactly what each one triggers.

There is no skill gap here. There is no knowledge gap worth building a course around. There is a decision point in a workflow where people need clarity at the exact moment they need to make a choice — and nothing is giving it to them.

What this organization needs is not a training course. It needs a job aid.

Here's the Thing — People Already Know This

Think about the last time something broke around your house. A leaky faucet. A tripped breaker. A door that stopped latching. Did you enroll in a home repair class at the local community college or trade school? Probably not. You pulled out your phone, typed the problem into a search bar, and watched a three-to-five minute YouTube video that walked you through the fix step by step. You didn't need a course. You needed the right information at the right moment, in a format you could act on immediately.

That is a job aid. YouTube just happens to be an exceptionally good delivery mechanism for it.

The same shift is happening in professional environments right now. People who need to learn a new software system are increasingly skipping the three-day bootcamp and opening a conversation with an AI instead. They describe what they're trying to do, get a direct answer, apply it, and move on. Quick. Specific. No seat time. No module navigation. No end-of-course quiz.

This isn't laziness. It's efficiency. People have always preferred the shortest path to a working answer — and the tools available to support performance in the moment have never been better or more accessible. The organizations that recognize this and design support accordingly are ahead of the ones still reflexively scheduling courses every time a process hiccups.

What a Job Aid Actually Does

A job aid is any tool that supports performance at the moment it's needed — a checklist, a quick reference card, a step-by-step visual guide, a decision tree, a short video, a prompt-ready AI tool. It doesn't teach. It doesn't build knowledge over time. It answers one question at the moment someone needs the answer: what do I do right now?

That is exactly what the dropdown problem requires. A simple one-page reference — or a decision tree posted next to the workstation or embedded directly in the system — that describes each scenario in plain language and maps it to the correct option. If the customer's situation looks like this, select Option A. If it looks like that, select Option B. Here's how you tell the difference.

That reference does not require a course. It requires clear writing, a solid understanding of the two scenarios, and a fraction of the development time a full training would demand.

The course, by contrast, takes weeks to develop, hours to deploy, and gets evaluated — if it gets evaluated at all — at Kirkpatrick Level 1. Did you like the training? Sure. Are you still selecting the right option six weeks from now when the dropdown label still sounds ambiguous and you're moving fast through a queue? That's a different question, and nobody's asking it.

The job aid lives at the point of performance. It gets consulted every time someone hits that decision point. That is the tool that solves the problem.

When the Customer Still Wants the Training

Here's where it gets uncomfortable. You've done the analysis. You've identified that there's no meaningful skill or knowledge gap — just a moment of ambiguity in a workflow that needs a reference tool. You've recommended a job aid. And the manager says: I understand, but we really need a training.

This happens constantly in L&D, and it's worth being honest about why.

Sometimes it's about accountability. A training course creates a completion record. The manager can document that every team member completed the module, and if errors continue, the documentation shifts responsibility. A job aid doesn't generate a completion certificate. It just sits there doing its job.

Sometimes it's about perception. Training feels substantial. It signals investment. A job aid — even a brilliantly designed one — can feel like a consolation prize to a stakeholder who came in expecting a course.

And sometimes it's about not understanding what L&D actually does. The assumption is that training is the product and everything else is secondary. Part of your job as an L&D professional is to push back on that assumption — respectfully, with evidence, and with a clear explanation of what each solution actually accomplishes.

The conversation worth having is this: a training course will take weeks to develop, will require hours of employee time to complete, and will be evaluated on whether people liked it. A job aid will take days to develop, will be available at the point of performance indefinitely, and will be consulted every time someone hits that decision point. Which one actually solves the problem you described?

The Right Tool for the Right Problem

Let's now take a second look at the scenario at the start of this post where the workforce was having issues completing an online form. We had a team that had been doing the job for months — they understood the process, they knew the workflow, they just couldn't reliably distinguish between two similarly labeled dropdown options at the moment of decision. That's a job aid problem — a clear, well-designed reference tool solves it without a course, without seat time, and without a Level 1 smile sheet.

Now change one variable. The organization updates the form. New fields. New options. New routing logic with consequences nobody on the team has seen before. The workforce doesn't know what the new form is, what it does, or what happens when they select one option over another. They're not choosing wrong because the label is confusing — they're choosing wrong because they genuinely don't know what they're choosing between.

That's a knowledge gap. And a knowledge gap requires training.

The distinction matters because the solutions are not interchangeable. A job aid handed to someone who has never seen the new form won't build the understanding they need to use it correctly. And a training course built for a team that already understands the process but needs a decision-point reference is an expensive, time-consuming answer to a five-minute problem.

Your employees are already using YouTube and AI to answer questions in the moment. They're not waiting for a course to tell them how to do something they could figure out with the right reference. The question isn't whether performance support works — it demonstrably does. The question is whether your organization is designing it intentionally, or leaving people to find their own workarounds.

A Tool Can Generate a Prototype. It Can't Tell You If Your Analysis Was Actually Finished.

I've been watching people talk about Claude Design like it's about to make half the instructional design career field obsolete. Describe a course, get a prototype back in minutes — no Figma, no coding, no waiting on a developer. It's a genuinely useful tool, and I don't doubt the excitement is sincere. But "revolutionize the field" is doing a lot of work in that sentence, and it's worth actually unpacking what it would take for that to be true.

Here's what a tool like that can't do, no matter how good the underlying model gets: it can't tell you whether the analysis it's building from was actually finished.

That's not a small caveat. It's the entire job. ADDIE isn't a five-letter acronym you memorize and then execute in sequence — Analysis, Design, Development, Implementation, Evaluation, check the boxes, done. Applying it is a skill, and most of that skill lives in the Analysis phase, which is exactly the part that's invisible in a finished prototype. Nobody looking at a slick mockup can tell whether the interviews behind it actually surfaced the real performance gap, or just confirmed what the SME already assumed going in.

Take a concrete example. A stakeholder tells you employees "don't understand the safety procedure." A practitioner who actually knows how to apply ADDIE doesn't take that at face value — they ask what "don't understand" means operationally. Is it a knowledge gap, or is it that the procedure itself is unworkable on the floor and everyone's improvising around it? Those are two completely different training solutions, and one of them isn't a training solution at all — it's a process fix that no course will ever touch. A generative tool can build you a beautiful course for either interpretation. It has no way of knowing which one you actually need, because that judgment call happens in a conversation, in a follow-up question, in noticing that the stakeholder's frustration doesn't quite match what the frontline workers are describing. None of that produces a prompt. It produces a conclusion a practitioner reaches by actually doing the analysis.

Or take Kirkpatrick's Level 3 and Level 4 — behavior change and business results, the two levels most people entering this field skip past because they're hard to measure and harder to attribute. Knowing how to design toward those levels, instead of stopping at "did they pass the quiz," is a skill you develop by watching training fail to change behavior and figuring out why. A tool can generate an assessment. It can't tell you that the assessment is measuring recall instead of the thing that actually matters, because it doesn't know what mattered in the first place — it only knows what you told it, and if what you told it was incomplete, the output will be a polished version of that same incompleteness.

A tool also can't be in the room.

I ran a pilot once for a program where we'd completely restructured the training — pulled all the knowledge-based content out of the ILT and moved it into an eLearning course, then rewrote the ILT itself as a single day of real-world exercises. We built those exercises from scratch, designed to simulate the actual work. On paper, it was a clean split: eLearning for knowledge, ILT for application. In the room, it fell apart by lunch. The learners didn't have enough context to understand what the exercises were actually building toward — we'd assumed the eLearning had given them enough of a frame to walk into hands-on work cold, and it hadn't. You could see it happening in real time: the confused looks, the exercises stalling out, people going through the motions without understanding why. We stopped the pilot at lunch and went back to rebuild the exercises using actual artifacts and items from the workplace instead of the ones we'd invented, so the exercises finally connected to something learners already recognized.

No prototype would have caught that. A generated course can look complete, sound complete, hit every objective on the outline — and still fail the moment real people are sitting in a room trying to do the thing you designed. The gap between "this should work" and "this is working" only shows up in front of an actual audience, watching actual faces, in real time. That's not a data point you feed into a tool afterward. It's a judgment call you make on the spot, mid-pilot, deciding the exercises are broken before the day is even over — and then doing the harder work of rebuilding them from something real.

This is why I don't think the field is being revolutionized so much as it's being handed a much faster front end. The prototype used to take days to mock up. Now it takes minutes. That's real, and it's useful, and I'll take it. But the thing that separates a course that works from a course that just looks finished was never the mockup stage. It was whether someone did the unglamorous work of figuring out what was actually broken before anyone touched a storyboard, and whether someone was in the room to catch it when the design didn't hold up against real people. A tool can't do either of those things. It can only build, very quickly and very convincingly, on top of whatever you hand it — including your mistakes.

That's the part of the job that doesn't get revolutionized by a better prompt box. It gets learned, slowly, by doing the analysis wrong a few times, watching a pilot fall apart in real time, and paying attention to what that cost.

What AI Can Do for Instructional Design. What It Can't. And What It Probably Shouldn't — For Now.

There are three different questions buried in every conversation about AI and instructional design, and most people only ever answer one of them. What can AI do. What can't it do. And — the one almost nobody asks, maybe because nobody feels qualified to answer it yet — what shouldn't it do, even in the cases where it technically could.

I don't think anyone's actually qualified to answer that last one with certainty. AI in this field is still in its crawling phase. What follows is where my thinking currently sits, not a rulebook — best guesses and emerging patterns, not settled conclusions. Ask me again in a year and some of this may look wrong.

Here's why I'm even willing to try, though. I've watched this exact cycle before, more than once. Gamification showed up, and within a couple of months of average IDs getting their hands on it, conference stages were full of people declaring it the biggest thing to happen to the industry since eLearning itself existed. A few months after that, nobody was talking about it anymore. AR and VR did the same lap — the breathless keynote, the vendor booths, the case studies — and then the quiet fade once the cost and the clunkiness caught up with the hype. Both were real tools with real, narrow use cases. Neither one changed how the average ID actually worked day to day.

AI is not doing that lap, or at least it doesn't look like it yet. The closer comparison isn't gamification or AR/VR — it's the release of rapid authoring tools like Captivate and Storyline. Those didn't just add a feature to the toolkit. They changed the actual workflow of the job, for everyone, permanently. Nobody today builds a course the way they did before rapid authoring existed, and nobody's debating whether that shift was a passing trend. AI looks like it's headed toward that same category — a genuine overhaul of what we do, can do, and should do — rather than another gamification-shaped fad that quietly exits the conversation by next spring. That's a guess based on the shape of the thing so far, not a certainty. But it's the reason I think the "can / can't / should" question is worth sitting with seriously right now, instead of waiting to see if this one blows over too.

Start with what it can't do, because that list is short, and it's the part I'm most confident about.

AI cannot conduct the interview. It cannot sit across from a warehouse supervisor and notice the pause before she answers the question about why the new process keeps failing, and follow that pause instead of the transcript. It cannot walk the floor doing a job shadow, watching how the actual work happens versus how the SOP says it happens, and catch the gap between those two things that nobody wrote down because nobody thought to. It cannot conduct a Level 3 evaluation in the field, watching whether the training actually changed behavior on the job, months after the course ended and the survey scores stopped mattering. And it cannot build a meaningful interaction or activity, in either ILT or eLearning, because meaning isn't something you generate from a prompt. It's something you earn by understanding what the business is actually trying to fix. It can absolutely create an interaction — the question is whether that interaction is tied to anything real. Ask it for one and, left to its own judgment, you'll likely get a matching game: flip a card, find the term, find the definition. What you actually need is a scenario that forces someone to apply that definition the way the job requires it. AI can build either one. It has no way of knowing, on its own, which one you actually need.

Now, what it can do — and this is the part everyone's already using whether or not they're being honest about it. Feed it the results of those interviews. Feed it the comments from an audited training program, the findings from that job shadow, the data from the L3 evaluation, the hard numbers on what it costs to develop and deliver the training versus what it saves once it's actually working. Give it that input, as prompts and as data, and it can generate an output — a course outline, a needs-analysis report, a design document, a first-pass structure for how the training should be organized and why. That's not nothing. That used to take days of staring at a blinking cursor, turning forty pages of interview notes into a framework that made sense. Now it takes an afternoon, because the raw material was already good — a human went and got it the hard way — and the AI's job is just to help organize what a human already found.

Which brings me to the question I don't think anyone can answer with real authority yet: not what AI can do, but what it should.

Here's my current thinking, offered as a working hypothesis rather than a rule. In the ADDIE model, Design is the outline, the framework, the general direction — what the training is going to be, how it's structured, why it's built that way. Development is what happens after the client approves that design: turning it into an actual, usable product. My instinct right now is that AI belongs in Design, and probably shouldn't be doing Development on its own — but I hold that loosely, because the tools are changing fast enough that this could look outdated within months.

Here's the reasoning behind the instinct, for what it's worth. AI tools right now can already generate a working prototype, a mockup, a slide deck, in minutes, from a prompt. That's genuinely useful, and I use it. But there's a difference between "AI can produce something that looks like a finished product" and "I'm comfortable letting it be the one that finishes it." The Design phase is fast, iterative, disposable — you're supposed to throw away nine outlines to find the tenth one that's right, and AI seems like a genuinely good tool for that kind of rapid, low-stakes exploration. Development, at least so far, still feels like where the craft lives — the judgment calls about pacing, the decision to cut a scene that tested fine but felt wrong, the thousand small choices that separate a course that technically covers the content from one that actually changes behavior. Maybe that changes. Maybe in a year the tools get good enough at those judgment calls that this whole distinction stops holding up. Right now, though, handing off Development entirely doesn't feel like it saves time so much as it swaps a slow, thoughtful process for a fast, thoughtless one.

So here's where I've landed, for now: use AI to cut into the parts of the job that were always just overhead — the time-consuming, expensive, repetitive stretch of turning raw analysis into a workable outline. Be more careful about handing off the part of the job that was never overhead to begin with. Whether that turns out to be the right line, or whether it looks naive a year from now, probably comes down to the same test I'd apply to gamification or AR/VR if I were being honest at the time instead of in hindsight: is this actually changing how the work gets done, or is it just the thing everyone's talking about this quarter. I think I already know which one this is. I've been wrong before, standing on a conference floor, watching something get declared the future.

A Picture Tells 1,000 Words. So Why Do We Still Build Slides Full of Them?

Corporate training didn't start with PowerPoint. It started with transparencies on an overhead projector, and before that, a blackboard and whatever the instructor could write fast enough to keep up with their own mouth. When PowerPoint came along, it didn't change much about how we thought — it just gave the same analog slide a digital home, complete with basic graphics and timed builds to help the audience focus on whatever point was being made at that moment.

Somewhere in there, someone tried to fix the obvious problem — slides were getting overloaded, audiences were checking out — and the fix became a convention that got taught in every "effective presentations" workshop for the next couple of decades: 6x6. No more than six bullets per slide, no more than six words per bullet. The logic behind it made sense on paper — less text, less overload, easier for the presenter to keep slides clean and the audience to keep up. But the convention was built around managing text, not eliminating it. It assumed the fix for too many words was fewer words, when the actual problem was asking people to read at all.

Humans are genetically wired to recognize shapes, color, motion, and sound. That's not a training preference, that's neurology — it's older than language, older than written communication, older than the concept of a slide. Reading, on the other hand, is a learned skill. Nobody's born knowing how to do it. And yet here we are in 2026, still defaulting to slides that ask an audience to do the one thing they weren't built to do instinctively, while ignoring the things they were.

And that's before you even get to the audience members for whom reading isn't just unnatural, it's actively difficult — dyslexia and other reading-related differences that a text-heavy slide deck does nothing to accommodate and everything to punish. Do we really want to sit with what that means for how much of our training has quietly failed a portion of every room we've ever presented to?

Here's the deeper issue, and it's not really about slides at all. It's about which question we're answering when we build the course. Content-based design asks "what does the SME think the learner needs to know?" and then dumps that information onto slides because someone said it was important. We've known for years this doesn't work. We keep doing it anyway, because it's easier, because it's what the SME handed us, because turning a stack of documentation into bullet points feels like progress even when it isn't.

Learner-based design asks a different question: what does the learner actually need to experience to walk away able to do the job? Content comes second, not first. That shift — putting the learner's experience ahead of the content dump — is what lets you capture attention and tap into internal motivation, which will always outperform external motivation, no contest. It's what lets you actually engage the senses instead of just the eyes: color, shape, motion, sound, doing real instructional work instead of decorating a bullet list. The best courses aren't built by writing better bullets. They're built by not defaulting to bullets at all.

I saw this pattern up close working for a training consulting firm years ago. We'd write a 500-plus-page manual describing, in exhausting detail, exactly how a piece of facility equipment worked — every valve, every reading, every procedure, spelled out in prose. Then we'd copy and paste that same manual, section by section, straight into PowerPoint. Then we'd teach it. Two to three weeks per class, reading the manual back to the room one slide at a time, because that's what the deliverable had always looked like and nobody stopped to ask if it should.

Take three-phase AC power as the example, because I've watched both versions get taught. Version one is two hours of text-based lecture — slides full of definitions, phase angle explanations, voltage relationships, all of it technically accurate and none of it landing, because you're asking someone to build a mental picture of a rotating electromagnetic field entirely out of sentences. Version two is a single animated graphic: three sine waves, offset by 120 degrees, moving in real time, showing exactly how the phases relate to each other as they happen. The second one doesn't take two hours. It takes about thirty seconds to click, and it teaches the concept better than the lecture did, because it's finally speaking the language the brain showed up already knowing.

That's the whole argument, really. A picture tells a thousand words. We've had the saying for a hundred years and spent most of that time building training that argues with it anyway.

What My Colonoscopy Taught Me About Instructional Design

Yesterday was my third colonoscopy. I want that out of the way early, because it matters to the story — three times through this exact process, and it never once occurred to me that I was watching an ADDIE project play out in real time. Not until I was home eating my first meal in nearly 48 hours yesterday afternoon.

Let me explain.

The initial consult in the doctor's office, where we discussed my symptoms and agreed to performing the colonoscopy, is effectively the initial kickoff meeting with a potential client. Nothing happens yet. Nothing's built yet. It's just two people agreeing on what the project actually is before either of them commits to anything. Skip this meeting, or rush it, and everything downstream gets worse. Every ID who's ever built a course without a real kickoff already knows exactly where this is going.

Then comes the analysis phase, and if you've ever done a real needs analysis, you already know it's the worst part of the job. Everyone wants to skip straight to building. Nobody wants to sit in the discomfort of figuring out what's actually wrong before they start designing a solution. The prep for a colonoscopy is that discomfort made extremely, unambiguously literal. You are handed instructions. Specific instructions. Follow them exactly, in order, on schedule, or the data's no good and you're doing this again. And then you spend the next several hours doing what I can only describe as a series of increasingly urgent data-collection runs to the bathroom, each one somehow both identical to and worse than the last, until at some point you stop asking "am I done yet" and start asking "was I ever going to be done, or is this just the process now." That's every SME interview I've ever sat through, if I'm honest. You ask the same question four different ways because the first three answers didn't actually tell you anything. You think you're finished. You are not finished. Ask again.

Eventually — and only eventually — everything clears up. And I mean that in every sense the word offers. The analysis is done. The information's clean. You know what you're working with. You're ready to build.

I knew the colonoscopy itself was a relatively quick process, but I didn't know how quick the entire thing actually is. I was put under at 10:04 and woken up at 10:36. Thirty-two minutes, and I experienced approximately none of them. The scary part was never in the operating room. It was always the at-home prep. Likewise, the scary part is never working in PowerPoint or Storyline — it's always the analysis.

I think about how often I've watched that same pattern play out in a project that had nothing to do with a hospital. The build gets treated like the hard part, the part that needs the schedule padding, the part everyone braces for — when really, if the kickoff was honest and the analysis was actually finished instead of just declared finished, the build is the easy afternoon. The nurses prepping the room, running through checks, making sure everything's positioned right before the doctor ever walks in — that's your peer reviewers and your graphic designers, quietly doing the work that makes the actual event look effortless. The front desk scheduling everything, sending the reminders, making sure the right people show up on the right day with the right paperwork — that's your training coordinators and your LMS admins, and nothing happens without them either, even though nobody remembers to thank them afterward.

Three times through this exact process, and it took the third one to notice the pattern. Which either means I'm a slow learner, or it means some lessons only show up once you've sat with the discomfort long enough to actually recognize it. Possibly both.

AI Didn't Build My New Website. It Just Stopped Letting Me Pretend I Couldn't.

My website wasn't broken. That was almost the problem — it worked exactly as designed, and what it was designed to say was "I don't know what I'm doing." Nobody told me that. I had to figure it out myself, which either makes me perceptive or six months late to my own party. Probably both.

Here's the math I hadn't done: if my website — the thing housing my portfolio, the thing that exists specifically to convince someone to hire an instructional designer — felt lifeless and disengaging, why would anyone assume the eLearning I built for them would feel any different? I wouldn't make that leap of faith. I've sat through enough dead, disengaging training to know better than to bet on a stranger's promise that "no, really, my actual work is good, I swear." And I definitely wasn't clicking through to a portfolio page to find out, if the homepage had already told me everything I needed to know.

But say someone did make it that far — did go looking, did click through. What were they actually going to find? A three-minute video clip of an interactive Storyline course, published as a video. Not interactive. A video of interactive. Because I didn't know how to code, and Squarespace's block-and-template system will let you display a lot of things, but "let someone actually click through your interactive eLearning" isn't one of them. So the one piece of proof I had that I could build engaging, interactive learning was, itself, neither engaging nor interactive. That's not irony, that's just bad advertising.

And even that video only showed the last five feet of a much longer race. Most portfolios show the finished product — here's a course, look how polished. Mine did that too, and it was still incomplete, because building the course isn't the hard part and it isn't the part that separates a real practitioner from someone with six months of Storyline tutorials under their belt. A lot of people are moving into this field right now as developers, not as practitioners — they can build a course, but they've never run a full analysis, never figured out that the actual fix for a performance problem is sometimes a job aid or a process change and not a training module at all, never heard of Kirkpatrick Level 3 or Level 4 evaluation, let alone conducted one. None of that was showing up on my site either. I've done all of it. My portfolio needed to say so, and needed to show that I can do the things others either don't want to do or don't know how to do.

I learned this lesson in the Navy, over twenty years ago, long before I built truly interactive eLearning or even this website. After each watch, we'd do a daily area cleanup — and sometimes that first swipe of a chem-wipe sprayed with Simple Green showed you how dirty everything actually was. That first swipe was my portfolio. The area around it was the entire website.

The colors themselves were easy — I originally chose shades of blue and grey because I like them, because I'm most comfortable with them, because they speak to me. I wasn't about to change that. What I didn't have was the right shades — the specific tones that would make the palette feel alive instead of just present. So the colors stayed. The exact hex values didn't.

The navigation was uglier than I'd admitted to myself. Every individual page — contact, appointments, portfolio, the works — sat in the header as its own link, and it looked exactly like what it was: cluttered and dated. I built a collapsible side panel instead, one the viewer can show or hide, which sounds like a small fix until you realize how much visual noise disappeared the moment it existed.

Then there was the product-image problem, which I'd assumed for over a year was a Squarespace limitation — square crops cutting the tops and bottoms off portrait-oriented product photos. It wasn't a limitation. I just hadn't found the setting. Once I did, every product image on the site actually shows the entire product, which is a genuinely embarrassing thing to fix sixteen months in.

And then accessibility, which I'd said I took seriously, but didn't fully understand what that actually meant. It was a priority when rebuilding my site, and it's a priority now when I'm building eLearning. Every time I do something, I'm asking myself: is this appropriate color contrast, would someone who's color-blind still be able to distinguish what I'm showing them, do the closed captions actually line up to the audio script, are the alt-text labels accurate — and so on. That's not a question I asked once and closed out. It's a question I ask now, every time, and a check I run every time I create a new product or make a major change to an existing one.

Every one of these fixes followed the same pattern — I didn't know what I didn't know, until something forced me to find out. The exact shades. The crop settings. My own understanding of what accessibility actually required. Small on their own, but together they're the same lesson on repeat: you don't find the gap until you go looking.

Here's the part I actually want to be honest about: I knew I could do better. I'd known it for sixteen months. What I didn't have was the execution — the specific shades that would take the palette from dirty to clean, the interactivity and small subtle touches most visitors won't consciously notice but will feel, the ability to actually show the full breadth of what I do instead of one flat video clip standing in for all of it. AI didn't hand me any of that as a talent. It's not a talent. What it did was take the eye I already had — twenty-five years of knowing what good instructional design looks like — and let me finally build to it, instead of building to the limit of what I could code by hand. I knew what "better" looked like the entire time. AI is what let me stop just knowing it and start shipping it.

Learning to vibe code and using agentic AI to formalize processes and run routine analyses is helping me be a better instructional designer. Not because AI is doing the designing for me, but because it's enabling me to finally ask and answer a question I'd avoided for years: what have I been doing on autopilot, never once stopping to check if it could be done better? I doubt I'm the only one who's been coasting on habit somewhere without noticing.

To Thine Own Self Be True — And Other Advice From Someone Who Wasn't

"To thine own self be true."
— Polonius, Hamlet, Act I, Scene III

Here is the thing about that quote. Polonius is not a wise man. He is a scheming, manipulative courtier who spends most of Shakespeare's play meddling in affairs that are not his concern — and ends up dead behind a curtain for it. That famous line is part of a long, self-important farewell speech he delivers to his son before sending him off to Paris. Polonius himself is, famously, not true to himself throughout the entire play. Shakespeare almost certainly intended the irony.

And yet — the idea survived the messenger. Four hundred years later, we are still quoting it. Because the principle is sound, even when the person saying it isn't.

I knew I could not draw in junior high. It never kept me up at night, because I had other things going for me — writing, analysis, breaking down complex information and making it make sense to people who needed it to make sense. The fact that I could not put a pencil to paper and produce something recognizable was just a fact about me. Not a crisis.

Then I became an instructional designer. And that fact developed consequences.

For a long time, my workaround was human. Throughout my career I worked with graphic designers — some freelancers, some coworkers — who could take what I was seeing in my head and put it on screen in a format that was natural for learners. I knew what I needed and I could communicate it clearly. They could execute what I could not. The work was better for it, and I was not embarrassed by that arrangement. I was deliberate about it.

That is what knowing your weakness actually enables. Not embarrassment. Not paralysis. A decision.

What I did not anticipate was how the tools themselves would start to close the gap.

I am not an AI evangelist. I want to be clear about that. I am cautious, I am still learning, and I am aware that I do not know what I do not know. What I can say is that I did not adopt AI to replace my process. I adopted it to expand what my process could reach.

I still cannot draw. But I can now produce custom graphics using tools that did not exist five years ago. I can generate the kind of visual content that used to require a specialist — not because I became a designer, but because the technology changed what I could communicate and what I could build from that communication. I can write custom code for eLearning interactions without knowing how to code. I completed a full website refresh that I could not have executed on my own. The things I was never going to be good at — illustration, visual creation, front-end development — are no longer the hard stops they used to be.

And the things I have always been good at — analysis, curriculum structure, breaking down genuinely complex technical content, writing — those did not go anywhere. AI did not replace them. It sits alongside them. I bring the thinking. The tools help with the execution my hands could never quite catch up to.

That is worksharing. It just looks different than it used to.

Knowing yourself is not a one-time inventory. It is an ongoing practice — because the tools change, the industry changes, and what felt like a permanent ceiling a decade ago may not be one today. The wall I identified in a junior high art class is not as tall as it used to be. I did not get better at drawing. The landscape around the wall shifted.

That is worth paying attention to. Not because AI is the answer to everything — it is not — but because the honest question is not what am I bad at in some fixed, permanent sense. The honest question is what am I bad at right now, and what options do I actually have?

Those answers keep changing. Which means the self-assessment has to keep happening.

Know thyself. Your strengths and your weaknesses. Both. Clearly. Honestly. And then keep asking the question — because the answer will not stay still.

I Knew I Could Do Better — So I Did

I built my website about sixteen months ago. For the first several months, it did what I needed it to do. But somewhere around the six-to-nine month mark, I started noticing what it wasn't doing — and I couldn't un-see it. The template constraints, the image cropping, the layout limitations. It worked. It just didn't reflect the level of work I was actually delivering for clients. My plan was to hire a professional webmaster this year and have a properly coded site built from scratch. That was the plan.

Then I went to ATD ALC.

I attended a session where the ATD Chapter DEIB Committee walked through using generative AI to review governance documents — bylaws, policies, the kind of foundational text organizations don't look at critically very often. Sitting in the closing keynote later that day, I took photos of my notes and a colleague's notes and asked Claude to organize them, identify the key themes, and pull out the top three takeaways and action items for each of us. It did. Cleanly. Accurately. In minutes.

When I got home, I checked off one of my own action items and had Claude review our chapter's bylaws for bias and ableist language. The results were eye-opening. Then I pushed further — I pulled together CSVs of member data, non-member data, event attendance records — and asked Claude to tell me what we had never thought to ask about our own data. What came back surprised more than a few board members. We weren't missing data. We were missing questions.

That shift in thinking changed my approach to a lot of things. Including my website.

I need to give credit where it's due. Last November at DevLearn, I attended a session by Jeff Batt where he talked about using vibe coding and generative AI to build learning experiences and websites — without knowing how to code. It planted a seed. When Claude's vibe coding capabilities expanded this year, a lot of instructional designers immediately saw the eLearning applications. I also watched what Tim Slade was starting to do with it. Their work gave me permission to stop waiting for the "right" solution and start building.

Instead of hiring a webmaster, I used Claude to rebuild my Squarespace site — and the difference is significant. Visually, in how content is displayed, in how the site actually behaves. One of my specific frustrations had always been images being forced to fit template placeholders rather than the other way around. That's fixed. I also used Claude to ensure the site meets GDPR requirements and includes proper cookie disclosure options. GDPR is more restrictive than U.S. requirements — and I made that choice deliberately. If I'm going to hold myself out as someone who builds accessible, professionally sound learning experiences, I should be holding my own web presence to at least the same standard.

Speaking of which — accessibility. I can't, in good conscience, tell clients I build accessible eLearning while running a website that fails basic accessibility checks. I used Claude alongside an independent online accessibility scanner to audit the entire site, identified the issues, and had Claude help adjust the underlying code to bring it into compliance. High-level: it's done, it's cleaner, and it's something I can stand behind.

The one area still in progress is the portfolio — honestly, the section I was most dissatisfied with from the beginning. I'm rebuilding it this week using Claude, Articulate Storyline, Canva, and Adobe Firefly, with a focus on making it genuinely useful for potential clients while ensuring every sample in it is fully accessible.

The rest of the site? Take a look. I hope you're enjoying what you're seeing — because for the first time in a while, so am I.

Why "It's Obvious" Is a Design Failure

‍Special contribution by Stéphane Mousseau, Operational Clarity Architect and Founder of LIX™‍ ‍

The Most Expensive Phrase in the Workplace

"It's obvious." Most of us have heard it. Some of us have said it. A manager explaining a process. A subject matter expert reviewing a training program. A team member wondering why someone made a mistake. The assumption is always the same: If someone didn't understand, they simply weren't paying attention. But what if the opposite is true? What if "it's obvious" is often evidence that something wasn't designed clearly enough in the first place?

The Curse of Knowing

One of the most common challenges in learning, documentation, and process design is something psychologists call the Curse of Knowledge. Once we know something, it becomes incredibly difficult to remember what it feels like not to know it. The steps seem obvious. The terminology feels familiar. The expectations feel self-explanatory. As a result, we unintentionally design for people who already understand the system rather than those encountering it for the first time. This happens everywhere:

●     SOPs that skip critical context
●     Onboarding programs built around assumptions
●     Training that explains concepts but not application
●     Leaders who communicate expectations they never explicitly state

The expert sees clarity. The user experiences confusion.

Confusion Is Data

When employees ask repeated questions, organizations often see a performance problem. When learners make mistakes, they assume more training is needed. When new hires struggle, they add more coaching. Sometimes that's true. But often, confusion is data. It is feedback from the system. A signal that something intended to be clear was not actually understood. Every repeated question points to a potential design opportunity. Every recurring mistake reveals friction somewhere in the experience. The issue is not that people are failing. The issue is that the system is teaching them something different than what was intended.

The Hidden Cost of "Obvious"

Most organizations underestimate the cost of unclear communication. Not because the consequences are dramatic. Because they are distributed. A few minutes spent searching for information. A clarification email. A process completed incorrectly. A manager answering the same question for the tenth time. Individually, these seem insignificant. Collectively, they create what I often refer to as a clarity tax: a hidden operational cost paid every day. Work takes longer. Onboarding slows. Decision-making becomes inconsistent. Performance becomes dependent on tribal knowledge instead of reliable systems. The cost rarely appears on a financial statement. But it is paid nonetheless.

Why Some People Notice First

Interestingly, the people who identify clarity problems first are often neurodivergent employees. Not because they lack capability. Because they are often less willing, or less able, to fill in gaps with assumptions. Where others see: "It probably means this." They may ask: "What exactly does this mean?" That question is incredibly valuable. It exposes ambiguity that was already there. The same ambiguity many other employees are quietly navigating every day. This is one reason neuroinclusive design often benefits everyone. The friction existed all along. Some people simply felt it sooner.

Small Changes. Extraordinary Impact.

Organizations often search for large solutions to performance problems. More training. More oversight. More communication. More technology. Yet some of the highest-impact improvements come from surprisingly small changes. A clearer heading. A rewritten instruction. A visual example. A defined expectation. A checklist. A better-organized process. Individually, these adjustments appear minor. Collectively, they can transform how easily people learn, understand, and execute. Small changes. Extraordinary impact.

A Simple Test

The next time you hear someone say: "It's obvious." Pause. Ask a different question. Obvious to whom? The expert? The designer? The manager? Or the person encountering it for the first time? Because when understanding depends on prior knowledge, assumptions, or unwritten rules, the problem is rarely the person. More often than not, it is a design opportunity hiding in plain sight.

Making the Invisible Visible

One of the reasons I became fascinated with clarity is that these problems are rarely visible. Organizations can see the outcomes. They see mistakes. Questions. Delays. Rework. What they often cannot see is where the friction originates. That realization ultimately led me to create the LIX™ Clarity Snapshot. Not to evaluate people. To help identify hidden clarity gaps inside the systems people depend on every day. Because if a process only works when someone already knows the answer, it isn't truly clear. And if understanding depends on assumptions, "it's obvious" may be less of an explanation and more of a design failure. If you're curious about where hidden friction may be slowing performance inside your own documentation, onboarding materials, or workplace systems, you can explore the free Clarity  

Snapshot at: https://lixlearning.com‍ ‍Because performance doesn't happen in a vacuum. It happens inside the systems we design. And when clarity improves, performance often follows.


—-----------------

Stéphane Mousseau is an Operational Clarity Architect, learning strategist, and founder of LIX™ Learning, where he helps organizations identify and remove hidden friction that impacts performance. Drawing on more than 20 years of experience in Learning & Development with organizations including Arc'teryx, lululemon, Aritzia, and MEC, Stéphane specializes in designing clearer documentation, learning experiences, and workplace systems that help people perform at their best. His work is rooted in a simple belief: many performance challenges are not people problems, but clarity problems. Through LIX™, he combines operational thinking, neuroinclusive design principles, and practical analysis tools to help organizations create environments where all minds can thrive. He is also the creator of the LIX™ Clarity Snapshot, an AI-powered tool that helps teams uncover hidden clarity and execution risks inside workplace documents in under a minute. Connect with Stéphane at lixlearning.com or follow him on LinkedIn.
www.linkedin.com/in/stephanemousseau‍

The Search That Started Bailey's eLearning Treats

Every instructional designer I know has hit the same wall. You are building a course, you get to the avatar selection stage, and you start searching. You need someone older. Someone with a visible disability. Someone in a wheelchair who looks like they work in an office, not a hospital. A person of color with a mobility aid. You search. You refine. You search again. What you find, if you find anything at all, are the same three images cycling through every stock library on the internet — clinical settings, passive poses, and a demographic range so narrow it would embarrass a 1987 corporate training video. After enough of those searches, most designers do what the deadline demands: they compromise. They grab what is available and move on. I did it too. For years.

The conversation I kept hearing in instructional design communities was not about accessibility — designers understand accessibility. It was about something quieter, but one with a simple solution: the near-total absence of realistic, working, living representations of the people who actually sit in our training. Not the idealized stock photo version of a workforce. The actual one — with the full range of ages, body compositions, ethnicities, gender identities, visible disabilities, personal expressions, and human variety that shows up in any real organization on any given day. I believed in that principle. I talked about it. I just had not held myself accountable to it. I had diverse avatars in my own work, but they were not necessarily representative of my actual audience. There is a difference between diverse and representative, and for a long time I let myself believe checking one box meant checking both.

That is when I stopped talking about the problem and started building the solution. I needed a place to go to find avatars that genuinely reflected the people sitting in the training — and when that place did not exist, I built it. That is what Bailey's eLearning Treats is. Not a stock photo library with a diversity filter applied as an afterthought. A catalog built gap-first — meaning the gaps in existing resources drove every character decision from the beginning. Who is missing? Who does the industry consistently fail to represent? Who does the instructional designer searching at 4pm before a deadline never find? Those are the characters I build. The catalog targets age range deliberately — not just the 28-year-old professional default, but characters across the full working lifespan. It targets body composition, personal appearance, and visible self-expression — tattoos, colored hair, the human variety that stock libraries still treat as edge cases. And it targets disability representation with specific intent, because this is where the gap is most severe and most consequential. Wheelchair users who are active professionals. Amputees. Characters with service animals. People whose visible difference is part of who they are, not the entire story the image is trying to tell.

The library comes in both photo-realistic and illustrated styles, because different courses, different organizations, and different design aesthetics call for different approaches. Both styles are built to the same standard: characters specific enough to feel real, diverse enough to reflect the actual workforce, and consistent enough across poses and expressions to carry a full course. A designer should be able to open Bailey's and find someone who looks like their learner — not approximate it, not settle for close enough, but actually find them. That is the benchmark every character in the catalog is built against.

The instructional design community talks constantly about putting the learner at the center. Representation is the most immediate, most visible, most concrete expression of that principle — and it starts before the first learning objective, before the first interaction, before the first word of content. It starts with who the learner sees on screen. I needed to hold myself accountable to that truth and be the change I was advocating. That accountability did not require a manifesto. It required building something. And I did.

Michael & Ishmael - One of Many Avatar Options