What if the designer gets hit by a truck?: wrangling digital design artifacts

On a design team, one major challenge is simply keeping track of the design artifacts generated by your designers. Whether you’re taking digital photos of a whiteboard or crafting ray-traced buttons in PhotoShop, a few weeks of visual design work can generate hundreds of files, making it difficult to keep track of what the current design is, let alone track progress and changes that have been made, or make sure that critical work isn’t lost.

Software engineers solve this kind of problem using source control systems (like CVS or Perforce) to track changes to files and attach metadata. This solution is so effective that it is ubiquitous in the software engineering world. So it makes sense to think that source control would be the answer for wrangling the disparate content of designers. Unfortunately, in my experience this doesn’t work. This has to do partly with how designers think, but mostly with how the design process works.
Source control works for software engineers because they are used to thinking very methodically about hierarchical classification (engineers in my previous company spent years arguing about the package structure that was used in the source files of the core product). Software engineers also don�t really produce that many files (typically no more than a few a day). The files software engineers product are unlikely to be deleted: chances are they will be included (in some evolved form) into the final product. And they are, at least at a gross level, easy to classify simply by file type: typically all the java code goes under src, all the database scripts go under sql, etc.
Visual designers are far less likely to spend time thinking about hierarchical classification of their own files (information architects are a different story, of course!). And the task is far harder for visual designers for a number of reasons. The number of files generated is far greater (designers often generate 100s of files in the course of a weeks work) and most files are temporary in nature (they will not be included in the final project). The files generated by a particular designer are typically all generated by the same tool, making gross classification by file type useless.
What is needed is some kind of a work process to bring order to this design chaos. Even if the chaos makes sense to the designers, what if the designer was hit by a truck (or hired by a competitor, or god forbid goes on vacation)? Getting the content into a source control system requires reducing the number of files and increasing their longevity. Since designers churn out 100s of temporary files of differing types, what is needed is a metafile of some kind that can be maintained and updated throughout the design process.
I�ve found that PowerPoint, of all things, is quite suitable for this purpose! A designer can paste the images for all the main screens or screen components from a design into a powerpoint file. Images from any tool (photos of a whiteboard, photoshop images etc) can be pasted into a powerpoint file. Annotation describing proposed behaviors / workflow can then be attached easily. As the screens evolve, the older, rougher images are replaced by the newer, more polished images.
The important thing is that many temporary files have been cooked down to one permanent file whose contents change over time. This allows you to easily save it into source control systems or share it with team members. Combined with a good file backup strategy (you have one of those, right?), and your ability to recover the loss of a team member has substantially increased.
Having a single document that holds the latest design artifacts also makes managing designers substantially easier, since everyone on the team knows where to go to see the latest design.
It also makes collaboration with business stakeholders _much_ easier (business stakeholders tend to be very comfortable working in PowerPoint, and will often edit the documents and mail them back to us with precise feedback, suggestions, and clarifications embedded into the document itself!).
How are you dealing with the issue of managing the files emitted by your designers? Can designers use source control effectively, or is it strictly the province of engineers? As always, feel free to comment in the space below.

3 thoughts on “What if the designer gets hit by a truck?: wrangling digital design artifacts

  1. Abdul Qabiz July 16, 2004 / 3:35 am

    Hi Jon,
    Its nice to see your blog. It has really good posts.

Comments are closed.