A Picture Tells 1,000 Words. So Why Do We Still Build Slides Full of Them?
Corporate training didn't start with PowerPoint. It started with transparencies on an overhead projector, and before that, a blackboard and whatever the instructor could write fast enough to keep up with their own mouth. When PowerPoint came along, it didn't change much about how we thought — it just gave the same analog slide a digital home, complete with basic graphics and timed builds to help the audience focus on whatever point was being made at that moment.
Somewhere in there, someone tried to fix the obvious problem — slides were getting overloaded, audiences were checking out — and the fix became a convention that got taught in every "effective presentations" workshop for the next couple of decades: 6x6. No more than six bullets per slide, no more than six words per bullet. The logic behind it made sense on paper — less text, less overload, easier for the presenter to keep slides clean and the audience to keep up. But the convention was built around managing text, not eliminating it. It assumed the fix for too many words was fewer words, when the actual problem was asking people to read at all.
Humans are genetically wired to recognize shapes, color, motion, and sound. That's not a training preference, that's neurology — it's older than language, older than written communication, older than the concept of a slide. Reading, on the other hand, is a learned skill. Nobody's born knowing how to do it. And yet here we are in 2026, still defaulting to slides that ask an audience to do the one thing they weren't built to do instinctively, while ignoring the things they were.
And that's before you even get to the audience members for whom reading isn't just unnatural, it's actively difficult — dyslexia and other reading-related differences that a text-heavy slide deck does nothing to accommodate and everything to punish. Do we really want to sit with what that means for how much of our training has quietly failed a portion of every room we've ever presented to?
Here's the deeper issue, and it's not really about slides at all. It's about which question we're answering when we build the course. Content-based design asks "what does the SME think the learner needs to know?" and then dumps that information onto slides because someone said it was important. We've known for years this doesn't work. We keep doing it anyway, because it's easier, because it's what the SME handed us, because turning a stack of documentation into bullet points feels like progress even when it isn't.
Learner-based design asks a different question: what does the learner actually need to experience to walk away able to do the job? Content comes second, not first. That shift — putting the learner's experience ahead of the content dump — is what lets you capture attention and tap into internal motivation, which will always outperform external motivation, no contest. It's what lets you actually engage the senses instead of just the eyes: color, shape, motion, sound, doing real instructional work instead of decorating a bullet list. The best courses aren't built by writing better bullets. They're built by not defaulting to bullets at all.
I saw this pattern up close working for a training consulting firm years ago. We'd write a 500-plus-page manual describing, in exhausting detail, exactly how a piece of facility equipment worked — every valve, every reading, every procedure, spelled out in prose. Then we'd copy and paste that same manual, section by section, straight into PowerPoint. Then we'd teach it. Two to three weeks per class, reading the manual back to the room one slide at a time, because that's what the deliverable had always looked like and nobody stopped to ask if it should.
Take three-phase AC power as the example, because I've watched both versions get taught. Version one is two hours of text-based lecture — slides full of definitions, phase angle explanations, voltage relationships, all of it technically accurate and none of it landing, because you're asking someone to build a mental picture of a rotating electromagnetic field entirely out of sentences. Version two is a single animated graphic: three sine waves, offset by 120 degrees, moving in real time, showing exactly how the phases relate to each other as they happen. The second one doesn't take two hours. It takes about thirty seconds to click, and it teaches the concept better than the lecture did, because it's finally speaking the language the brain showed up already knowing.
That's the whole argument, really. A picture tells a thousand words. We've had the saying for a hundred years and spent most of that time building training that argues with it anyway.
What My Colonoscopy Taught Me About Instructional Design
Yesterday was my third colonoscopy. I want that out of the way early, because it matters to the story — three times through this exact process, and it never once occurred to me that I was watching an ADDIE project play out in real time. Not until I was home eating my first meal in nearly 48 hours yesterday afternoon.
Let me explain.
The initial consult in the doctor's office, where we discussed my symptoms and agreed to performing the colonoscopy, is effectively the initial kickoff meeting with a potential client. Nothing happens yet. Nothing's built yet. It's just two people agreeing on what the project actually is before either of them commits to anything. Skip this meeting, or rush it, and everything downstream gets worse. Every ID who's ever built a course without a real kickoff already knows exactly where this is going.
Then comes the analysis phase, and if you've ever done a real needs analysis, you already know it's the worst part of the job. Everyone wants to skip straight to building. Nobody wants to sit in the discomfort of figuring out what's actually wrong before they start designing a solution. The prep for a colonoscopy is that discomfort made extremely, unambiguously literal. You are handed instructions. Specific instructions. Follow them exactly, in order, on schedule, or the data's no good and you're doing this again. And then you spend the next several hours doing what I can only describe as a series of increasingly urgent data-collection runs to the bathroom, each one somehow both identical to and worse than the last, until at some point you stop asking "am I done yet" and start asking "was I ever going to be done, or is this just the process now." That's every SME interview I've ever sat through, if I'm honest. You ask the same question four different ways because the first three answers didn't actually tell you anything. You think you're finished. You are not finished. Ask again.
Eventually — and only eventually — everything clears up. And I mean that in every sense the word offers. The analysis is done. The information's clean. You know what you're working with. You're ready to build.
I knew the colonoscopy itself was a relatively quick process, but I didn't know how quick the entire thing actually is. I was put under at 10:04 and woken up at 10:36. Thirty-two minutes, and I experienced approximately none of them. The scary part was never in the operating room. It was always the at-home prep. Likewise, the scary part is never working in PowerPoint or Storyline — it's always the analysis.
I think about how often I've watched that same pattern play out in a project that had nothing to do with a hospital. The build gets treated like the hard part, the part that needs the schedule padding, the part everyone braces for — when really, if the kickoff was honest and the analysis was actually finished instead of just declared finished, the build is the easy afternoon. The nurses prepping the room, running through checks, making sure everything's positioned right before the doctor ever walks in — that's your peer reviewers and your graphic designers, quietly doing the work that makes the actual event look effortless. The front desk scheduling everything, sending the reminders, making sure the right people show up on the right day with the right paperwork — that's your training coordinators and your LMS admins, and nothing happens without them either, even though nobody remembers to thank them afterward.
Three times through this exact process, and it took the third one to notice the pattern. Which either means I'm a slow learner, or it means some lessons only show up once you've sat with the discomfort long enough to actually recognize it. Possibly both.
AI Didn't Build My New Website. It Just Stopped Letting Me Pretend I Couldn't.
My website wasn't broken. That was almost the problem — it worked exactly as designed, and what it was designed to say was "I don't know what I'm doing." Nobody told me that. I had to figure it out myself, which either makes me perceptive or six months late to my own party. Probably both.
Here's the math I hadn't done: if my website — the thing housing my portfolio, the thing that exists specifically to convince someone to hire an instructional designer — felt lifeless and disengaging, why would anyone assume the eLearning I built for them would feel any different? I wouldn't make that leap of faith. I've sat through enough dead, disengaging training to know better than to bet on a stranger's promise that "no, really, my actual work is good, I swear." And I definitely wasn't clicking through to a portfolio page to find out, if the homepage had already told me everything I needed to know.
But say someone did make it that far — did go looking, did click through. What were they actually going to find? A three-minute video clip of an interactive Storyline course, published as a video. Not interactive. A video of interactive. Because I didn't know how to code, and Squarespace's block-and-template system will let you display a lot of things, but "let someone actually click through your interactive eLearning" isn't one of them. So the one piece of proof I had that I could build engaging, interactive learning was, itself, neither engaging nor interactive. That's not irony, that's just bad advertising.
And even that video only showed the last five feet of a much longer race. Most portfolios show the finished product — here's a course, look how polished. Mine did that too, and it was still incomplete, because building the course isn't the hard part and it isn't the part that separates a real practitioner from someone with six months of Storyline tutorials under their belt. A lot of people are moving into this field right now as developers, not as practitioners — they can build a course, but they've never run a full analysis, never figured out that the actual fix for a performance problem is sometimes a job aid or a process change and not a training module at all, never heard of Kirkpatrick Level 3 or Level 4 evaluation, let alone conducted one. None of that was showing up on my site either. I've done all of it. My portfolio needed to say so, and needed to show that I can do the things others either don't want to do or don't know how to do.
I learned this lesson in the Navy, over twenty years ago, long before I built truly interactive eLearning or even this website. After each watch, we'd do a daily area cleanup — and sometimes that first swipe of a chem-wipe sprayed with Simple Green showed you how dirty everything actually was. That first swipe was my portfolio. The area around it was the entire website.
The colors themselves were easy — I originally chose shades of blue and grey because I like them, because I'm most comfortable with them, because they speak to me. I wasn't about to change that. What I didn't have was the right shades — the specific tones that would make the palette feel alive instead of just present. So the colors stayed. The exact hex values didn't.
The navigation was uglier than I'd admitted to myself. Every individual page — contact, appointments, portfolio, the works — sat in the header as its own link, and it looked exactly like what it was: cluttered and dated. I built a collapsible side panel instead, one the viewer can show or hide, which sounds like a small fix until you realize how much visual noise disappeared the moment it existed.
Then there was the product-image problem, which I'd assumed for over a year was a Squarespace limitation — square crops cutting the tops and bottoms off portrait-oriented product photos. It wasn't a limitation. I just hadn't found the setting. Once I did, every product image on the site actually shows the entire product, which is a genuinely embarrassing thing to fix sixteen months in.
And then accessibility, which I'd said I took seriously, but didn't fully understand what that actually meant. It was a priority when rebuilding my site, and it's a priority now when I'm building eLearning. Every time I do something, I'm asking myself: is this appropriate color contrast, would someone who's color-blind still be able to distinguish what I'm showing them, do the closed captions actually line up to the audio script, are the alt-text labels accurate — and so on. That's not a question I asked once and closed out. It's a question I ask now, every time, and a check I run every time I create a new product or make a major change to an existing one.
Every one of these fixes followed the same pattern — I didn't know what I didn't know, until something forced me to find out. The exact shades. The crop settings. My own understanding of what accessibility actually required. Small on their own, but together they're the same lesson on repeat: you don't find the gap until you go looking.
Here's the part I actually want to be honest about: I knew I could do better. I'd known it for sixteen months. What I didn't have was the execution — the specific shades that would take the palette from dirty to clean, the interactivity and small subtle touches most visitors won't consciously notice but will feel, the ability to actually show the full breadth of what I do instead of one flat video clip standing in for all of it. AI didn't hand me any of that as a talent. It's not a talent. What it did was take the eye I already had — twenty-five years of knowing what good instructional design looks like — and let me finally build to it, instead of building to the limit of what I could code by hand. I knew what "better" looked like the entire time. AI is what let me stop just knowing it and start shipping it.
Learning to vibe code and using agentic AI to formalize processes and run routine analyses is helping me be a better instructional designer. Not because AI is doing the designing for me, but because it's enabling me to finally ask and answer a question I'd avoided for years: what have I been doing on autopilot, never once stopping to check if it could be done better? I doubt I'm the only one who's been coasting on habit somewhere without noticing.
To Thine Own Self Be True — And Other Advice From Someone Who Wasn't
"To thine own self be true."
— Polonius, Hamlet, Act I, Scene III
Here is the thing about that quote. Polonius is not a wise man. He is a scheming, manipulative courtier who spends most of Shakespeare's play meddling in affairs that are not his concern — and ends up dead behind a curtain for it. That famous line is part of a long, self-important farewell speech he delivers to his son before sending him off to Paris. Polonius himself is, famously, not true to himself throughout the entire play. Shakespeare almost certainly intended the irony.
And yet — the idea survived the messenger. Four hundred years later, we are still quoting it. Because the principle is sound, even when the person saying it isn't.
I knew I could not draw in junior high. It never kept me up at night, because I had other things going for me — writing, analysis, breaking down complex information and making it make sense to people who needed it to make sense. The fact that I could not put a pencil to paper and produce something recognizable was just a fact about me. Not a crisis.
Then I became an instructional designer. And that fact developed consequences.
For a long time, my workaround was human. Throughout my career I worked with graphic designers — some freelancers, some coworkers — who could take what I was seeing in my head and put it on screen in a format that was natural for learners. I knew what I needed and I could communicate it clearly. They could execute what I could not. The work was better for it, and I was not embarrassed by that arrangement. I was deliberate about it.
That is what knowing your weakness actually enables. Not embarrassment. Not paralysis. A decision.
What I did not anticipate was how the tools themselves would start to close the gap.
I am not an AI evangelist. I want to be clear about that. I am cautious, I am still learning, and I am aware that I do not know what I do not know. What I can say is that I did not adopt AI to replace my process. I adopted it to expand what my process could reach.
I still cannot draw. But I can now produce custom graphics using tools that did not exist five years ago. I can generate the kind of visual content that used to require a specialist — not because I became a designer, but because the technology changed what I could communicate and what I could build from that communication. I can write custom code for eLearning interactions without knowing how to code. I completed a full website refresh that I could not have executed on my own. The things I was never going to be good at — illustration, visual creation, front-end development — are no longer the hard stops they used to be.
And the things I have always been good at — analysis, curriculum structure, breaking down genuinely complex technical content, writing — those did not go anywhere. AI did not replace them. It sits alongside them. I bring the thinking. The tools help with the execution my hands could never quite catch up to.
That is worksharing. It just looks different than it used to.
Knowing yourself is not a one-time inventory. It is an ongoing practice — because the tools change, the industry changes, and what felt like a permanent ceiling a decade ago may not be one today. The wall I identified in a junior high art class is not as tall as it used to be. I did not get better at drawing. The landscape around the wall shifted.
That is worth paying attention to. Not because AI is the answer to everything — it is not — but because the honest question is not what am I bad at in some fixed, permanent sense. The honest question is what am I bad at right now, and what options do I actually have?
Those answers keep changing. Which means the self-assessment has to keep happening.
Know thyself. Your strengths and your weaknesses. Both. Clearly. Honestly. And then keep asking the question — because the answer will not stay still.
I Knew I Could Do Better — So I Did
I built my website about sixteen months ago. For the first several months, it did what I needed it to do. But somewhere around the six-to-nine month mark, I started noticing what it wasn't doing — and I couldn't un-see it. The template constraints, the image cropping, the layout limitations. It worked. It just didn't reflect the level of work I was actually delivering for clients. My plan was to hire a professional webmaster this year and have a properly coded site built from scratch. That was the plan.
Then I went to ATD ALC.
I attended a session where the ATD Chapter DEIB Committee walked through using generative AI to review governance documents — bylaws, policies, the kind of foundational text organizations don't look at critically very often. Sitting in the closing keynote later that day, I took photos of my notes and a colleague's notes and asked Claude to organize them, identify the key themes, and pull out the top three takeaways and action items for each of us. It did. Cleanly. Accurately. In minutes.
When I got home, I checked off one of my own action items and had Claude review our chapter's bylaws for bias and ableist language. The results were eye-opening. Then I pushed further — I pulled together CSVs of member data, non-member data, event attendance records — and asked Claude to tell me what we had never thought to ask about our own data. What came back surprised more than a few board members. We weren't missing data. We were missing questions.
That shift in thinking changed my approach to a lot of things. Including my website.
I need to give credit where it's due. Last November at DevLearn, I attended a session by Jeff Batt where he talked about using vibe coding and generative AI to build learning experiences and websites — without knowing how to code. It planted a seed. When Claude's vibe coding capabilities expanded this year, a lot of instructional designers immediately saw the eLearning applications. I also watched what Tim Slade was starting to do with it. Their work gave me permission to stop waiting for the "right" solution and start building.
Instead of hiring a webmaster, I used Claude to rebuild my Squarespace site — and the difference is significant. Visually, in how content is displayed, in how the site actually behaves. One of my specific frustrations had always been images being forced to fit template placeholders rather than the other way around. That's fixed. I also used Claude to ensure the site meets GDPR requirements and includes proper cookie disclosure options. GDPR is more restrictive than U.S. requirements — and I made that choice deliberately. If I'm going to hold myself out as someone who builds accessible, professionally sound learning experiences, I should be holding my own web presence to at least the same standard.
Speaking of which — accessibility. I can't, in good conscience, tell clients I build accessible eLearning while running a website that fails basic accessibility checks. I used Claude alongside an independent online accessibility scanner to audit the entire site, identified the issues, and had Claude help adjust the underlying code to bring it into compliance. High-level: it's done, it's cleaner, and it's something I can stand behind.
The one area still in progress is the portfolio — honestly, the section I was most dissatisfied with from the beginning. I'm rebuilding it this week using Claude, Articulate Storyline, Canva, and Adobe Firefly, with a focus on making it genuinely useful for potential clients while ensuring every sample in it is fully accessible.
The rest of the site? Take a look. I hope you're enjoying what you're seeing — because for the first time in a while, so am I.
Why "It's Obvious" Is a Design Failure
Special contribution by Stéphane Mousseau, Operational Clarity Architect and Founder of LIX™
The Most Expensive Phrase in the Workplace
"It's obvious." Most of us have heard it. Some of us have said it. A manager explaining a process. A subject matter expert reviewing a training program. A team member wondering why someone made a mistake. The assumption is always the same: If someone didn't understand, they simply weren't paying attention. But what if the opposite is true? What if "it's obvious" is often evidence that something wasn't designed clearly enough in the first place?
The Curse of Knowing
One of the most common challenges in learning, documentation, and process design is something psychologists call the Curse of Knowledge. Once we know something, it becomes incredibly difficult to remember what it feels like not to know it. The steps seem obvious. The terminology feels familiar. The expectations feel self-explanatory. As a result, we unintentionally design for people who already understand the system rather than those encountering it for the first time. This happens everywhere:
● SOPs that skip critical context
● Onboarding programs built around assumptions
● Training that explains concepts but not application
● Leaders who communicate expectations they never explicitly state
The expert sees clarity. The user experiences confusion.
Confusion Is Data
When employees ask repeated questions, organizations often see a performance problem. When learners make mistakes, they assume more training is needed. When new hires struggle, they add more coaching. Sometimes that's true. But often, confusion is data. It is feedback from the system. A signal that something intended to be clear was not actually understood. Every repeated question points to a potential design opportunity. Every recurring mistake reveals friction somewhere in the experience. The issue is not that people are failing. The issue is that the system is teaching them something different than what was intended.
The Hidden Cost of "Obvious"
Most organizations underestimate the cost of unclear communication. Not because the consequences are dramatic. Because they are distributed. A few minutes spent searching for information. A clarification email. A process completed incorrectly. A manager answering the same question for the tenth time. Individually, these seem insignificant. Collectively, they create what I often refer to as a clarity tax: a hidden operational cost paid every day. Work takes longer. Onboarding slows. Decision-making becomes inconsistent. Performance becomes dependent on tribal knowledge instead of reliable systems. The cost rarely appears on a financial statement. But it is paid nonetheless.
Why Some People Notice First
Interestingly, the people who identify clarity problems first are often neurodivergent employees. Not because they lack capability. Because they are often less willing, or less able, to fill in gaps with assumptions. Where others see: "It probably means this." They may ask: "What exactly does this mean?" That question is incredibly valuable. It exposes ambiguity that was already there. The same ambiguity many other employees are quietly navigating every day. This is one reason neuroinclusive design often benefits everyone. The friction existed all along. Some people simply felt it sooner.
Small Changes. Extraordinary Impact.
Organizations often search for large solutions to performance problems. More training. More oversight. More communication. More technology. Yet some of the highest-impact improvements come from surprisingly small changes. A clearer heading. A rewritten instruction. A visual example. A defined expectation. A checklist. A better-organized process. Individually, these adjustments appear minor. Collectively, they can transform how easily people learn, understand, and execute. Small changes. Extraordinary impact.
A Simple Test
The next time you hear someone say: "It's obvious." Pause. Ask a different question. Obvious to whom? The expert? The designer? The manager? Or the person encountering it for the first time? Because when understanding depends on prior knowledge, assumptions, or unwritten rules, the problem is rarely the person. More often than not, it is a design opportunity hiding in plain sight.
Making the Invisible Visible
One of the reasons I became fascinated with clarity is that these problems are rarely visible. Organizations can see the outcomes. They see mistakes. Questions. Delays. Rework. What they often cannot see is where the friction originates. That realization ultimately led me to create the LIX™ Clarity Snapshot. Not to evaluate people. To help identify hidden clarity gaps inside the systems people depend on every day. Because if a process only works when someone already knows the answer, it isn't truly clear. And if understanding depends on assumptions, "it's obvious" may be less of an explanation and more of a design failure. If you're curious about where hidden friction may be slowing performance inside your own documentation, onboarding materials, or workplace systems, you can explore the free Clarity
Snapshot at: https://lixlearning.com Because performance doesn't happen in a vacuum. It happens inside the systems we design. And when clarity improves, performance often follows.
—-----------------
Stéphane Mousseau is an Operational Clarity Architect, learning strategist, and founder of LIX™ Learning, where he helps organizations identify and remove hidden friction that impacts performance. Drawing on more than 20 years of experience in Learning & Development with organizations including Arc'teryx, lululemon, Aritzia, and MEC, Stéphane specializes in designing clearer documentation, learning experiences, and workplace systems that help people perform at their best. His work is rooted in a simple belief: many performance challenges are not people problems, but clarity problems. Through LIX™, he combines operational thinking, neuroinclusive design principles, and practical analysis tools to help organizations create environments where all minds can thrive. He is also the creator of the LIX™ Clarity Snapshot, an AI-powered tool that helps teams uncover hidden clarity and execution risks inside workplace documents in under a minute. Connect with Stéphane at lixlearning.com or follow him on LinkedIn.
www.linkedin.com/in/stephanemousseau
The Search That Started Bailey's eLearning Treats
Every instructional designer I know has hit the same wall. You are building a course, you get to the avatar selection stage, and you start searching. You need someone older. Someone with a visible disability. Someone in a wheelchair who looks like they work in an office, not a hospital. A person of color with a mobility aid. You search. You refine. You search again. What you find, if you find anything at all, are the same three images cycling through every stock library on the internet — clinical settings, passive poses, and a demographic range so narrow it would embarrass a 1987 corporate training video. After enough of those searches, most designers do what the deadline demands: they compromise. They grab what is available and move on. I did it too. For years.
The conversation I kept hearing in instructional design communities was not about accessibility — designers understand accessibility. It was about something quieter, but one with a simple solution: the near-total absence of realistic, working, living representations of the people who actually sit in our training. Not the idealized stock photo version of a workforce. The actual one — with the full range of ages, body compositions, ethnicities, gender identities, visible disabilities, personal expressions, and human variety that shows up in any real organization on any given day. I believed in that principle. I talked about it. I just had not held myself accountable to it. I had diverse avatars in my own work, but they were not necessarily representative of my actual audience. There is a difference between diverse and representative, and for a long time I let myself believe checking one box meant checking both.
That is when I stopped talking about the problem and started building the solution. I needed a place to go to find avatars that genuinely reflected the people sitting in the training — and when that place did not exist, I built it. That is what Bailey's eLearning Treats is. Not a stock photo library with a diversity filter applied as an afterthought. A catalog built gap-first — meaning the gaps in existing resources drove every character decision from the beginning. Who is missing? Who does the industry consistently fail to represent? Who does the instructional designer searching at 4pm before a deadline never find? Those are the characters I build. The catalog targets age range deliberately — not just the 28-year-old professional default, but characters across the full working lifespan. It targets body composition, personal appearance, and visible self-expression — tattoos, colored hair, the human variety that stock libraries still treat as edge cases. And it targets disability representation with specific intent, because this is where the gap is most severe and most consequential. Wheelchair users who are active professionals. Amputees. Characters with service animals. People whose visible difference is part of who they are, not the entire story the image is trying to tell.
The library comes in both photo-realistic and illustrated styles, because different courses, different organizations, and different design aesthetics call for different approaches. Both styles are built to the same standard: characters specific enough to feel real, diverse enough to reflect the actual workforce, and consistent enough across poses and expressions to carry a full course. A designer should be able to open Bailey's and find someone who looks like their learner — not approximate it, not settle for close enough, but actually find them. That is the benchmark every character in the catalog is built against.
The instructional design community talks constantly about putting the learner at the center. Representation is the most immediate, most visible, most concrete expression of that principle — and it starts before the first learning objective, before the first interaction, before the first word of content. It starts with who the learner sees on screen. I needed to hold myself accountable to that truth and be the change I was advocating. That accountability did not require a manifesto. It required building something. And I did.
Michael & Ishmael - One of Many Avatar Options