This series outlines our project process through the lens of our development of the new 4SiteStudios.com. In this post, we will discuss our process for architecting a content management solution for a client.
In the technical plan, we take the content plan, wireframes, and our documentation from the discovery phase, and begin to make decisions about how we're going to actually implement the site in Drupal. What content types do we need? What contrib modules do we need to install? Do all of those modules play nicely together? What custom modules do we need to write? What views do we need to build? How do we know when a feature is done, and how do we test to make sure?
The first thing we do is break all the main functionality of the site down into user stories. These are simple statements that describe tasks that different types of users should be able to perform. For example, "A visitor to the site can see a list of upcoming events," or "An authenticated user can register for an event." These are intentionally kept simple, so that we keep the focus on the problem we're trying to solve, rather than the way we're planning to solve it.
Next, we write a description for each user story. Descriptions are still simple and user-focused, but they go into a bit more detail. If the story is that the user should be able to fill out a form, the description tells us what form fields the user should see on the screen, and what she should see after she submits the form. These descriptions help guide us as we're designing solutions, but they also tell our developers (and more importantly, our QA testers) what "done" means. Occasionally as we're writing descriptions we'll discover additional use cases that weren't captured in the original wireframes, and we'll update the wireframes to match.
Finally, we briefly describe the solution we're proposing for each user story. Do we need to create a new content type? Build a view? Install a module? The solutions usually start fairly simply in the technical plan, but once we import the stories into our project tracking system, Pivotal Tracker, we'll start adding much more detail, including acceptance criteria and QA testing instructions. For any particular story, we usually write these detailed specs during the sprint before we actually start development on that story.
For the new 4SiteStudios.com site, most of our stories are pretty straightforward. We probably could have even built the site in Wordpress, but why would we want to do that? :) And since we're building the new site on top of our install profile, 4Site Hub, a lot of user stories (particularly stories for content editors and administrators) were already addressed in the tech plan for that project. As we go through the development phase, we'll test the 4Site Hub stories too, to make sure we haven't introduced any regressions.
The second tab of the technical plan outlines all of the content types we'll need on the site. We already started this work in the content plan, but the tech plan goes into much more detail. We capture all of the fields we need, the field type for each, whether it's required, and how it will be displayed. If the content type is based on one in 4Site Hub, we describe how we'll capture the changes—will we create a feature override, or just build a new feature? The third tab captures similar information for our taxonomy vocabularies. The final tab captures all of the modules, features, and third-party libraries we'll need for the project. For Hub-based projects, we always look for features and modules that are part of the standard installation that can be disabled.
Now that we have a plan for how we're going to proceed, we're ready to spin up a development environment and start building!
If you want to get a look at the tech plan for our new website, look below.