Planning and Managing Drupal Projects

Putting this all together

In theory, each member of the team will be dealing with its own piece of this giant puzzle called building a website. In practice, especially on small teams, you’ll often find yourself switching back and forth among different phases of the content development cycle. A typical Drupal project, for example, might look like this:

1. Site map and wireframes are created and approved;

2. The designer (you) starts adding in visual elements;

3. The front-end developer (or you) starts creating content types and fields;

4. Site content comes in, and looks different from the wireframes and designs that have been approved;

5. The front-end developer (or you) goes back and starts changing content types, fields, views, etc. to mesh with the content files;

6. The client decides that the content should be changed to match the designs;

7. The front-end developer (or you) goes back and starts changing content types, fields, views, etc. BACK to where they were before;

8. And so on, and so on...

Somewhere in this whole mess, theming also has to happen. In larger teams, the designer will often work directly with a front-end developer to iterate designs and incorporate them into the site’s theme. For smaller jobs, or solo gigs, you’re the one doing the lion’s share of the design, theming and content management. With time, you become used to it. A typical theming session for me usually involves tweaking the display of a field in my content type, then tweaking a display setting in one of the Views I created, then ...