Design and Prototyping for Drupal

Chapter 1. Design for Drupal: Basic Concepts

At the most recent Drupal Design Camp in Boston,^[1] Drupal founder Dries Buytaert mentioned in his keynote speech, “I make designers write PHP. And produce horrible code. You guys should hate me.”

While this announcement got a big laugh from attendees at the camp, Dries wasn’t completely joking. Creating effective design for Drupal requires a willingness to acquire some technical knowledge. If you’ve ever thought of using Drupal as a “quick” or “cheap” way to build a website, and you’ve experimented with it at all, you’ve already learned that you were dead wrong in that assumption.

But, if you’re willing to build on your design skills, learn some basic principles, and apply them to an interesting and rapidly growing technology, you might find yourself very happy working with Drupal. And believe it or not, the Drupal community will love you for it; the last couple of years in particular has seen a renaissance of talented designers who are not only doing beautiful work in Drupal, but they’re showing others how to do it as well. If you want proof, look no further than the impressive collection of videos from Boston’s most recent Drupal Design Camp, which you can find at http://ttv.mit.edu/collections/drupal:1922.

Blatant plug for the Drupal design community aside, let’s move on to some basic principles of creating design for Drupal. To recap from the Planning and Managing Drupal Projects guide, visual design (defined here primarily as creating the look and feel for a given site), often comes either after or alongside the technical implementation phase of a Drupal project. See Figure 1-1 for a reminder.

Figure 1-1. An overview of the Drupal site planning and design process. See how Technical Implementation and Visual Design go together? That’s important.

This is important for a couple of reasons:

1. Focusing on visual design later in the process helps clients focus on information hierarchy, content and structure in the early phases—which is especially important for content-rich or interaction-driven sites.

2. As mentioned in the Planning and Managing guide, having actual content and structure for the site at least somewhat established prior to starting visual design gives you a better idea of where you’re starting from—which makes it easier to create layouts that are both visually attractive and feasible to implement.

This last piece—feasible to implement—is one of the core challenges to working in Drupal, and where many visual designers end up going crazy. Whether we want it to or not, Drupal has ways it likes to do things—a fact that is true with any web-based framework (yes, even WordPress). By understanding and respecting how Drupal likes to do things, it’s easier to develop design patterns that allow you to design more efficiently, while maintaining your creativity.

The presentation Don’t Design Websites, Design Web SYSTEMS!,^[2] first presented by Todd Nienkerk and Aaron Stanush of Four Kitchens at DrupalCon Copenhagen, illustrates this point perfectly. Working with design agency Thinkso Creative to implement a complex Drupal site for Expeditiary Learning, the Four Kitchens team started with a series of visual designs, site maps and wireframes that Thinkso had put together. All of these provided an excellent design direction for the Four Kitchens team, but because some design elements had been created before Thinkso had chosen Drupal as its platform, several of the elements had to be reconsidered and restructured in order to avoid significant delays or cost impacts in production.

Does this mean that you should know you’re designing for Drupal before you start the discovery and user experience phase of a site? Not always. Some projects, particularly ones that involve a high level of user interaction or complexity, can benefit from a platform-agnostic approach in the early phases. What’s more important to this process is flexibility: knowing that your designs may have to adapt once you get into technical implementation. This need to adapt is also a key reason that designers should get to know Drupal. By having even a basic understanding of what’s happening “under the hood,” you can adapt quickly, and avoid the nightmare that eventually befalls every talented web designer: well-meaning implementers who destroy your design to make it fit their framework.

The process for creating an effective Drupal design often depends on the nature of the team and their development strategy. Some Drupal designers focus primarily on aesthetics and layout and give their designs to the developers to implement; other designers prefer to do a little bit of everything, moving from layout to Views configuration to theming as the project progresses, and working with developers to handle the trickier bits of functionality they want to develop.

As you’ll probably notice by the time you finish the book, I’m in the latter camp. For me, design for Drupal is about creating a vision, sketching out the possibilities, and moving quickly into prototyping to test the assumptions that I make during the design process. Prototyping early—whether with paper, in a program like Axure or Balsamiq Mockups, or directly in Drupal—helps me make sure that I’m not creating something that will be impossible to implement. It also helps me remain vigilant about all the little things that need to be considered when designing for in a Drupal site, including:

• 404 and 403 pages

• Error messages and content administration links on individual pages

• User profile pages

• Form elements, including the user login block

• The look of block quotes, tables and other things that might be inserted into the content

• Pages for individual content categories, or for social areas of the site

Because we’re working in a dynamic framework, any of these pieces might pop up at some point in your user’s journey through the site—and it’s a safe bet that all of them will. Taking the time to create design that integrates these components with your overall look and feel is part of helping your site look thoughtfully designed and not “Drupally.”

The design phase of a Drupal project typically happens in four stages:

Ideation

During ideation, you’re generating ideas for layout, usually in rapid-fire format. Options for ideation include style tiles (sometimes called mood boards), and sketches of wireframes or grid layouts.

Wireframing

Wireframes are basic, component-level mockups of your site’s pages. While it’s very possible (and increasingly popular) to sketch wireframes with pencil and paper and use those to discuss architecture and content priorities to the client, other options include Adobe Fireworks or Balsamiq Mockups. You can also use a program like Axure RP for wireframing, which allows you to prototype multiple pages within the same document, annotate functionality on the wireframes, and output a functional specification for developers with the click of a button. If you're doing UX work with clients who plan on developing in-house, this can be extraordinarily useful.

Design comps

During layout, you’re starting to lay in real content and images, and organize content on the page. Some teams, like San Francisco’s Chapter Three, use a hybrid wireframe/design process called “greyboxing” as a way to more rapidly iterate design; others prefer to keep wireframes and design comps as separate components of the design process. See Chapter 5 for more on greyboxing.

Iteration and client signoff

During iteration, wireframes and designs are discussed, debated, and tweaked until the team agrees that it’s ready.

Ideally, iteration happens throughout the entire process, with the final result being a set of visual designs that’s been agreed on by the team and signed off by the client as “this is what we’re going for.” Each stage feeds the next; ideation gives you the ideas for wireframes, which inform the designs, etc.

In theory, all of these pieces would happen in turn, and the final designs would be handed over to the implementation team for turning into a Drupal site. In practice, many teams go straight from wireframes into prototyping, and add visual design as a final layer. Others go straight into visual design and then work on implementing those designs in Drupal. As long as you have a solid discovery and information architecture phase to back up your design choices, either approach can work; the important part is having an understanding of what it will take to implement your design choices, and collaborating with your team to make sure that you’re designing things that can be implemented.

If you’re working solo, it’s also vital to know what pieces of the puzzle are beyond the scope of your abilities; having a developer you can call when you need some extra help getting something to work can save you money and headaches down the line.

About the Case Studies

Throughout this book, we’ll be focusing on two real-world projects. While this can make it challenging to “follow along at home,” for those who like to work that way, I have two reasons for this decision:

1. I’m working on them currently, and I enjoy being able to do two things at once;

2. Focusing on projects like these, as opposed to a single project made up for the book, gives you the chance to see how these ideas work in the real world, with all the frustrations and moments of unexpected joy that happen in real projects.

In Part II, we’ll mostly be using my portfolio site, tzk-design.com, as an example. This project is currently in the process of being redesigned as I refocus my studio, and it gives me a chance to walk you through the actual process of sketching and creating layouts for a relatively simple site.

The second project, Urban Homesteaders Unite (UHU), is being developed by myself and a colleague, Tricia Okin of Brooklyn, NY’s Papercut (http://papercutny.com). The site was originally conceived as part of Tricia’s MFA thesis (as such, layouts were already created), and I’ve been working with her to expand upon that original idea and turn it into reality.

The goal of UHU is to connect urban homesteaders, e.g., people into gardening, food preservation, and other city-hippie pursuits, through home-based events, blog posts and connecting with other homesteaders in their neighborhood. This lets me get into deeper areas of Drupal trickiness such as Views relationships and working with user profiles (cue evil laughing).

Through these projects, I can show you a typical Drupal design process—from ideation and sketches to prototyping and applying our look and feel to the site’s theme. Let’s get started!

---

^[1] http://boston2011.design4drupal.org/

^[2] You can get the slide deck at http://fourkitchens.com/presentations.