Designing for Drupal
Nica Lorbor, from Chapter Three, has a great post on their highly optimized Drupal design process. In the article, Nica shows how they start from a Drupal template that has roughly 25 common named elements (some native Drupal, some not) that can be styled according client specifications. A specialized Fireworks template calls out these elements and helps map them to a mockup to facilitate conversation between the designer and the developer. This creates a common language that binds the design to the code that the developer needs to work on. This also probably quickly identifies visual design elements that are not part of the normal Drupal/Chapter Three build, which need special consideration for estimation and budgeting.
I think the efficiency of this process supports my philosophy that you should work with a partner that specializes in the CMS that you intend to implement. Chapter Three didn't invent this methodology for their first Drupal implementation. I am sure that it evolved over time. It also speaks to the efficiency of designing with the platform in mind. With this process, everybody on the project (from designers to developers) understands what is going to be easy and what is going to be hard. Designers are guided towards concepts that are more efficient to build. Yes, you could build any design on Drupal, but that doesn't mean that you should. With some site designs, you will be fighting the natural tendencies of the platform: increasing both the implementation and maintenance costs.
I should probably make the point here that I am not implying that all Drupal sites (or sites from any other CMS) look alike - particularly to the untrained eye. Nearly all of what the casual site visitor notices (font, palette, page layout, buttons, etc.) is totally customizable in Drupal and any other CMS platform. Guessing what CMS was used involves much more subtle characteristics that you wouldn't notice unless you worked with the platform extensively.
This all raises a chicken and egg problem that I have discussed before. If the product influences the design and the design defines the requirements that drive the product selection, where do you start? As I mentioned in "When it is not all about the software," the key is knowing enough about your requirements to define a short list of options that you can evaluate on more subjective levels (such as aspects of design).