This is from 2012 | 6 minute read
File Management and the Pragmatics of Digital Work
I wrote, previously, that it's important to "...be extraordinarily diligent about file management. I maintain a rigid file structure of every document, artifact, presentation, and design deliverable, organized by client, project, project phase, and so on. When I enter a new context, I can immediately change my work space to ensure I'm ready to work; there's no searching for files, or locating old emails. It's just ready to go."I want to describe in more detail how this works.
Files
All of my files have a name that's extremely specific, and follows a pattern like this:
[client_project_artifact_version_initials.type]
So, I end up with files called AC4D_IDSE101_understandingFileNaming_03_jk.docx—this is a word document for Austin Center for Design, course IDSE101, about Understanding File Naming. It's the third version of the file, and since I touched it last, I add my initials.
Over time, you'll see how the files have changed:
AC4D_IDSE101_understandingFileNaming_DRAFT_01_jk.docx
AC4D_IDSE101_understandingFileNaming_DRAFT _02_mf.docx
AC4D_IDSE101_understandingFileNaming_03_ls.docx
AC4D_IDSE101_understandingFileNaming_04_mf.docx
This shows how multiple team members have worked on the same document, kicking it back and forth. The naming convention serves a few key purposes. First, when a file is emailed to someone else, they can instantly understand what it is. This removes the likelihood of an incorrect file being shared inadvertently. Additionally, it makes it clear which version is the most current, and who was responsible for the last set of changes. Finally, for the purposes of Getting Lots Of Things Done, the file name itself acts as a trigger for recall. A file that has a version number of 65 or 98 indicates that the project is well underway, and has been for some time; it signals "get in the mindset of details, and be prepared for discussions about minutia." A file with an early version number says "these are new ideas. People may not be on the same page as you." A file with initials from a junior designer says "You should probably look at this before you present it." A file with a name that contains DRAFT or EARLY EDIT says "Don't show this to a client." And so on.
If you work on a single project for a single client, and have a single role, this level of detail may not seem necessary, because you can remember the state of materials from day to day. But chances are, even if you work on a single file all day long, someone else in your organization doesn't, and will need this level of detail to make sense of whatever you are collaborating on. Do them a favor and start being more diligent in your file naming.
Folders
I have a projects folder, which is also a Dropbox folder: everything that is in it gets automatically backed up. Inside of that folder, I have a folder for each client, and inside of the client folder, a folder for each project. Anything on the desktop is transient working material. So, I end up with a structure that looks like this:
---AC4D
-------Classes
-------------IDSE101
-------------IDSE102
-------Students
-------Faculty
---Conferences
---Writing
The importance of the structure is that it maps to the actual organization of events in the day. I can roll into class to teach, and the process of (I am at AC4D) => (going to teach class) => (called IDSE102) allows me to quickly locate the material relevant for the activity. There's no hunting around for the right content; it's where it should be. This becomes extraordinarily important if you are working across multiple clients or multiple projects for a single client.
Inside of Files
Many types of files have a structural component inside of them. For example, a Word document has styles, that indicate Header levels [1, 2, 3], Paragraphs, and so on. You don't have to use them, and most people don't. But these aren't just conveniences: they predict the usage of the file for later, and help create a seamless workflow for the use of your material in other contexts. I think some designers aren't aware that their work is actually used in other contexts, and that it feeds a larger flow of work, but consider that after something's written in a Word document, it might be used in a layout program like InDesign, it might be pushed into an Excel document, cut and pasted into email, or act as the basis for HTML. Did you know that if you set up styles in Word properly, InDesign inherits them? Think about how much time that saves during layout. The larger point is that people will use your content after you are done with it, and so they should be able to open your files and navigate the material without requiring your in-person assistance.
The equivalent for most visualdesignersis the layer palette in Photoshop. When a designer is aware of how their work fuels a larger process, they go out of their way to name things in a coherent fashion. This mimics the file/folder structure of an operating system—it requires naming each layer, and each layer folder, appropriately. It acknowledges that other people will use your files. It's a courtesy, but it's also larger than that: it creates an opportunity to Get A Lot Of Things Done.
Team Expectations
Presuming you wanted to implement some of these simple ideas in your own teams, it will require a form of collaboration that isn't automatic and doesn't come naturally. You will need to tell your teammates how you expect them to work; if you don't tell them, they probably won't do it. This means that you set expectations at a kickoff meeting (literally writing on the whiteboard, for example, how you expect people to name their files, organize their materials, etc), and then reinforce this over and over. Want people to put their work on the server before they leave for the evening? You need to tell them. Expect your designers to label all button layers in Photoshop with a prefix "btn_"? You need to tell them. And more importantly, you need to show them by leading by example. When you start sending out materials, reinforce the expectation by practicing what you preach.
These things—files, folders, internal file organization, and setting team expectations—seem silly and trivial. They aren't. As long as files are the structural element of your work, these small details are part of the "measure twice, cut once" or "always clean off your workspace" of craftsmanship. They make you more productive, they indicate your respect for the medium and your co-workers, and they make life easier for everyone.
Originally posted on Tue, 15 May 2012