Subtraction.com

The Problem with Photoshop

After trying many times to regulate the manner in which Web site production is organized on the many design teams I’ve led, I’m still not at peace with the amount of control that should be imposed on other designers. On the one hand, everyone works in a unique manner, and it’s counter-productive to shoehorn a single, unified and overly detailed process on designers, who are typically free-thinkers when it comes to this working style. This I accept readily, but there are some things, admittedly low-level things, that I find it hard not to at least want to control.

There are more profound — and touchier — examples than this, but the one that has me preoccupied lately is the relatively trivial matter of organizing Photoshop documents. By and large, most designers approach the construction of a Photoshop document in an ad hoc manner, creating new layers as they are needed, not always naming them properly, or defaulting to Photoshop’s automated, serial numbering scheme, which happens to be generally devoid of meaning. I’d venture to guess that the vast majority of Photoshop documents are created in this way, and more often than not without negative consequence.

Photoshop in Production Shops

Below: Photoshop cruft. A more or less typical combination of named and unnamed layers in a Photoshop document. And yes, I’m still using an older version of the program.

But when working in a production environment, there’s a lot to be said for being highly organized with the constituent parts of these files: the application is far from an ideal tool for Web site production to begin with, and the natural (and completely understandable) cruft of redundant, obsolete and/or superfluous layers generated by a designer over the life span of a production document can exacerbate an already difficult process. Add two or three or more designers to the mix — everyone adding, obsolescing and altering layers with no overarching mindfulness of the document’s construction, and you end up with a structural mess.

I’ve toyed with the idea of putting in place fairly strict guidelines around the creation and management of these documents for what might generously be called “the greater good” of a project. Specifically: there should be as few layers as possible (especially among text layers), all layers should receive unique and logical names (completely eschewing Photoshop’s default “copy” appendage to duplicated layers), obsolete layers should be deleted, etc.

The Wrong Tool for the Wrong Job

They’re simple enough rules, in my mind, but they’re open to a lot of interpretation — how many layers are too many or too few? what exactly is a logical name? — and trying to impose them is more or less committing to a path of micro-management. It’s true that design production is a kind of micro-management to begin with, but it occurs to me that what’s really lacking here isn’t so much a unified mindset for production teams, but rather a truly flexible visualization tool for Web production.

I’ll never deny Photoshop’s raw and unparalleled power in rendering singular concepts, but it’s starting to become a real liability when it comes to communicating interactivity, as the thorny problem of layers management indicates. To be fair though, what I’m saying is that Photoshop is just the wrong tool for the job. But short of actually coding the final experience — which some would argue is the simplest, best solution — there remains a huge opportunity gap for a new kind of software tool. I know, I’ve talked about this before, and there’s almost nothing new I’m adding to the argument now. Basically, I just want to reiterate: I want a new production tool.

+