Organize!

Feb. 24th, 2009

Organization is important

Organization, in general, is a highly applicable skill for almost any job.  However, given the vast numbers of files, directories, and formats that developers and designers tend to work with, organization must be made an especially high priority for those professionals.  The lack of a defined project and resource filing structure can accumulate to hours of time wasted on a project spent sifting through documents to find what you’re needing.  Worse, your thoughts become disconnected in the space between search and valid result, further deteriorating your precious time.

In recent months I’ve had several opportunities to work on a variety of projects with a number of different companies.  One of the things that has been immediately noticeable to me are the ways that these different agencies do (and don’t) organize their work.  I’ve found some of them to be extremely easy to work with; others not so much. I thought I’d share a few scenarios I’ve experienced and give  examples of how I organize my files, tools, and other resources for quick retrieval. I’d like to start off by issuing a set of guidelines that I’ve found are helpful in organizing your work:

It’s OK to be OCD
Standarized file naming

Anal-retentiveness is an ideal personality trait for project resource organization. A mantra of “Everything must have its place” is extremely useful to keep running through your head. Everything needs to be in a folder, and you should probably even make folders for items that don’t exist yet if you know you’re going to need them in the future. Files need to have specific naming conventions for standardization, and certain file types should possibly be placed in specific folders (like CSS or JavaScript files).  Even your source documents, such as PSD or AI files, need to have their individual layers grouped and labeled in a manner appropriate to their contents.
Stick with it
A great organization system is awesome to have, but it means exactly jack if you don’t stick with it. Just like cleaning your house, storing your important financial documents, or organizing your music collection: you have to keep on top of it. This is probably the hardest part; you can make the organization system up as you go along and modify it on the fly, but if you don’t make a commitment to place your resources in their proper place… chaos ensues. It takes only a few extra seconds of your project time to drop your files in the right spot – it takes hours of extra time to go through and move your scattered files into their correct locations (not to mention the time you may have wasted up to that point looking for them for other projects).
Alphabetized isn’t always best
… sort of. A lot of firms use only alphabetical sorting to store their records. This can work in a lot of instances, but sometimes it is better to sort your information by date. Instead of placing your latest project for Anderson Ant Farms in the “A” folder, it may be better to create a parent folder of “2009″ and place your project folder inside it. This all depends on what your typical filing needs tend to be; just keep in mind that there are other methods beside your ABCs.
Make folders for project processes
Project process folders

It may be tempting to stop at just creating a folder for your project title and dumping everything into it. Making folders for specific segments of the project, however, can greatly improve your information retention and speed up your retrieval process. For instance, I create a “Bid”, “Source”, and “Proof” folder for every project that I do – regardless of what medium I’m working in. Documents, sample images, contracts, and other files related to the initial project dialogue with the client go into the “Bid” folder. My layout PSDs, AIs, stock images, or any other design phase project files go in the “Source” folder. Anything that I generate that goes to a client (apart from the final deliverable) is placed in the “Proof” folder, possibly in their own dated folders to facilitate a project timeline.

Scenario #1: E-Commerce Firm

My first job immediately out of college was as the lead (and only) designer for an e-commerce company. The company produced its own flagship shopping cart application and had a development department dedicated to customizations of their a la carte storefront solution and other random client requests. My job covered everything from product branding, to website updates, to custom designs, to server maintenance.

One of the biggest productivity hazards I encountered while working at this company was their total lack of a standardized filing system for project resources. The key term in this case is “standardized” as I quickly discovered that all of the developers in the department had their own methods of storing files – none of them in sync with any other worker. We used a centralized development server that hosted client preview sites for projects in addition to our project files for both active and archived documents, with every developer had access to
this environment for storing their files as they saw fit. Each developer had complete freedom to change and move the files located anywhere in our development environment. This quickly became a problem for our client test sites, when Developer A would set their files structure and Developer B would later go in and change it to something they felt was more efficient, almost certainly without Developer A’s knowledge. Eventually, the server ended up as a giant mish-mash of filing structures, inconsistent naming, lost files, orphaned projects, and accidentally-deleted archives.

The root cause of all this mayhem was a lack of guidelines from the department manager. Standards for file storage were consistently lacking from leadership, and as a result we engaged in an internal struggle of ideals. Had a set of standards been implemented for storage locales, naming conventions, etc., then the problems with file confusion and ego battles would most likely have been avoided. An acute case of having too many cooks spoiling the pot, with no guidance at all from a master chef.

Scenario #2: The Lone Design Firm

I was brought on to head up the web work for a small design firm that had most of its experience in branding, print, and multimedia production.  I was eager to jump in and start cranking out projects, as I knew the firm had worked itself into a backlog (which is a good problem to have) and needed some of the more basic orders tied up ASAP.  The firm had been the domain of a single designer, being totally responsible for all the visual work being produced and a large amount of the project management for the company as a whole.

My first project was something very simple: a business card.  Our web-related projects were all out for client approval, so it was determined this was something I could hammer out quickly and move on.  The business card was for a repeat client, who wanted to keep the majority of the artwork from their previous design, but needed some textual updates and wanted a little more jazz added in.  My first indication of a problematic situation was that upon entering the Clients folder, I found every project was filed under a clients name, formatted first then last.  This wasn’t a huge problem, but many projects are for a business and not for a single client, making surname ordering not only cumbersome but sometimes inappropriate.  Regardless, I sought out the folder for this client based on their last name.

The contents of the Doe, John folder were a mess to say the least.  Example folder names included “Temp”, “sample images”, “2008 Business Cards”, “Business Cards”, “[Name of Business]“, “[Name of Business] Print”, etc.  Based strictly on those options, the source PSD I’m looking for could be contained within any one of four different locations. “2008 Business Cards” seems to be fairly specific, so I head for that one.  Alas, this is incorrect as the client has had work done since 2008, and the droids I’m looking for actually end up being in the plain “Business Cards” folder.  By this point, I’ve wasted probably about 5 – 10 minutes.  Not a substantial amount, but you can already see how this can add up over the course of several days worth of work on multiple projects.

When I finally located the correct PSD, it was to discover that none of the layers within it were group in any sort of fashion or labeled anything other than the standard numerical progression of layer 1m, layer 2, layer 3, etc. that Photoshop produces every time you make a new layer.  I had to resort to toggling the visibility of every layer on and off to establish the location of each element and determine which ones I needed to work with.  After working on several other projects that yielded these same pitfalls, it was obvious that the lead and formely-only-designer had never expected that anyone else would need to get back into those files… ever.  A prime example of not only shortsitedness, but extremely bad organization as a result.

Scenario #3: Within A Framework

I was a part of a very large project to create an internationalized messaging system, one that would easily handle multiple languages, a variety of user presentation layers, and a high level of customization and ease of maintenance. To meet these requirements, it we used the Symfony PHP framework.

One of the mandates of using Symfony (and many other frameworks) is a very strict file structure. Files available for public access on the user presentation layer had to be placed here and CSS files needed for the backend admin section had to go there. The Symfony documentation was long, and extremely thorough, which presents a sharp learning
curve for first-time users. But once the proper placements are grasped, productivity goes way up and organization chaos goes way down.

For this particular project, several developers and their designer (me) had to work together on a tight schedule, all having different approaches to their workflows and methods. In this instance, using the defined locations of Symfony’s file structure, we were able to keep it together and avoid the constant issues with misunderstandings on resources and their levels of access.

Header Image Credit: tome213

Opinionated? (leave a reply)

  1. You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>