

For the past two years I have attended the Boston Drupal Design Camp at MIT. Understandably for a Drupal camp, most sessions focus on the technology but with a unique slant toward its use in the service of aesthetics.
I guess you could say it sprang from a movement that began at DrupalCon DC, where many designers gathered to set an agenda during the code sprint. I was a fly on the wall of that meeting and I saw many leaders voice concern that their presence within the community was undervalued.
As I sat down to an early session of the Design for Drupal Camp I could have sworn I recognized the presenter from that meeting in DC. Perhaps that is why I was a little disappointed. His presentation, “Design in the Browser: Use CSS to Stop Lying to Ourselves and Our Clients,” seemed to devalue the design process as I know it.
Basically, he suggested that designing in the browser with code, was preferable to using a graphics program to construct a simulation. The argument being that this would insure the design was producible, and that what the client saw during presentations was exactly what they would get. Literally, that the alternative was a lie.
While I agree that managing client expectations and insuring your concepts can be executed is a legitimate problem, I respectfully disagree with his proposed solution of designing in the browser.
To be clear, I don’t care what tools you use to communicate your designs to the client. Any program or technique will due as long as they don’t get in the way of your creativity. My problem with the browser is that it is a presentation/production environment, not a blue sky design tool. As such it diverts time away from exploring an array of ideas in favor of a single, dialed-in solution.
Giving clients a handful of relevant concepts to choose from provides them a meaningful opportunity to invest in their new brand. They know their business better than anyone, so having a chance to provide input on a deeper presentation will only inform the process. I should also add that when given this choice, clients rarely choose the first idea out of the gate.
It is not fair to call this technique a “Shotgun” approach as the speaker did (responding to me) during the question and answer period. This implies that the pursuit of multiple solutions at a conceptual stage is as reckless as birdshot. Rather, I think it simply acknowledges that the design process is not binary. Solutions are not purely right and wrong, but instead vary in their success and often draw from one and other.
If you want to manage client expectations about what is producible, try working with designers that are familiar with the limitations of the medium. Web designers should be no different than boat designers in the sense that we should design for our presentation/production environment, not in it. Designing a boat in water will yield the vessel that floats the fastest, but probably not the fastest vessel.
By all means, feel free to test, iterate, and revise in a browser, but when it comes to early stage design, choose tools that will accelerate your creative process. You won’t be lying to yourself or your client. You will be exploring the truth.