Let us speak plainly: Designers can turn a perfectly viable project idea into a convoluted, massively expensive train wreck before a single line of code is ever written. (There I said it, now the Emperor can put on a robe.) With the simple wave of a Photoshop wand designers can create design comps that lift a client's expectations to a web-gasmic crescendo only to later dash those dreams on the rocks of open source-hating despair as their project funds deplete and the development team begs for mercy, often long after the designer has left the project, doubtless adding insult to injury by implying it was the development team—or, worse yet, Drupal itself—that has failed.

Many times the designer even gets assistance, where said design is created and then used to birth a Frankenstein prototype, by passing the fantasy design to an HTML/CSS jockey who proceeds to "code up the interface" for the project without either of them having an inkling of what Drupal would output by default, all the while holding the expectation that the markup and CSS will simply be "worked into the theme down the road by the Drupal devs."

It is to this scenario that I send a message, a message I want you to repeat with me right now. So please stand up and go to the window (or Twitter, Facebook, etc) and yell in your most unrestrained voice (and preferably in your native tongue): "I'm mad as hell and I'm not going to take this anymore!" That's right, it's time for a change in the way we design.

I would venture a guess that anyone who has built a Drupal site has experienced some level of frustration with this design process. The old model of design and development silos just don't seem to work when it comes to Drupal (or anything else honestly). Having a visual designer—with no knowledge of Drupal—create comps which get sent out with an RFP for a project bid ends up with a budget-busting project that leaves a bad taste in the mouth of the designer, the developers, and worst of all, the client. With this in mind let's see if this article can be a stepping stone to changing the way designers think about and work with Drupal, and how clients approach a new Drupal project while still in the early stages.

Turn This Ship Around

What we need is new thinking about what it means to be a designer and the role design plays in a project. The most direct route to turning this ship can be based on a handful of basic premises about how to cultivate a new kind of designer:

1. The Hybrid Designer: The designer must acquire a more complete set of skills.
   To successfully bridge the gap between the client's vision and the development team's efforts requires a hybrid set of cross-disciplinary skills (outlined below) that allows the designer to move between the abstract world of client dreams and the concrete world of module selection, theming, and custom development. The old approach of silo-encased design teams split into visual design, information design, user experience, front end coding and back-end development is dead. Just think of each of these silos as yet another chasm for the delicate details of your project to fall into and never return. Hybrid designers can fill various levels of each of these roles and carry the details straight through to the development team and back again.
2. The Framework: The designer has a fundamental responsibility to understand the framework (in this case Drupal) that is being used to develop the project.
   This cannot be overstated and is continually the source of amazement when considering how many projects drudge through their existence with a designer having no idea what the framework would be when they designed a complex pixel-exact solution for the client. This is a terrible failing of the design community that is rarely tolerated in any other design related industry. Imagine an architect designing your custom home with no idea what materials will be used, what climate you will live in, or even where the build site is.
3. Paired Design/Development:

The designer must be paired with an experienced and user-oriented developer from start to finish and this pairing should be included in all decisive stakeholder meetings.
An experienced Drupal developer can keep a designer on course when new or custom interactions or design patterns are needed in a project. Being able to discuss build approaches, configuration changes, or deeper, more complex theming issues with a developer can save weeks of time where more traditional approaches require new comps and more meetings. An added benefit: this pairing increases the knowledge of the designer about programming and the developer's knowledge of design practices. Cross-training at it's finest. The pairing can rapidly iterate through wire-frames and screen shares to suss out solutions in hours instead of days, and talk in terms of feasibility and real effort estimates. When present at meetings, the pair can quickly discuss real world options based on the client feedback and present practical next steps. From the other side, when developers run into unforeseen interface challenges or new screens, the designer is right there to work through best options. We all know how sites end up when developers are forced to design solutions because the designer is long gone. You can basically pick the screens or page elements in a given Drupal site that the designer didn't account for and that required the developers to finish on their own.

Specific Skills a Hybrid Designer Needs

Here is the short list of skills the designer needs to cultivate:

• Practical experience. Knowledge of principles with visual design, user experience design, information design, and overall feature design. These disciplines (though called by many names) are interconnected and are all required reading and practice.
• Strong client communication skills. This means the ability to suss out the client's vision and clearly define their needs and expectations. That responsibility is much more effectively accomplished by the designer/developer pairing in client meetings than by a project manager (or worse yet a sales rep) for a given development shop. Setting client expectations properly can be the difference between happy repeat customers and burned bridges.
• Rapid wire-framing skills of some kind. This plays to communication skills and is invaluable when trying to discuss ideas in a group. It doesn't have to be fancy; it can be as simple as paper and pencil, or something as elegant as Adobe Fireworks, and can even go as far as encouraging clients and stakeholders to exchange wire-framing ideas themselves. Though those ideas may appear messy or convoluted, they always aid in conveying the vision the client has for their project and can serve as a starting point for better iterations on the design. This doesn't mean the client designs the project, it just serves as a more direct route to understanding their needs and desires.
• Real world HTML, CSS, PHP, JQuery and Drupal theming skills. Basic skills here are a must but the more advanced the better. Contrary to some designers' strongly held beliefs, understanding the constraints of a framework, device, and/or browser is essential to effectively design for them. Anyone who has ever had to code (or pay for) pixel-exact, roundy-corner-drop-shadowy-eyecandy for Internet Explorer 6.x will testify to the cost and pain here. Being able to design for the graceful degrading of features, and to properly set expectations for various devices/browsers can create huge cost savings.
• Drupal site configuration skills. Knowing how to create a content type or setup basic views requires a designer to understand the mechanics of how core elements like content types, views, blocks, etc, are constructed and used and can enhance the understanding of how these elements can be designed for and used out of the box. Better yet: just use Drupal to rapidly prototype design ideas before submitting comps to the client, and know the options being provided are sound.
• A sense of humor and flexibility. I just had to throw that in because if a designer doesn't have a sense of humor working with all this stuff than please just stay home! I have worked with too many designers who think their designs are "works of art" and should not be modified at any cost. Designing for the web is not finger painting pictures for mom's refrigerator, it is designing for elegance, pragmatism, usefulness, and evolving requirements—so lighten up and let the design process flex.

A New Designer Mantra

"Theming is overriding" is the mantra of experienced Drupal theme developers (themers) and essentially means every chunk of data coming out of Drupal, every block and piece of markup Drupal outputs, has some form of default theme markup applied to it. These default markup decisions are also the hooks that allow themers to override and change the markup before it is rendered. Drupal 7 has taken this concept further by making every effort to bubble up un-rendered data (render-able arrays) to the very surface of the theme layer to give themers as much control as possible over the final markup. This also applies to CSS, allowing default CSS to be overridden or excluded entirely, to be replaced with custom styles. This creates the ever-present choice of accepting the default markup from Drupal for a given feature or overriding it to make it your own. Once folks new to Drupal grasp this concept much of the learning curve starts to smooth out.

The same concept of "overriding" can be extended all the way back to the beginning, into the hands of the properly prepared designer with a new mantra: "Designing for Drupal is overriding (when possible)." The designer who learns about the Drupal theming process and has even a basic grasp of how to evaluate new modules can begin thinking of functionality and user interactions as building blocks to override. Drupal then offers that savvy designer a vast palette of user interactions and functionality out of the box that can be leveraged to get the most mileage out of the framework with the least amount of effort and cost.

Choices

With the tools listed above firmly in hand, standing shoulder to shoulder with a paired developer, the designer can now step up and offer practical choices to the client in relation to cost and effort. Understanding what can be overridden or massaged into place with a little effort and what truly needs custom development (and is worth the cost), becomes the crowning glory of designing for Drupal. The designer/developer pair becomes the leverage point for the Judo Flip of getting every last ounce of "free software" out of Drupal before needing to build something custom. The team offers real choices to clients for making cost-critical decisions about where the project needs custom modules and custom interactions and where working with existing patterns will suffice.

A good example of this is deciding to build a custom mega-menu navigation for a site that is too deep or complex for simple Drupal menus. This is design and customization for the sake of elegance, pragmatism, and usability and well worth the cost of development, the added benefits of which can easily be demonstrated as such to the client.

Put it into practice

Get hands on. Install and evaluate what Drupal and other contrib modules can do out of the box for a given feature before re-inventing the wheel. Dig into the source code, rendered page source, etc and see what raw materials are available.

Be the designer who can implement what you design! Learn and work with HTML/CSS and the Drupal theme layer so you are designing things that can be built. (That sounds so strange to have to say but I have seen too many cases where designers have no clue how their drawings will be built.)

Wire-frame concepts and discuss ideas with a paired developer through the project life cycle and use Drupal for rapid prototyping to prove out ideas before presenting them to clients.

Call out the key decision points for clients when choosing between customizing or using existing code. (I promise they will love you for it.)

Recognize the challenge. Instead of complaining about a framework like Drupal, recognize that a true designer is one who understands the boundaries and constraints of a system and can then bend those constraints to his/her will when needed. "These rules are no different than the rules of a computer system, some of them can be bent, others can be broken... understand?" -- Morpheus

Public Service Announcement

If you are about to start a project or are in the middle of a project as you read this, and your designer doesn't understand Drupal with some level of the detail discussed herein, please do yourself a favor and stop for a moment. Talk to your development team and see if anyone knows of a designer who has these qualifications and might be available to consult. It doesn't matter how fancy the marketing agency office lobby is, or how flashy the designer's portfolio; if the designer doesn't understand Drupal and is designing comps that your developers will be tasked to build, that designer is going to cost you heaps of money. If you are a company out there lucky enough to have this new hybrid designer on staff (or a designer that has the desire to cultivate these skills) please know you have someone of great value to your team. Pay them appropriately, for the day will soon come when the hungry masses will be knocking on your door with offerings of gold, frankincense, and myrrh.