Last week, 37signals posts “Why we skip Photoshop” and seemingly every web designer working that day chimes in with “that’s cool for you, but” and defends pushing pixels in that aging beast as if it were a constitutional right. Looking over some of the responses, one thing becomes clear quick — you’ll have to pry Photoshop out of most designers’ “cold dead hands.”

Instead of siding with the crowd however, I just got annoyed that so many had seemingly missed the point. The original piece wasn’t about the entire design community walking away from Photoshop. Rather, it was about isolating a more efficient workflow for addressing application design. In the broad field of web design, where so many of us are expected to shift back and forth between “interactive print” design and true UI design work, I think we can forget how different these modes of design are, and how different the workflow needs to be.

Turn to page 138

Interface and application design is like a never-ending set of “choose your own adventure” endings — even the most basic programs end up with hundreds of views, each containing dozens of permutations of data and user input. This stands in contrast from designing non-applications on the web — the content and requirements are usually known upfront, in detail, and can be scoped in their entirety fairly easily.

Of course, it is possible to scope UI design work. It’s just that scoping and defining of requirements is such a large chunk of the work of any UI project, that the scoping really is the design itself — the choices to put what where, and how and why are design choices themselves.

Yet using Photoshop (or Illustrator, InDesign, etc) puts so many constraints on the flexibility of the design materials (no way to quickly swap in test data, quickly re-use design chrome and globally alter it, etc) that it can very easily slow down and halt progress as PSDs have to be mangled to cover all of the various views. I can’t tell you how many times I’ve been burned laying out a great comp in Photoshop, to have “edge data” (long names, long urls, unbroken text, etc) break an idea or grid. Getting things into code as soon as possible has always saved me headache.

Gradients before you walk

Also, it seems almost too obvious to point out, but using an image editing program to handle UI design is dangerous because it allows for far too much focus on the ‘appearance’ of an application, rather than it’s function. Form should follow, never lead. Forcing yourself to work in HTML and CSS means you’re more likely to actually build and consider those 10 contextual error pages, rather than loosing sleep refining rounded corners and slapping on gradients and transparencies.

It’s never one or the other

These choices, of course, aren’t binary — you can sketch something out on paper, get a few visual ideas hacked out in Photoshop, crank out some HTML, then pull that back into Photoshop for details, and push it right back to HTML again.

In the end, the way we work is a bit chaotic and insane, flopping back and forth between tools that never seem to be a perfect fit for what we’re doing. It’s just disappointing that we’re so protective of our workflows that we can’t open up a bit to some friendly advice. Just sayin’.