Planning and Managing Drupal Projects

Lifecycle of a Drupal Project

A good project plan for Drupal starts with the client. How much do they know about Drupal? Did they specifically request it, or was it something you suggested to them as you heard their list of requirements? This is surprisingly important information. For clients who are new to Drupal or just learning about it, there’s a bit more handholding you need to do in order to get them on board with the process. Designing for content management systems is very different from designing for Flash or with straight HTML; it’s very common for Drupal designers to realize too late that the brilliant layout they designed won’t go into Drupal without a serious fight.

I typically break Drupal projects up into six distinct phases:

1. Discovery. During discovery, we learn as much as we can about the client, the project, and the project’s objectives. This is also where we start to create a map of the functionality that we need to implement, any resources we’ll need, etc.

2. User Experience & Architecture. This is where we take a deep dive into the lives, personalities, and other factors that define the humans that will need to deal with this project on a daily basis—both the end users that visit the site, and the clients who will end up managing the content once the project is finished. During this phase, you’ll be doing work like wireframes, user flows, and often starting to prototype things directly into Drupal.

3. Prototyping. During prototyping, usually done just prior to starting the Functional Implementation phase, we start testing some of the hypotheses and user flows that came out of the User Experience phase. For simple sites, the prototyping and functional implementation phase go together; for more complex user flows, or for projects where you’re wrangling a ton of content, the prototyping phase is essential to making sure that something you want to create will work the way you want it to in Drupal. We’ll go deeper into prototyping in a future guide, Design and Prototyping for Drupal.

4. Functional Implementation. During this phase, the focus is on creating the functionality that we’ve described in the user experience phase, and ironing out any areas where the functionality we’ve decided on doesn’t make sense, or aren’t available within the budget. For many smaller sites, there’s a good chance that you’ll be doing this work on your own; however, if you’re not currently on a Drupal team, be advised: get to know some developers, and pay them to do things for you when you’re in a rut. Developers are a Drupal designer’s best friend.

5. Visual Design and Theming. Notice, please, that visual design, here defined as the colors, fonts, images and other branding elements that define the look and feel of a given site, comes fifth in this list. There are many reasons for this, most of which you’ll find in this book. The most important, however, is because bringing visual design into the picture too early in a Drupal project—or any significant project, for that matter—is a recipe for disaster. Part of your job as a Drupal designer is to keep clients focused on what’s important, and what’s important is how this site will serve their business objectives and their brand. While visual design is an important component of the site’s value, it’s just one piece of it—and it’s the piece that clients will most often fixate on, to the detriment of more important issues, such as whether a user actually needs 50 pages of content in order to make a purchasing decision. The best way to explain this to clients is that the first part of the process—which is still design, by the way—sets up the experience you’re creating for the user, and establishes content priorities. The visual design/theming phase makes sure that the experience you design in those early phases meshes with the client’s brand and messaging.

6. Testing and Launch. Note to self: Always Test Before Launch. And After Launch. And then again after the client’s had a chance to muck around with it. There are a few steps to the launch phase. First, you’re moving your code from a development server to a staging server (the server that holds your site before the world gets to see it), and making sure parts didn’t break in transit. Once you’re sure everything’s good, you’ll move everything from staging to production (where the site will ultimately live). For this process, it’s incredibly useful to have developers on your team.

For most projects, I also like to include a final phase, which helps consolidate everything that we’ve learned from working on the project:

1. Wrap-up meeting/Documentation. In the wrap-up meeting, you sit down with the client and discuss what worked well in the project, and what could have gone better. It’s also a useful time to document the knowledge that you gained through the project, either in an internal Wiki for your team, or on Drupal.org (hint!).

Figure 1-2 provides a quick visual breakdown of how a typical Drupal project works.

Figure 1-2. Typical project lifecycle for a Drupal site.