I think you will save yourself a lot of grief too, if you start with a good base theme and extend it. I've used the blueprint theme, but any grid based theme would work well.

But, I think you're ignoring how much Drupal a designer needs to know in order to theme it. I also don't think the designer should assume that you start with a blank slate or that you won't have to accomodate module specific markup.

I think step 3 is a huge time-sink, so you're project schedule must accomdate the learning the designer will have to do.

And, while I prefer "back-end" coding to front-end/theming, I think you're punting on a hugely important skill to have.

Here you are describing a really simple project where one guy works as a developer and one as html-coder.

But if you have a bigger project with more programmers - then you will run into a problem of DB synchronisation between developers

Why?

Because having one DB for all developers is not secure, especially when you install another module (some modules kill other) - so if you don't know what you do - you can break the process of development.

Oscar: Absolutely. =) The best project I've worked on was when we had a designer/developer who could directly theme new forms, site features, and things like that, and who cleaned up the code I'd written while implementing the design of the previous designer (who really just handed us images and who had asked for things like image buttons for forms and lots of other effects).

Even in a large company, though, it takes time to develop a pool of people with skills like that. So a reasonable compromise is to have designers do the HTML and CSS (even if they're doing it from scratch because they don't want to mess with the PHP snippets in something like Zen). It's easy to find designers with experience in doing that. It's easier for me (and other developers) to figure out how to port the theme to Drupal (also theming forms and whatever else) rather than teach designers how to work with the Drupal theme system.

Front-end is hugely important, and it takes time and experience to do it well. I can do it in a pinch, but I don't love doing it, and I would prefer to manage project risk by bringing in someone who can do it well. I usually theme my custom modules a little bit to get them close to what the wireframes want, but I'm perfectly okay with letting someone else work out the IE6/IE7/Firefox/(...Chrome/Safari) issues while I build more functionality.

Konan: Totally! For teams larger than a single developer, you really should have version control. These staging and deployment tips have worked really well for us because we can form project teams with developers who are pretty comfortable with PHP, so we don't have to rely on the potentially messy side-effects of shipping database changes around. Putting all the significant changes in source code also enables code review and easy regression testing, too. Hope that helps!

Sacha, in reading your responses, I realized that what I was trying to articulate, and didn't do a very good job of it, was that you want a designer who's not necessarily familar with actual Drupal theming, although that helps, but one who is familiar with how Drupal works and some of the functionality it provides. Hence, my "don't assume you start with a blank slate" line.

Off the top off my head, they should be familiar with, or be told about,
* What elements Drupal adds to a teaser/body
* What kinds of layouts are easy, ie on a node template
* If using views, the built in display plugin (table, grid, list, etc) and how diff fields can be grouped/themed.
* Common page elements, and which are overridable or not, ie sear form, primary/secondary menus, footer elements that can be configured via theme, etc...

Such knowledge is particularly helpful so that proposed designs aren't too out-of-whack to implement based on a projects budget and schedule. And it'll minimize the number of "can-we-do-this" with Drupal questions as they are preparing the design. In an ideal world, it'll also prevent the "the-client-has-already-approved-it-so-you-have-to-build-it-like-this" disaster.

Oscar - Absolutely! Here are my preferences for designers to work with:

1. Designers who have actually built Drupal themes before, and can do the PHP.

2. Designers who have looked at Drupal themes before, and can think in terms of regions, panels, and other good things.

3. Designers who work with HTML and CSS, at least.

4. Designers who make fancy layered Photoshop files that are annoying to implement. ( fancy hover effects, rounded corners, etc.)

The more I can help people around me move up this list of skills, the happier I'm going to be during the development phase. =)

On the projects that I've been on, we don't let the clients even see the proposed design (or even wireframes) until the developers have reviewed it for feasibility. During this phase, we also figure out what we can do with existing modules we've worked with, existing modules we find but haven't tried, and custom code.