The First Question You Should Ask Before Accepting Any Project

Imagine this: you come back from a week-long vacation and work through your backlog of emails. One of them stands out. It’s from your supervisor, describing a new project from an internal customer you’ve never worked with before. A scoping meeting has been set for that afternoon.

You walk in. The customer doesn’t waste any time. His organization can’t do their job. It’s taking three times longer than the budget allows. His team has trouble performing even the basic parts of their work. The error rate exceeds 25%. He wants a new training program — something comprehensive, something that will teach his people how to do their jobs efficiently and effectively and get that error rate down.

He’s already decided what the solution is. He came in with a conclusion.

Here’s the question you need to ask before you agree to anything: What does success look like to you?

Not “what training do you need?” Not “what topics should we cover?” Not “what format do you want?” Those questions accept the premise that training is already the right answer. This one doesn’t.

Why That Question Changes Everything

When you ask someone what success looks like, you force them to define the outcome they actually care about — not the solution they’ve already decided on. And the answer almost always reveals something the original request was hiding.

In this scenario, the customer says success looks like his team completing tasks in the time the budget allows, with an error rate under 5%. That’s a measurable outcome. That’s something you can actually design toward. And more importantly, it opens the door to the question that needs to follow immediately: how do we know the problem is a knowledge or skill gap?

Because here’s what the customer hasn’t told you yet: why is it taking three times too long? Why is the error rate at 25%? He has a conclusion — his team doesn’t know how to do their jobs — but he doesn’t have evidence for it. And “my team is performing poorly” is not the same thing as “my team needs training.”

There are a dozen reasons a team might be underperforming that have nothing to do with knowledge or skill. The process they’re following might be broken. The tools they’re using might be inadequate. The documentation might be outdated, missing, or written by someone who assumed the reader already knew what they were doing. There might be a staffing shortage that means everyone is operating at capacity before they’ve finished onboarding. There might be a systemic issue upstream that sends bad inputs into their workflow and guarantees errors on the other end regardless of how skilled the person handling it is.

Training cannot fix any of those things. A new course on how to do the job will not repair a broken process, replace a missing tool, or staff a team that is already stretched past its limits. What it will do is consume weeks of development time, hours of your team’s time, and a training budget — and then, when the error rate stays at 25%, someone will say the training didn’t work.

The training didn’t fail. It was never the right solution.

What “What Does Success Look Like” Actually Does

That one question reframes the entire conversation. Instead of starting with a solution and working backward to justify it, you’re starting with an outcome and working forward to find what will actually achieve it.

It also signals something important to the client: you are not an order-taker. You are a professional who is trying to solve their actual problem, not just build what they asked for. Most clients, once they understand that distinction, appreciate it. A few will push back — they came in with a solution and they want someone to execute it. That’s a conversation worth having directly rather than just complying.

When you get the answer to what success looks like, the next question is straightforward: what do we know about why the gap exists? Not what do we assume — what do we actually know? That’s where the needs analysis begins. Not with a course outline, not with a storyboard, not with a list of learning objectives. With evidence.

In this scenario, a proper analysis might reveal that the team actually knows how to do the job — they’ve done it before, they can describe the process accurately, and the errors aren’t random. They cluster around one specific step in the workflow where the documentation is ambiguous and the tool they’re using behaves inconsistently. That’s not a training problem. That’s a documentation and tool problem that a job aid and an IT ticket will solve faster and cheaper than any course ever could.

Or it might reveal that there genuinely is a knowledge gap — that the team is newer than the customer implied, that the onboarding process was compressed, and that several critical steps were never formally taught. In that case, training is the right answer. But now you’re building it with clear outcomes, clear evidence, and a clear definition of what success looks like when you’re done.

The Question Is Simple. The Discipline to Ask It Is Not.

It is easier to just take the project. Say yes, schedule the kickoff, start on the storyboard. The customer is happy, your calendar is full, and everyone moves forward with the comfortable illusion that something is being done.

The problem is that something being done and the right thing being done are not the same thing. And when the training ships and the error rate doesn’t move, the question that follows is rarely “did we solve the right problem?” It’s “why didn’t the training work?” — and that’s a much harder conversation to have after the fact than before it.

Ask what success looks like. Ask it in every scoping meeting, for every project, from every client. Ask it before you open a new Storyline file, before you write a single learning objective, before you agree on a timeline or a budget. Ask it as if the answer matters — because it does.

The answer will tell you whether you’re about to build something that solves a real problem, or something that makes a client feel like a problem is being addressed. Those are not the same thing, and only one of them is worth your time.

If You're Checking for Accessibility at the End, You're Already Too Late

I'll start with a confession: for most of my 25 years in learning and development, accessibility was something I knew I should care about and rarely thought about. I only started to understand what it requires, and why it matters, over the past 18 months.

That's an uncomfortable admission, because I'm one of the learners it's meant to serve. I have significant hearing loss in one ear, and I wear a hearing aid to manage the tinnitus that came with it. Some voices are harder for me to hear than others, certain higher tones don't register at all, and I regularly have to ask people to repeat themselves or speak up. For years, I handled that quietly, on my own, without ever connecting it to the courses I was building for other people.

Last month, I got a lesson in what that gap costs. I sat down to add one card to the Accessibility section of my website's Resources page, and I checked the page against the standards I now hold myself to. It failed them. The text was too small, the filter buttons gave screen readers no indication of what was selected, keyboard users had no visible focus indicator, and the subtitle didn't meet WCAG contrast requirements.

Fixing those issues should have taken an afternoon. Instead, each correction created a new problem. Larger text made the filter labels overflow on phones, and the longer page tripped a site-wide fade-in script that never triggered on a block that tall. For a few hours, the entire page was invisible: an accessibility fix that made the page inaccessible to everyone.

That is what treating accessibility as a final check really costs. You aren't correcting one decision; you're unwinding every decision that was built on top of it.

Why "At the End" Doesn't Work

Disability scholar Mike Oliver introduced the term social model of disability in 1983, and it draws a distinction that changed how I think about my own work. A person's impairment is one thing. The disability is the barrier the environment puts in front of them. My hearing loss is an impairment. A facilitator who won't use the microphone, or a video with no captions, is the barrier.

If barriers come from the environment, then in our field they come from design, and design decisions get made early. Text size, color, navigation, interaction style and media formats are typically locked in during the design phase. By the time an accessibility review happens at the end of development, those decisions have been storyboarded, built, reviewed by stakeholders and approved. Changing them means reopening all of that work.

Software engineer Barry Boehm described this pattern back in 1981: the later a defect is found, the more it costs to fix, because more work has been built on top of it. My Resources page was a small-scale version of the same thing. The text size was never just a text-size decision, because the layout, the mobile behavior and a script on a completely different part of the site all depended on it.

An end-of-project accessibility check doesn't prevent problems. All it does is find them at the point where they're most expensive to fix.

The Learners You'll Never Hear From

The most common objection I hear is a practical one: "We'll accommodate anyone who asks." It sounds responsible. The numbers say it isn't.

According to the CDC, more than 1 in 4 U.S. adults, over 70 million people, report having a disability. In a global survey of nearly 28,000 employees, Boston Consulting Group found that 25% self-identified as having a disability or limiting condition, while their employers reported only 4 to 7%. Most employees with disabilities never tell their employer. And because so many disabilities aren't visible, you can't identify those learners by looking around the room.

I understand that gap from the inside. Every time I ask someone to repeat themselves, I'm doing the accommodating myself. I have to notice the problem, decide it's worth interrupting for, and speak up. An accommodate-on-request model puts that burden on every learner, every time. Many of them, especially new employees, people in compliance training and anyone who has been treated differently after disclosing, will simply stay quiet and learn less.

If you design only for the people who ask, you end up designing for a small fraction of the people who need it.

Where Accessibility Actually Belongs

Building accessibility in from the start doesn't add a phase to your process. It changes what you do in the phases you already have. Here's how that looks in my own ADDIE work.

Analysis.

My learner persona guides now include access needs alongside role, experience and motivation. That doesn't mean guessing at diagnoses. It means assuming the audience includes people with differences in hearing, vision, mobility and cognition, and recording the conditions they'll learn in: noisy break rooms, shared screens, phones, keyboard-only setups.

Design.

I define all 14 color slots in a course's Storyline theme in the style guide, and I check each text and background pairing for contrast before a single slide is built. Navigation, focus order, and what happens to visual-only interactions for screen reader users all get decided in the design document, not discovered during QA.

Development.

Alt text is written at the same time as the content, by the person who knows what the image is supposed to communicate. Captions come from the narration script, which already exists, so you don't have to transcribe the audio after the fact.

Implementation, in the classroom.

For instructor-led training, the same principle applies. Send materials in accessible formats before the session so learners can preview them. Use the microphone every time, even when the room "isn't that big." Repeat audience questions before answering them. Turn on live captions for every hybrid or virtual session. And write all of this into the facilitator guide so it doesn't depend on whoever happens to be presenting that day.

Evaluation.

Testing with a screen reader such as NVDA and an automated checker such as axe DevTools still matters. But its job changes. It should confirm decisions you've already made, not uncover the ones you skipped.

What the Research Supports, and Where It Pushes Back

None of this is new thinking. In 1997, architect Ronald Mace and his colleagues at North Carolina State University's Center for Universal Design published the Principles of Universal Design, arguing that environments should be usable by the widest range of people without later adaptation. CAST's Universal Design for Learning framework applies the same logic to instruction. It treats learner variability as the expected condition and calls for planning multiple means of engagement, representation and action from the start. That guidance was updated as UDL Guidelines 3.0 in 2024.

The most popular argument for this approach is what Angela Glover Blackwell called the curb-cut effect. Curb cuts were built for wheelchair users and turned out to help parents with strollers, travelers with luggage and delivery workers with carts. Captions work the same way. Research from the UK regulator Ofcom found that about 80% of people who use captions aren't Deaf or hard of hearing.

That argument is useful, but it has limits. Legal scholar Blake Reid warns that leaning too heavily on the curb-cut effect can subordinate the needs of disabled people to the convenience of everyone else. If the only reason to caption a video is that it helps everyone, captions become optional the moment a budget gets tight. The primary reason to build accessible learning is that disabled learners are entitled to the same learning as everyone else. The benefits for other learners are a bonus.

Learning science adds one more caveat. Ruth Clark and Richard Mayer's redundancy principle cautions that showing on-screen text that duplicates the narration can increase cognitive load for some learners. That isn't an argument against captions. It's an argument for making them learner-controlled, with a caption toggle the learner chooses rather than text forced onto every screen. That's a design decision too, and it's much easier to make at the start than to retrofit at the end.

What Doesn't Count

If you're hoping a tool can make this go away, the evidence isn't on your side. WebAIM's 2026 analysis of the top million home pages found that 95.9% had detectable WCAG failures, averaging 56 errors per page. The most common failure, low-contrast text, appeared on 83.9% of pages. Those are basic design decisions, not obscure technical problems.

Accessibility overlays, the plug-ins that promise automatic compliance, haven't solved this either. In 2025, the Federal Trade Commission required accessiBe to pay $1 million for deceptively claiming its AI tool could make any website WCAG-compliant. In April 2026, the Department of Justice

and said itself that generative AI "does not yet reliably automate" the remediation of inaccessible content at scale.

No plug-in can retroactively make a design decision you never made.

Build It In

I came to accessibility late, and I'm still learning. But the biggest lesson from these last 18 months is simple. Accessibility isn't a review you pass at the end of a project. It's a set of decisions you make at every stage, and every decision you postpone gets more expensive to make later.

Somewhere in your next audience is a learner who won't ask you to repeat yourself. Design for that person from the start.

Two Years In: What I've Learned, What I Pay For, and What Nobody Tells You

Nineteen months ago I made the decision to go out on my own. I had the skills, I had the experience, and I had a plan. What I did not have was a clear picture of what freelancing actually looked like in practice — the tools, the habits, the marketing, and the slow realization that being good at your craft is only one part of running an independent business.

The Lesson Nobody Prepares You For

I believed, genuinely, that if you had the skills people were looking for, they would find you. I was wrong.

The freelance market is a mountain of digital clutter. Talented people are buried in it every day. Having skills matters — but if no one can find you, the skills might as well not exist. Marketing and self-promotion turned out to be more important to my business than I ever anticipated, and it was something I had to learn entirely on my own.

That meant learning social media — not just posting, but understanding what kind of content builds an audience, what platforms are worth the time, and how to carve out a niche specific enough that the right people recognize themselves in what you're saying. It meant building a presence that represented me and my work accurately rather than generically.

It also meant learning skills I had previously relied on others to handle. At my last corporate position, I had a teammate who was a graphic designer — when I needed photo manipulation, video production, or audio work, she was the person I turned to. That resource disappeared the moment I went out on my own. Basic photo editing, video and audio production, and generative AI prompting all became part of my workflow out of necessity — because the alternative was paying someone else to do things I could learn to do myself, or producing content that didn't reflect the quality of the work I was actually delivering for clients.

Nineteen months in, those unplanned skills have become some of my most useful ones.

What I Actually Pay For

Here's what's currently in my subscription stack — in alphabetical order — and why each one earns its place.

• Adobe Creative Cloud — This is the heavy lifter. Video production in Premiere Pro, audio production, photo editing in Photoshop, and job aid development. Adobe Firefly is also part of the suite, which has become increasingly useful for image generation. The interface is still the worst in the industry from an accessibility standpoint — small fonts, low contrast, a visual density that would make any WCAG auditor wince — but the capability is unmatched and I haven't found a reasonable alternative that does everything it does.

• Anthropic Claude — Management assistant, script cleanup for videos, proofreading for blog posts. I use it daily. If you're reading this blog, you've already seen the output.

• Articulate 360 — Do I really need to explain this one to an instructional design audience? Storyline 360 and Rise 360 are the core of my eLearning development work. As a freelancer, I also have access to Nova. I haven't gotten heavy into it yet, but I'm sure it will, for better or worse, become a vital tool in my toolbox.

• Canva — Job aid development and image generation for social media content. I've built specific templates for my social media production that create a consistent message and look across everything I publish. My brand colors and logos are already built in — all I need to do is adjust the specific wording to reflect the product. That consistency doesn't happen by accident. It happens because the template does the heavy lifting so I don't have to start from scratch every time.

• Clockify — Accurate time tracking for hourly contracts. When you're billing by the hour, you need records that are defensible. Clockify handles that cleanly without getting in the way.

• Pixabay — Licensed stock photos and audio clips. Having a reliable source of legally usable media that doesn't require per-asset licensing has saved me more time than I can calculate.

• Riverside — Social media video creation and editing. Beyond production quality, what makes Riverside particularly useful is the ability to quickly review the audio transcript and create social media-ready shorts that can be posted directly to YouTube, LinkedIn, or other platforms as part of my broader marketing efforts. The gap between raw footage and something ready to post is significantly smaller with Riverside in the workflow.

• Substack — This has surprisingly become both one of my more enjoyable and important marketing tools I've found. In some ways, it has surpassed this blog. People have access to my Substack and can easily find it through a search of keywords within the Substack architecture. People have to know I have a website with a blog to find this. So for those of you who are reading this — thank you. It means more than you know.

• TinyPNG — Batch image compression. One of the things I do, when I'm not generating learning content, is creating graphics that support diversity and disability representation — two areas that are majorly underrepresented in the L&D community. I maintain a library of images focused on these areas, and TinyPNG enables me to package over 100 images into an easily downloadable file for my customers. Every image on this site has also been through it, because page load speed matters for accessibility and SEO.

• TinyURL — Social media URL creation. Long URLs are ugly and unwieldy in posts. This solves that in about five seconds.

And one non-subscription worth mentioning: I purchased a teleprompter license to support talking-head video recording. Reading from notes or trying to memorize scripts was producing inconsistent results. The teleprompter fixed that. It's a one-time cost that improved the quality of every video I've recorded since.

Nineteen Months Later

The skills I planned to sell are still the foundation of the business. But the skills I didn't plan on learning — the marketing, the content creation, the photo editing, the video production, the AI prompting — are what made the business visible enough to sustain itself.

If you're thinking about making the jump, go in with your eyes open. Being good at instructional design will make you a good freelancer. Knowing how to be found, how to show your work, and how to run the operational side of an independent business is what will make you a successful one.

The gap between those two things is where most people get surprised.

Where You Work Shouldn't Be Up for Debate. The Data Agrees.

A few months ago, I learned that a company I used to work for had implemented a full return-to-office mandate. Not hybrid. Not flexible. Everyone, back in the building, five days a week.

My first reaction wasn't surprise. It was frustration. Because I had worked for that company both before and after COVID, and I remembered exactly what both looked like.

Before COVID, I had an hour-long bus ride each way to get to the office. Two hours of my day, every day, just getting there and back. I wasn't productive on that bus. I wasn't with my family. I was just in transit, burning time I couldn't get back.

Then COVID happened, and everything shifted. I got up in the morning, took the dogs for a walk, and was at my workstation without losing two hours of my life to public transportation. I was productive. I was present. I was happier at work than I had been in years.

And now, apparently, that was over. Not because anything had changed about the work. Just because someone decided it was time to come back — without understanding how the individual teams not only worked, but needed to work efficiently and effectively.

I want to ask that question out loud: why?

The Data Has an Answer. Leadership Won't Like It.

Owl Labs has been tracking how people work for ten years. Their 2026 State of Hybrid Work Report — now in its tenth annual edition — surveyed 2,000 full-time workers across the United States, and the findings are about as clear as workplace data gets.

If given the choice, nearly 1 in 2 workers (46%) say they would choose to work hybrid. Requiring employees to work in the office full-time is the top policy that would prevent workers from accepting a job offer — cited by 39% of respondents. And if those same workers were told they could no longer work remotely or hybrid, 41% would start looking for another job that offers more flexibility, and 6% would simply quit.

That is not a minor inconvenience. That is a retention crisis waiting to happen.

Workers themselves believe return-to-office policies are being driven by a desire to maintain leadership oversight and visibility (76%), improve productivity and collaboration (74%), and reinforce company culture (71%). But there's another reason on that list that deserves more attention than it typically gets: 63% of workers believe employers are requiring in-office work to justify office leases and real estate investments.

Half a century of office real estate doesn't justify disrupting a workforce that has demonstrated it can do the job from anywhere.

The Productivity Argument Doesn't Hold Up

The most common justification for return-to-office mandates is productivity. People aren't as productive at home. They're distracted. They're not collaborating. The work suffers.

The data says otherwise. 69% of managers say their teams have become more productive since adopting hybrid models, and workers who work remotely or hybrid report being more productive than their fully in-office counterparts. The clear productivity killer, according to the report, is the commute — with 86% of workers commuting up to 45 minutes one way, daily.

Think about what that means in practice. An hour and a half of a person's day, every day, spent getting to and from a building. That's time they're not working. That's time they're not with their families. That's time they're spending an average of $53 a day just to show up — on commuting, parking, breakfast, and lunch — compared to $20 a day when working from home.

You're not getting more productivity with a return-to-office mandate. You're getting more resentment.

Why Instructional Designers Are a Particular Case

I want to bring this back to our field specifically, because I think instructional designers are uniquely positioned in this conversation.

The work we do — needs analysis, content design, storyboarding, course development, evaluation planning — is almost entirely independent work. It requires focus, creativity, and the ability to think without constant interruption. The Owl Labs report found that 51% of workers say they work more independently and productively when remote, versus 30% who prefer doing solo work in the office, and about half say they think more creatively when working remotely.

That describes instructional design work almost perfectly.

The collaboration that our work does require — stakeholder meetings, SME interviews, review cycles, client check-ins — can happen in person when it genuinely benefits from being in person. Quarterly planning meetings, relationship-building sessions, onboarding. Those are the cases where an in-person presence adds something. Not the Tuesday afternoon when you're writing a storyboard for a compliance module and the only thing the open office plan is contributing is background noise.

The work doesn't care where it gets done. What matters is whether it gets done well.

The Return-to-Office Question Nobody Is Asking

Here's what I keep coming back to when I think about that former employer's mandate: what changed?

The work didn't change. The tools didn't change. The people didn't change. By every measure, the remote work model was functioning. And then, five years after it was implemented out of necessity, someone decided it was time to reverse it — not because of evidence, but because of preference. Because that's how it was done before. Because the building is there and it should be full.

The Owl Labs report found that 76% of workers believe return-to-office policies are being enforced because of traditional expectations — that's just "how it's always been done." Not because the data supports it. Not because productivity suffered. Because someone in a corner office decided that people should be in buildings again.

That is not a strategy. That is nostalgia dressed up as policy.

If you are an instructional designer — or any knowledge worker — working in a role that can be done effectively from anywhere, you have every right to ask why you are being required to come in. Ask what problem the mandate is solving. Ask what evidence supports the decision. Ask what the organization is measuring that would indicate the policy is working.

And if the answer is "because we said so," you have the data to push back.

Stagnant Skills and a Different Kind of Teacher

The Tool I Always Wanted to Learn. The Way I Finally Did.

For years, Photoshop sat on my computer like an indictment. I had bought the books. I had watched the YouTube tutorials. I had opened the application with good intentions more times than I can count. And every time, I hit the same wall — not because the concepts were beyond me, but because the tool itself is overwhelming in a way that is difficult to explain until you've experienced it.

Photoshop is extraordinarily powerful. That is also its problem. When you open it without knowing exactly what you're looking for, you are staring at an interface that offers you everything and explains nothing. The menus are deep. The panels multiply. The steps that seem like they should be simple — removing a background, creating a mask, isolating a single element from an image — require a specific sequence of actions in a specific location that no tutorial I ever found assumed I didn't already know where to start.

That last part is what consistently stopped me. The tutorials all began one step past where I was. They told me what to do once I was already there. Getting there was left as an exercise for the viewer.

I'll also say this in passing, because it's something I've mentioned to others: for a company whose tools are used professionally by designers and visual communicators, Adobe's interface has some of the worst accessibility I've encountered in professional software. Small text, low color contrast, a visual density that would be challenging for anyone with accessibility needs. At a moment when WCAG standards are gaining real traction and accessibility is finally being treated as a professional obligation rather than a nice-to-have, that's a strange gap to leave open.

The Difference a Different Teacher Made

A few months ago I started using Claude differently. Not for large tasks, but for small ones. Specific, bounded questions about specific steps in Photoshop. How do I remove an image background? How do I create a mask? How do I isolate this element so only the logo is visible?

The difference was immediate — and it came down to one thing I had specifically asked for: don't assume I know where to start. Tell me which menu to open. Tell me what to click first. Walk me through each step in sequence, from the beginning, without skipping the part where you tell me where to look.

That instruction changed everything. Suddenly the tool that had defeated me for years became navigable. Not easy, exactly. But navigable. I could get from where I was to where I needed to be, because someone — something — was finally telling me the whole path instead of the last half of it.

What started with Photoshop opened a door I hadn't expected. The same approach worked with Premiere Pro. I started asking simple questions — how do I even out the volume across a recording, how do I add closed captions, how do I compress video playback so it syncs better with narration. Simple things, asked one at a time, answered completely.

What I've Built Since Then

I want to be honest about where I started and where I am now, because the gap matters.

A few months ago I was producing basic talking-head videos with uneven audio and no captions. Now I can add a title card, on-screen animated text, and the Trident logo — and I can do it without having to ask for instructions every time. I've internalized enough of the process that the tool is starting to feel like mine.

That's the part I'm most proud of. Not the output, though the output has improved. The part where I stopped needing to be walked through every step. The part where the knowledge moved from the conversation into my hands.

This past week I've been learning how to split audio, add intentional silence, and give the viewer space to absorb what they're seeing before the narration continues. It's a small thing. It's also the kind of small thing that separates a video that feels considered from one that feels rushed.

What I Actually Think About All of This

I'm not writing this to make a case for AI. The debate about AI — its environmental cost, its effect on creative work, its implications for employment — is real and worth having. I'm not dismissing any of it.

What I am saying is that for me, personally, AI solved a problem that years of books and tutorials and good intentions never could. It met me where I was. It didn't assume I already knew the first step. It gave me a teacher that was patient enough to start at the beginning every single time I needed it to.

I spent years feeling like Photoshop and Premiere were tools I would always admire from a distance. I don't feel that way anymore. And the skills I've built over the past few months are mine now — not borrowed, not dependent on a prompt. Mine.

Don't let the tools you've always wanted to learn stay on the shelf because the learning curve felt too steep. The way in might be different than you expected.

After Articuland: A Cautious Take From Someone Who's Been Here Before

Last week, Articulate held Articuland — their largest user event of the year — and unveiled Nova and Frontline, their vision for the future of workplace learning. The L&D community has been processing it ever since. Two people I respect, Tim Slade and Diane Elkins, both weighed in publicly, and I want to add my perspective to that conversation — not to settle it, but to complicate it a little.

What Tim Said

Tim's take was direct: Storyline is dead. Not discontinued — dead in the sense that it has stopped being where the future of eLearning development is being built. He drew a parallel to Studio and Presenter, which Articulate never formally killed but which slowly faded from relevance after Storyline arrived in 2012. His argument is that Nova represents the same kind of shift — not a replacement, but a displacement.

I think Tim is right that this is the direction things are heading. I'm just not ready to put a timestamp on it.

Storyline will be around for the next few years — I'm confident of that. What I'm less confident about is what comes after that. We've seen this pattern from Articulate before. Studio and Presenter were slowly phased out through a gradual withdrawal of meaningful development, not a single announcement. We also watched Articulate effectively push its user base off of Storyline 3 by slowing updates to that version while continuing to develop Articulate 360 — making the choice to upgrade feel less like an option and more like an inevitability. Whether that same pattern plays out with Storyline depends on things none of us know yet — how quickly Nova and Frontline mature, how the market responds, and what Articulate decides to prioritize internally. I've been an Articulate customer since Storyline launched in 2012. I'm not ready to call it dead. But I'm watching.

What Diane Said

Diane's take was the one that resonated with me most, and I think it's worth amplifying. Her core point: most of what Articulate showed at Articuland already exists. Synthesia and HeyGen have been producing AI talking-head video for years. AI roleplay tools were on display at five different booths at ATD's conference in May. The ability to upload a document and convert it into a course has been available for two years. Articulate didn't invent any of this. What they did was say the quiet part out loud — that these tools are designed to put course creation in the hands of people who aren't instructional designers.

That's what rattled people. Not the technology. The statement.

Diane also made the point that matters most to me professionally: there is a significant portion of the instructional design process that Nova and Frontline did not show on stage. Where did those source documents come from? Were they accurate, current, and agreed upon before they were uploaded? Who conducted the needs analysis? Who facilitated the stakeholder meetings? Who will test the output for LMS compatibility, verify that it works with assistive technology, and ensure it meets accessibility standards? Who will manage the review cycles?

None of that appeared in the demo. Because none of that can be automated. Nova and Frontline can generate a very good first draft. They cannot job shadow a team, conduct interviews, identify the real performance gap, or do the messy human work that determines whether the training is solving the right problem in the first place.

My Own Caution

The headline version of my concerns is this: a few sentences of input is not enough to generate a truly meaningful interaction. It's enough to generate an interaction. Whether that interaction is purpose-built for what the learner actually needs to understand or practice is a different question, and one the keynote didn't answer.

I also have real questions about what happens when untrained subject matter experts are given full edit access to a learning experience an instructional designer built. Nova keeps the branding consistent automatically. It cannot keep the instructional integrity intact when someone who doesn't understand learning design makes changes to the content. The course can be perfectly on-brand and still teach the wrong thing. Consistent branding was never the risk.

Where I Land

I'm not ready to declare Storyline dead, and I'm not ready to declare Nova the future. What I am ready to say is this: the tools have been moving in this direction for years, and Articuland put a spotlight on something the industry had been able to partially look away from until now.

The parts of this job that Nova cannot do — the analysis, the stakeholder work, the accessibility review, the instructional judgment — those are where your value needs to live. Not in your ability to move rectangles around a Storyline slide. That part of the job has been getting easier for a decade. It's going to keep getting easier.

The tools are going to get better. That's not a prediction — it's already happening, and Articuland made that clearer than anything Articulate has said publicly in years. The question I keep coming back to isn't whether Nova and Frontline will change this industry. It's whether I — whether any of us — are doing the work now to be ready when they do. Because if there's one thing I've learned from watching Studio fade, watching Storyline 3 get quietly sidelined, and watching this keynote land the way it did, it's that the future in this industry doesn't announce itself with much warning. It just arrives. And the people who are ready are the ones who started preparing before it got there.

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‍