Storytelling and Software
Storytelling can grow an idea into something greater.
One of my favorite YouTube channels of late has been Film Courage. It’s a repository of longform interviews with creative writers and creators surrounding the film industry, writing, script writing, screenplays, and story. It is a treasure.
In an interview with Glen Gers, he presents the 6 elements of any story that I love for its clarity of purpose.
What I find so useful for storytelling as a mental model for software is really about how you have to focus on characters. People. It’s easy to forget that we typically create software for other people to solve problems. For many, software is something we use every day, for better or worse. Our complaints about software are legion and growing. Why not use that energy as a way of problem solving for new things?
Software is designed by people with goals.
If you squint, this can map to the idea of a protagonist and opposition toward a particular goal your software helps them achieve it.
Every person who uses your application has a goal. Every one. Curiosity is a stellar goal if you can cultivate it, but in a lot of our cases we typically have some kind of narrative we’ve already communicated to those people on what the software is supposed to do. If you’ve never done this before, this article is for you.
If you are building a video game, your narrative is your game. If you’re building accounting software? Your narrative is just as important even if it seems unclear or impossible to define.
Here’s the six storytelling questions take from the video above:
who is it about?
what do they want?
why can’t they get it?
what do they do about that?
why doesn’t that work?
how does it end?
These questions help you build anything from a video game, to accounting software, to a social network. This works particularly well for improving existing software and refactoring.
Adapting the above list for software is generally like so:
Who is your software for?
Why do they want your software?
Why is your software right for what they want to do?
Which software do they already use that your software improves?
How does your software replace their existing software?
How do you communicate this to them?
In product development circles, this is similar to a process of user personas, however personas are about telling multiple stories from unique perspectives and I would warn you not to start out your storytelling by going straight to Tarantino or Nolan. Keep things simple to start with. What is the main character, and what are their goals?
What’s important here is that you focus on only answering one question at a time. Each of these questions will help you organize and focus on the one thing your software does that makes it different than something that already exists.
Maybe you focus on performance with a complex, resource intensive task. Maybe your focus is on accessibility, or power users. It doesn’t matter what it is, but it does matter. If you aren’t able to tell someone a story using this device, this could be a red flag that your work might be too derivative. That’s not a bad thing in some cases, but what we’re interested in is new or innovative derivatives.
Lets see how this works with a specific example.
Example: Figma’s Software Story
Who is your software for?
Mallory is a graphic designer, who is working for an agency that hasn’t updated their tools or processes for delivering great designs in a decade.
Why do they want your software?
Part of Mal’s plan to get promoted is to utilize Figma — a multiplayer design tool for applications and the web — that allows her access to necessary tools like rapid prototyping, whiteboards, and collaborative reviewing her team needs to remove all the manual labor of saving revisions, shipping sketch or PSD files, and having to hold meetings for reviews.
Why is your software right for what they want to do?
Figma focuses on performance, though you wouldn’t know it by looking. Their web based editor is implemented with WebAssembly, and absolutely screams at top speed while working with large, complex projects. Their desktop app is functionally identical to the web based one, and only has some extra features — which are free — to handle fonts better and handle exporting assets easier.
Which software do they already use that your software improves?
Today, the agency utilizes a mixture of Photoshop, Sketch, and Dropbox. This works well enough, but the team complains often about how much time is spent shuffling files around, resolving sync conflicts, permission settings, and other technical time-wasters. Figma is entirely cloud based, and it exports to commonly useful file formats for the engineering team — well compressed PNGs, speedy and uncomplicated SVG files, and even supports modern web development tooling like Tailwind CSS.
Building great systems is a process of asking questions.
How does your software replace their existing software?
There are 10 years of archives from existing projects the agency has shipped for clients, and Figma reads similar formats like Sketch just fine. Photoshop isn’t going away any time soon, so PSD files can stay on a dedicated backup should they ever be needed. Mal realizes that the software Figma completely replaces isn’t Photoshop, but Sketch and Dropbox.
How do you communicate this to them?
Mal heard about Figma from a colleague at her last job. She had dabbled with it for a while and liked it, but couldn’t get her old boss to buy in to the change management of a tool change mid project.
One of the ways she presented the abilities of Figma to her team was within Figma itself; building example scenarios within Figma’s prototyping toolset, and showing how a mistake could be modified and republished within seconds, rather than minutes or a half an hour. This got the team curious and a long discussion followed along with some notes for a timeline and a couple milestones.
One of my most useful procedural tactics to prime my brain to think about a problem is to explain an existing service through this format of narrative structure. I try to eliminate jargon where necessary, and speak as clearly as I’m able about the problem that exists, and how the character changes based on some particular goal.
What are you certain of when it comes to your users goals? How are you evaluating the ways in which you are becoming a blocker for their goals? How can you change that?
Storytelling isn’t just a sales tactic, it’s a mental model for developing on the fly. I’m not arguing that this is the right method for all software, but by rooting ourselves in people and their goals, we are better positioned to empathize with them. Steve Jobs was a pro at this, although in a way we take for granted, I think. Jobs had a gift for simplification.
Famously, when confronted by a software developer upset over a decision Apple made, he explains this great story: The most important thing the LaserWriter did was print a gorgeous picture. You didn’t need complex storytelling to get people excited; you could just show them a print and ask, “Do you want this?”
When your product is so good that you don’t have to explain what’s in the box — the great software it has, the complex drivers and mechanics — its much easier to get them excited.
Storytelling is how that starts. It’s not a polish you put on existing software, it is a mechanism for the growth of an idea. It’s scaling. By telling stories, we’re reifying an idea, little by little, until you don’t need it anymore to get people excited.
Happy New Year, folks.
(throw me a tweet if I should do more posts about ideation and creativity. I’m probably going to anyway, but I need the engagement for validation. tia. -L)