Designing for Drupal


We've been using Drupal for years as the CMS of choice for our sites.

But while I personally had experience working with it when our shop was much smaller (I used 5.x I think), Drupal has grown in to much more of a beast in terms of sophistication and features.  Our developers are, of course, plugged in to the community and were using 7.0 before it came out, patching core modules, etc, to get a jump on it, but my skill level with Drupal was definitely novice (being a designer). So, as a professional New Year's resolution I decided to return to Drupal and really learn the guts of how it works now.  I did this for two reasons:

   1. I wanted to be able to speak intelligently about current modules and methods regarding views, panels, context, cck, etc.
   2. I wanted to design more effectively for Drupal theming.

So why would I want to do this? Well, it's good to know the technology you're using, even if you are not explicitly in the trenches using it day-in and day out. I wanted to be able to hear a client's request and immediately start thinking how a combination of modules could make it happen without having to check with a developer first.  Secondly, I wanted to design more effectively for Drupal, to streamline the theming process where I could while still doing great custom work.

With that in mind, I had everything I needed on hand to re-learn Drupal. was obviously a clutch resource as well as the dev team here, which I harassed with question after question during my experimentation. With these tools available I started a vanilla Drupal install on my computer and dove in.  My plan was to break up my learning in to two phases: configuration and theming.


The developers here helped me out with a list of frequently used modules that I installed. Luckily, I had a chance to do some pro-bono freelance work doing a site that's perfect for Drupal - News, calendar, events, galleries, etc., which served as an excellent way to learn. Right away I dove in to Views (which came back, albeit slowly) but I instantly saw the 'wow' factor of how to exploit custom content types and views to do a lot of what I wanted. It's definitely come a long way.

In the process I figured out how to do recurring events in a class schedule calendar, API integration into Flickr, node relationships/references between different content types, etc. There was a number of headaches and quite a few times I would delete content types, install new modules, revert, repeat, etc.  Eventually I started to get a clearer idea of how the whole system worked as I flushed out all the site content.  The final steps were discovering the power of Context to display blocks on different pages to control layout which is utterly amazing.

So how has this made me a better designer? Well, I can say I have:

  • A better idea of what's possible when displaying and organizing content
  • More understanding regarding how much configuration time is needed to actually build a site
  • A realization that there are many ways to build a site and rarely one 'right way'
  • Upmost respect for our developers, especially when they push the boundaries with custom modules

These ideas might seem obvious, but keeping these thoughts in mind while in client meetings, Protoshare or in Photoshop will help me visualize how the content could be structured down the road and help out our dev team wherever I can. The next step in my process was bringing the site to life with a design.


Theming was the second phase of my learning. Theming refers to taking a Photoshop file and applying it to Drupal via HTML/CSS. It's very different than straight production though, which I am more familiar with.  The process is much more iterative and often goes hand in hand during points in configuration.

So, starting with a tailored version of Zen we use, I started my design with an interior page. I sourced exact column widths, headings and margins outlined in Zen, as well as some general formatting of blocks (recent content, upcoming events, etc). I incorporated these restrictions in to the design and found space to elaborate and be creative within those constraints. The result was a great design that literally one night of work to get implemented. The process reminded me of paint by numbers. Not because I was only switching out logos of a generic template, but because I had the Zen html structure in mind when I was designing.   knew exact which divs would hold my overlapping background images and where to cut them a very unconventional look, but still within basic html. This saved enormous amount of time, especially for a pro-bono project.  It was sort of like knowing I had a square hole to work with, but also knowing I could chisel, paint, bedazzle, square peg however I wanted, instead of designing an oval peg simply for the sake of doing so and relying on the developers to implement. I also heavily experimented with what I could accomplish with FCK editor to show the design power of WYSIWYG editing.

With all this in mind, I have a brand new mindset when sit down in photoshop and design a site for Drupal. I don't want to unnecessarily reinvent the wheel on every site, and now that I know some basics, I can avoid that when possible. For example, if a Drupal module breaks the price of an ecommerce product to a second line, I'll just use that format in my design (unless there's a good reason to change it).  I'll keep the read more link left aligned and text, even though I could design it with some crazy floating absolute positioned button or format search results similar to the default manner if it suits the site. Again, if it helps the user it's ok to design outside these constraints but by "going with the flow" wherever possible, I can create not only more of a seamless transition from creative to dev, but a more well-thought-out site in general.

Closing thoughts - Designers, get out there and build some Drupal sites! You will expand your skillset – and your fellow developers will appreciate it.

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Consolas}