In this episode, I talk with Katie Cox, an instructional designer who has spent her career in customer education and now builds an entire product Academy as a team of one. We talk about what customer education actually means and how it differs from documentation, how she partners with technical writers and has them review every course before it ships, the skills that transfer if you're a tech writer thinking about making the pivot, and why feedback is a gift you shouldn't take personally.

—

Katie and I discuss her winding path into customer education, which started with a kinesiology degree, moved through a content editor role at an e-learning agency, and led to a Master's in education technology and her first customer education job at a software company with a pretty advanced program and a manager who became a formative mentor. We talk about what "customer education" actually means, why there's a push toward calling it "product education" instead, and how the content she builds gets used by customers, partners, and internal teams alike. Katie draws a clear line between learning content and documentation: people come to an Academy expecting to spend time learning, while people come to docs with a specific question and want out. That difference in expectations changes what you can ask of your audience and how you design the content.

A central thread of our conversation is how Katie's work and technical writing overlap in practice. She works out of her company's docs repo, repurposes screenshots and text from her technical writers so there's a single source of truth, and never releases a course without having a writer review it, because they know their topics well and they catch things. We dig into her approach to building courses: backwards design starting from learning objectives, a running scenario with fictional companies to anchor the content, and hands-on activities because people learn by doing. Katie is emphatic that clicks are not engagement, and that gating content behind forced interactions is the fastest way to lose a learner. As a team of one, she also pulls in colleagues to build courses using a template she created, which means she's used learning design to teach other people learning design.

We spend the second half on what it takes for a tech writer to move into instructional design. Katie, who has hired for these roles, says she'd hire a technical writer without hesitation, because the core skill of taking something complex and breaking it down is the same skill, and it's the thing she sees newcomers without that background struggle with most. The biggest difference she points to is scale: tech writers work page by page, while learning designers have to build a thread that runs through an entire course. We also cover whether you need a formal degree (she has one and learned more on the job), why the tooling matters less than the design thinking behind it, portfolio expectations and take-home assignments, and resources like Julie Dirksen's books, Cammy Bean's "The Accidental Instructional Designer," and the Customer Education Org Slack community. Katie closes with the best advice she's received: don't personalize it, because feedback is a gift.

Katie Cox is an instructional designer who loves learning about learning, providing engaging courses for life-long learners, developing relationships that allow the learning design process to come to life, and nerding out over process optimization. Great educational experiences make a difference in people’s lives, and she's all about making those experiences the best they can be.

Join the discussion by replying on Bluesky

—

We love hearing your ideas for episode topics, guests, or general feedback: