As designers who work with clients, we often concern ourselves with output; most of the apps we use are designed to produce it. We use Photoshop to create JPGs, GIFs, PNGs, and TIFs. Editing software like After Effects and Final Cut and 3D software like Cinema4D, Maya, and 3D Studio Max create MOVs and MP4s. Omnigraffle, Keynote, and Indesign make PDFs. And we optimize these files for presentation, whether that’s a deck targeted at our clients’ projector resolution or an asset with the right compression settings for a website.
Yet, I rarely see time spent on things that are never intended to be shown to a client. The purpose of these is to help facilitate internal process; nothing more. Though it seems counter-intuitive that spending more time on an extra artifact would make the process more efficient, I’ve saved large amounts of time working on process rather than output. I call these “invisible deliverables.” For me, invisible deliverables serve 3 main purposes:
One of my favorite invisible deliverables to start with is a layout framework. I love the existing layout frameworks like the 960 Grid System
, and YUI Grids CSS
, but often find that they’re too robust because they have to apply to everyone. Sometimes, I’ll strip those down and other times, I’ll rebuild a simpler version using the same principles. For me, grids that are too complex or granular defeat the purpose; instead of communicating organization and order, they look chaotic and random.
So I make my own, with a very limited scope… three to five options max. It’s a simple device to get all the designers on the team working from the same framework and all the developers to have a common construct. It eliminates variation among multiple designers, variation that’s annoying for developers and causes unnecessary time spent on correcting those anomalies.
A simple grid
Another great opportunity for invisible deliverables is to help simplify complex problems into digestible chunks. In “Always Beautiful
,” a recent project I worked on for Microsoft’s beta launch of IE9, we dynamically set graphics to the song “Already Got Me Sold” by recording artist Ming
. The type of graphics and interactions were determined by the song section—chorus, verse, bridge, etc—so we quickly made a color-coded song map. The song map acted as a cheat sheet and reference guide throughout the project so that we could focus on more important things.
A systematic way to visualize song sections
at Big Spaceship
To get around that, I’ll often prototype animation as part of my design process and as a communication tool. Flash may be dying
as an output format for creating full websites, but I still use it frequently (along with After Effects) as a prototyping instrument, even if the result will never be seen by anyone other than my team. If I have a specific idea for an animation style, I’ll create a SWF or an MOV than I can give along with PSDs to whomever is developing the site. That invisible deliverable of a motion test acts as a great reference to work from when actually building, regardless of language.
Time Spent Is Time Gained
Spending extra time on invisible deliverables is incredibly valuable. Process is the real battle on many projects; the output is just the documented results of that battle. Work on your invisible deliverables, and marvel at how much smoother your projects become.