Visualizing the intangible

Lessons learned from creating an explainer video for a tech product

TL;DR

  1. Skipping vital stages of the explainer video process, especially storyboarding, doesn’t guarantee a quicker process, it might even make things take longer.
  2. Constantly challenge your assumptions on how to communicate ideas; consulting subject matter experts to ensure you’re delivering a focused, effective message.

The Challenge:

Cigital SecureAssist is an IDE plugin that gives software developers the ability to find and fix security flaws in their code when it matters most; as they’re coding, rather than later on during the testing phase when it’ll cost more. With a solid script in hand Cigital needed a video that perfectly explained how all that technology worked and why it was such a game-changer. Oh, and they needed it for a trade show they were attending in a matter of weeks.

So, no pressure.

Some preliminary notes and doodles I created during the kick-off call to make sure we understood the message the client wanted to deliver.

But wait there’s more

To add to the challenge, we were inheriting some baggage with this project. You see, Cigital had already started the process with another studio, but weren’t happy. Not because the animation quality was poor, far from it, rather due to the fact that they weren’t successfully visualizing the script according to the client. They were making graphic choices based on how “techy” they looked rather than actually translating the concepts of the script into visual forms. And this is a common mistake we see in explainer video land;

visual decisions made based on a surface or gut impressions of the subject matter rather than on a deep understanding of the ideas being communicated.

To make matters worse, they jumped straight to the animation stage without first doing storyboards thinking it would speed up the process. Considering the impending deadline this was understandable, but this move ended up accomplishing the opposite. It caused numerous project delays as the client wasn’t satisfied with how the studio was communicating key concepts and each round of revision took days to turn-around since they were spending time animating rather than simply adjusting static storyboards.


The beginning stages tend to look a bit rough. But these wouldn’t be sent to the client. This is just visually working through metaphors as quickly as possible.

The Solution:

Once we took over the project and had an in-depth kickoff call with the client, we went back to the drawing board (literally). We began by sketching out some metaphors addressing the main points of the script. For example, paramount to the setup of the story was showing insecure code being created and subsequently attacked. As usual, we explored these concepts verbally before playing with visual representations in some uber crude sketches.

Eventually, the doodles become sequences of doodles to play with how best to tell the story.

Once we had what we thought was a good sequence of visuals that accurately described the issue of insecure code, we created some initial storyboards in the style of the final piece. The initial story involved using a developer’s monitor with scrolling code as a backdrop. Then a file folder spitting out tattered looking file icons appears, but as they land, they are attacked by red lasers (pew pew) revealing security holes indicated by shields with exclamation marks.

The feedback to this approach in general was positive:

“Overall, the visualizations you came up with are outstanding! Again, I am very impressed with the creativity and clarity in communicating ideas and concepts in the visualizations. Very happy to be working with you on this project!

– Casey C, Cigital

But…

“The technical co-workers I solicited feedback from were all confused by the folder at the bottom of storyboard #2 ’producing software.’ They said they think of software as something that is produced along a software development ‘assembly line’ from ‘technically fancy components’ whose internals are opaque and confusing…”
– Casey C, Cigital

This feedback was vital in helping us change our perspective on how we depicted the fine art of software development, which subsequently improved the video. Files magically coming out of a file folder hid the magic that goes into crafting code and it’s this hard work that SecureAssist is trying to help developers with.

We regrouped and then changed the metaphor, using an industrial asembly line with robotic arms as the assembling mechanisms.

Despite what you’ve heard, building a piece of code isn’t a mechanical process… or so I learned.

Again the response was generally positive:

“So…this is really good. Very, very happy with what you have created and the additional modifications you have made based on earlier feedback.”
– Casey C, Cigital

But?…(you know it’s coming)…

“The way the application gets built is spot-on. The only issue my co-workers had was with the mechanical hands…they felt like it marginalizes software development as something a robot could do.”
– Casey C, Cigital

So where we landed was a more personal approach, actually depicting the developers as they added blocks of code to the software. See? Sometimes it pays to be straight-forward. Instead of trying to overthink the “developer” metaphor, the client responded best to simply depicting them as humans… go figure. But I at least got to keep the red lasers.

We still relied on the stereotype of the bespectacled developer, but the client didn’t seem to mind.

Literal vs Figurative

Another key idea they wanted to express was that other industries don’t wait until late in the manufacturing process to tack on security measures, so why should software developers? We originally chose to show examples of other products having security concerns dealt with early on in their production process as a way of contrasting it with the software process.

Blueprints, to me, are the universal symbol for “this is the planning stage”. To the client’s audience however, this made no sense. So it pays to always test your assumptions.

But eventually settled with demonstrating the completely hypothetical, but disastrous effects of trying to “bolt on” security at the end of various other product cycles.

Get it? “bolt on” security? #seewhatididthere

Linear vs Cyclical

One of the unique visualization challenges on this project was in illustrating the software development life cycle (SDLC), and differentiating it from the software development process so that the viewer wasn’t confused about which one was being discussed at the relevant times in the explainer video.

So the SDLC was shown as a linear progression; going from coding to release, while the development process was depicted as a cycle; repeatedly going through coding, compiling and debugging stages.

“It’s the Circle of cooode… and it moves us all”

Tying everything up

In an effort to parallel process, we had sent voice-over and music samples for the client to review while working on the initial draft of the storyboards. So once the script was approved, we had the VO talent secured and music track purchased.

By the time the storyboards were approved, we had all the audio in hand and were ready to start animation.

In the end, I think the animation turned out well, and more importantly the client was pleased.

“This is awesome! Absolutely love the video. The animation is outstanding, the music is good, and Paul’s voice over is great!”
– Casey C, Cigital