STAR: A Technical Storytelling Framework

A while back I was helping a company put together a customer case study video. Their customer had agreed to take part (which is always a win), but the solution being showcased was a genuinely complex data platform. Easy to explain badly. Very easy to lose people in ten seconds flat.

Before we touched a camera, I sat down with the customer over a cuppa and asked a load of questions, They weren't random questions, they were structured, deliberate questions, mapped straight onto STAR.

Situation: what was the challenge, what was the pain before this?
Target: what were you trying to achieve, and why did that matter?
Action: what did you actually do, and how did you do it?
Result: what happened? What changed?

I took the answers and turned them into a script, written in plain English, structured around STAR, then loaded onto a teleprompter. I filmed the customer with my posh camera, lights and mics.

What came out the other end was a case study that was clear, tight and genuinely compelling. All built on a framework most people only associate with dreading the words "tell me about a time when."

What STAR Actually Is

STAR gets taught almost exclusively as an interview technique. Situation, Task, Action, Result. You use it to answer competency questions and hope the interviewer ticks the right box.

That's a shame, because it's a really clean structure for telling any technical story. Not because it's especially clever. But because it forces you to include the parts people actually need, in an order that makes sense.

Situation sets the scene. What was going on, what was the challenge or the opportunity.

Target is the destination. What the customer, or your team, was trying to achieve, and why it mattered.

Action is the journey. What you did, how you did it, the choices you made along the way.

Result is where it landed. What changed, what improved, what's true now that wasn't true before.

Why It Works So Well for Technical Storytelling

Complex technical work has a habit of turning into a feature list if you're not careful. A demo becomes a tour of the interface. A case study becomes a spec sheet with a customer logo stuck on it. STAR stops that happening because it forces a narrative shape onto the content. Your audience isn't just being told what the product does, they're being taken through a real situation with a beginning, a middle and an end.

It also scales really well. The same four sections fit a two minute video, a written case study on your site, or the answer you give a prospect in a meeting when they ask "has anyone else had this problem?"

How to Use It Yourself

• Ask questions before you write anything. Interview the customer, the colleague, or yourself if it's your own story.
• Structure the answers around STAR before you touch a script or a slide. 
• Put them in plain English.  Get rid of all the jargon.
• Resist the urge to lead with the result. The Situation and Target are what make the Result mean something. Save it for the end.
• Keep it tight. A good STAR story can run under two minutes told out loud.

I use frameworks like STAR constantly with the technical professionals I coach in Pre-Sales, Consulting and Customer Success teams.  Getting the stories can be hard enough,  but once you've got one,  knowing how to structure it is vital.

If you want more on using a teleprompter (which I use all the time)  check out using a teleprompter to create professional video content quickly.

Want help building this into how your team communicates? Take a look at the Technical Storytelling Program for Individuals.

Ben