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:
- 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.
- 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.
- 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.
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.
Hi Jeffrey, thanks for sharing your insights with us! I have a UX/Design and Development background myself and I can see your point. I too see some serious projects take off with a marketing driven designs based on a mosaic of fancy call-to-actions combined with carrousel galore. I am all for the involvement of designers and developers from day 1 and I agree 100% that a broad knowledge of Drupal workings, will improve Drupal designs and align client expectations to bring them in balance with Drupal's possibilities, or any framework for that matter. Having a hybrid designer will surely work for any Drupal project. If you can find them. For as much as you would value a designer with HTML, jQuery and PHP skills to have on your team, can you expect the best web designers to have those skills since they may want to be able to design websites, not just Drupal websites.
We run into designs for big Drupal projects that get made by specialized design agencies (without involving us, the Drupal development agency upfront). We see such Drupal website projects landing at our desks where clients have contracted design agencies first and then come up with a near perfect design that conforms with latest web standards and take responsiveness and browser quirks into account. Still we run into the pixel-perfectness issues that you describe. I would be interested in an all out campaign towards our mutual clients to raise awareness of the importance of a kickoff where both developers and designers are involved from day 1.
What about hybrid developers and how much can we expect them to know about alignments, grids and usability principles? I still see some out-of-the-box Drupal functionalities these days that require lack of understanding on how people use things nor do they allow easy 'overriding'. I think there is still a gap between 'architects' and 'implementers' that somehow needs to be closed. And there the saying goes like: "Understanding is a three edged sword; Your side, their side and the truth."
Hi Imre, A campaign to educate clients is always a good idea, and is honestly a big part of the reason I wanted to write this article, so developers could have something to point a client to as a guide to getting the project on track. I think educated clients make for much more reliable and stable clients. If they can be brought into the process early and shown why you need to have design/development considerations from the beginning, if you can show them how they can save on project costs by leveraging Drupal knowledge as well as Drupal modules it becomes easier for them to make conscious choices and spend budget for custom work where it is needed most instead of burning budget pyres fueled by poor design choices that force development to customize and override every corner of Drupal just to "match the comp".
As far as your question: "can you expect the best web designers to have those skills since they may want to be able to design websites, not just Drupal websites" I would say the answer actually is yes, especially if you are referring to "the best web designers". Web frameworks are complex beasts and some level of specialization is required to do the job properly. Now if you just a need a corporate brochure Drupal site, that is one thing and a general web designer can get by, but if you need a complex social platform built on Drupal that you want customized to your own businesses needs, then you are just asking for pain to hire a web designer off craigslist and expect general best practices will cover the needs of the design process. To use myself as an example: I specialize in Drupal design and as such if I was tasked with designing an interface for a RoR app the first thing I would do is sit down with a developer and get up to speed on the core ins and out of the rails framework and any existing infrastructure the project has. This way I could leverage existing elements where possible instead of just designing in a dark room somewhere placing all the burdon on the developers to try to implement my fantasy. I would also take a humble stance with the development team and ask where the design might be modified to better suit the existing infrastructure (without compromising UX quality) which is something that can't be done if the designer is long gone and the design is set in stone.
I think designers get off easy by claiming "design should be independent of the platform". Nothing is independent of it's platform, and making the choice to use a platform inherently brings with it dependancies, so to learn to leverage the strengths of a platform, and work with (or push the boundaries of) the constraints of a platform is IMHO a core part of a real designers job.