I have a new office mate. He’s a rubber duck. Yes, the cute yellow kind with the innocent smile. Here’s how that came to be.
The Problem
Earlier this week while working in Storyline 360 (a very robust course building tool), I was staring at a button and trying to determine why it wasn’t working. I wanted the button to behave in two different ways depending on input from the student but was failing. I was stumped.
Back Then
If only I had remembered a practice I learned long ago. In my very first role in online course development, I wrote out pseudo code when designing a lesson. I’d state what the student should see on screen initially, what types of input should be collected from the student, and what feedback the student should receive based on the inputs. The result was a precise set of instructions that would be implemented by a team of programmers.
It was an effective workflow. It forced the other course designers and me to state clearly what we wanted and to imagine every path the student could take through the content. The resulting instructions were easily proofed and reviewed by another designer for mistakes. And the programmers could implement the pseudo code efficiently and with little back and forth required.
Now
Fast forward more than a decade. The tools of online course development have evolved, meaning the roles and workflows have also changed. In many projects I work on these days, deciding what should happen and implementing this via a course building tool are no longer two separate roles even though they are very different skills.
In many ways, this is a good thing. The approachability of today’s tools means that building courses doesn’t require the extensive programming it did back when I started. And when fixes are needed, the same person who created the interaction can make the updates directly. But today’s roles and workflows blur the line between designing and implementing.
This blurred line is how I found myself staring at Storyline and grumbling audibly. Though I hadn’t realized it yet, I was trying to design a plan and implement it at the same time. I hadn’t paused to outline the role of the button and how its behavior should vary based on the students’ path through the material.
The Solution
I learned this week about a cousin of writing pseudo code called “rubber ducking.” In this technique, you imagine a rubber duck staring back at you. (Or better yet, you place one right on your desk!) Then, “...you explain what's happening step by step in your code, or on your Storyline timeline, to a rubber duck or some inanimate object on your desk. You just sit there and you describe what's happening.” (Safdie, K. H. (2020, February 27). Episode #25: eLearning Alchemist Podcast)
Aha! That is exactly what I had failed to do. I was trying to program the button without stating step by step what its two navigation paths were and how they differed.
The duck idea is so simple and yet so brilliant. You say in plain language to the duck what is supposed to happen. In forcing your brain to say out loud what is expected, you are likely to catch your mistake and pinpoint how to fix it.
So that’s how I came to have a rubber duck on my desk.
Oh, and that button that stumped me? It now works.
Comments