Continuing in this series of examples of tension in technical storytelling (part 1, part 2), I said previously that it's important to close the loop and release tension after you create it.
Because if you don't, it will eat at the learner, at best distracting them, and at worst causing them to disengage or leave a less-than-stellar review.
The hard part is that if you aren't paying attention, you may inadvertently introduce tension you never release.
While reviewing this same course on React, I left feedback on an open loop that was never closed.
Consider this React code:
export default async function Cart() {
const cartItems = cartService.getItems();
return (
/* JSX */
)
}
The clip I was reviewing used a snippet like this, and as a React dev, my thought the entire time was:
Why is the component async? And why isn't getItems
awaited?
Where there's an async
, there's usually an await
– otherwise, what is the point? If there is a point, it needs to be explained clearly.
Those questions were never answered, and I felt unsatisfied. We all feel this way when an open loop is never closed. Tension must be relieved. That's why it's called closure.
You don't want this to happen; catching these issues takes attention and empathy. Sometimes, as an expert, you miss obvious things like this, and while it's not your fault, it is your responsibility. Putting systems in place is an effective way to deal with this, which is why Pluralsight has the content review process.
But you don't have to get that sophisticated – simply putting your content in front of a beta audience is usually enough to catch the obvious stuff.
Just be ready because feedback won't come in the form of "I want less tension" or "Please create more tension." Learners don't know what tension is they just know how your content and delivery makes them feel. The feedback will come to you as "this is confusing" or "this goes too fast" or "boooooring". Really, all feedback can be traced to how you deploy tension if you look hard enough.
Have a lovely day,
Kamran