Clever title to be determined later

Is there some sort of weird IT meme in development out there? This past week, I’ve had two different people suggest using a praying mantis as a logo for their networking/programming business. I’m not so sure that’s the right angle for a couple of different reasons: mantids are only associated with computers because they are insects, and bugs are not a good thing in your system; the only other thing people know about mantids is that they get their heads ripped off after mating, and do you really want the phrase “rip off” associated with your business?

I’ve been doing a lot of reading on what goes into creating corporate identities lately, and it’s amazing the depths some people will get into when they are trying to pick themes/colors/icons/etc. I imagine a lot of that is influenced by programs like ISO 9000 and Six Sigma – where every single process is defined in respect to every other process. I’m not totally against that idea, as I’ve seen some really shitty corporate processes that could have benefited from at least a cursory look by an efficiency expert, but I think they go a little overboard with the belts and things.

Like any other process, it can be too easy to get caught up in the details – what exact shade of blue should be used and what quadrant of the logo should have gradients applied. These things can be important overall, sure, but I think a lot of Graphic Designers are overstating the importance of these details to satisfy their own inflated egos. The client’s desires are important, I’m not denying that, but a designer insisting that each project requires delving into their client’s every rationale for being in business strikes me as padding the account hours.

Maybe it’s because I’m first and foremost a writer, but the way I approach things is to determine overall impact first – what reaction do you want? – then break it down into its component parts. Sometimes a picture first, then a headline; sometimes the opposite. It seems easier to me to work backwards from the desired result to the components you have to build with. On the other hand, I may think that way because I learned early on how to rationalize and justify decisions in the face of critical design panels.

The map is not the territory. Except when it’s expected to be.

Remember that.