The Power of a Content Deck

One of the challenges of web development - particularly when you're using a waterfall approach - is to bridge together the discreet documentation the team produces, so that each individual element is part of a larger whole.  Documentation produced by tech should reference and leverage documentation produced by information design, and so on.  Not only does this help present a cohesive picture to the team and client, these references will be useful come development, when the team will be expected to stitch each piece together into a single product.  Over the past year, I've focused on leveraging the content deck as a key document to help tie together supporting assets with great success.

Why the content deck?: The content deck comes at a key juncture in the life cycle of an interactive project - it is driven by information design, but will inform creative design.  It is a lynchpin for the team, touched by everyone.  More importantly, it may be the only complete reference to the site that exists.  Wireframes and storyboards are often only produced for key or unique pages, but the content deck will likely include copy for each and every page of the site.

What to incorporate: Beyond actual copy, the content deck should reference and incorporate the following elements:

• Numeration from the information architecture and wireframes - this allows an individual to understand exactly where individual content elements will live within the site and on a given page.  Not only will this will help the client greatly during content review, which can be a disjointed experience, it is necessary for the technical team, who will have to populate each website page with the proper copy.
• Multimedia files and server location - most sites include photography and/ or video, and the content deck provides an ideal opportunity to reference which specific media assets should be placed on which screens.  Again - the content deck may be the only complete reference you have to the entire site, so it's a simple and easy way to pass this information along to the technical team for the build.  But, don't stop at the image or video name - include the location of that file on the server, or on an external social media site, as well, so the team will know where the asset currently lives.
• SEO data - title tags and meta descriptions for individual pages can also live in the content deck.  This means the tech team will have a single place to refer to for all this information, instead of disparate documents they'd otherwise have to try and connect to one another.

Improvements to the way in which websites are built can easily be made by streamlining our work process.  Consider maximizing the value of the content deck by incorporating much more pertinent information than simply copy.  In the context of web development, the old saying, content is king, can be tweaked - content deck is king.

Can We Combine Agile and Waterfall Development Strategies?

While there are likely as many unique Project Management approaches as there are Project Managers, there are two well-know production cycle methodologies that have been the topic of much discussion in PM circles – agile and waterfall methodologies. As I evolve in my own area of expertise, I am constantly reinventing small aspects of what I consider best practice. Most recently, to address the incredibly complex requirements of a large client initative, I challenged myself to come up with a 'super' Project Management process that would not only improve the way in which we deliver, but what we deliver at the end of the engagement. I determined there was a way to combine the best features of waterfall development disciplines with agile principles for superior results.

Simplistically, the waterfall approach infers structure, control, progression and finite project cycles. This approach works when you have access to limited resources and when specific hours are assigned to granular stages of a project phase. Agile is different in that additional leaway is given for teams to iterate through a single deliverable numerous times until a level of satisfaction is achieved. It's difficult to implement this approach when you are working with shared resources, or when time to market and budget cannot be shifted. It's important to understand my descriptions of the two approaches are extremely simplified and highlight key differences – for this entry, it's important that I make the distinction clear. I encourage all readers to conduct their own research into each approach more thoroughly.

Both approaches boast significant and different benefits, and are generally seen as being mutually exclusive of one another. It can be argued, however, that certain elements of both paths can be merged into a single process to achieve greater results. With this in mind, I have proposed a slightly refined process to my internal team, where iterations can be accommodated, but are scheduled within a defined process and period of time. In order to deliver on this approach, the efforts of multiple departmental leads (such as Information Design, Interface Design and Technical Development) must ocur concurrently so that the team can produce deliverables as a single entity. By doing this, each person's feedback is representative of the iterations which normally ocur as a deliverable is transitioned from department to department. The net result is a more controled cycle where iterations can still be accommodated.

I believe that the quality of an end deliverable will be superior when the expertise of each lead can be amalgamated into a single output. This style of collaboration will also result in a greater understanding of practice areas among the larger team – this will create long-term synergies that spur individuals to consider varying points of view, even when they work isolation.

This approach may seem like a very small deviation from standard operating procedure, but asking different subject matter experts to come together and produce one element together represents a big shift in previous thinking. This approach moves traditional agencies away from a manufacturing-based production cycle, and propels them forward into a more advanced collective and collaborative environment. As online initiatives take on more sophistication in usability, interface design and technical functionality, there will be a stronger mandate for this style of production.