Demystifying the Interactive Process [Part VI – Deployment]

By this stage the development is done, the code is married to the front-end designs and the internal team has had their chance to crawl around inside the guts of the interactive piece to break it before the Client or worse, the end users break it themselves. Once the internal team has had their chance to check their own work, the work gets turned over to the Client. At that point, we’re out of Development and moving directly into Deployment.

Although you might be tempted to dismiss Deployment as a ‘simple’ or ‘easy’ part of the process (‘just wrapping things up’), Deployment is perhaps the most busy time in any interactive project, with the most amount of ‘rushes’, ’emergencies’, and ‘fire drills’ happening. Do yourselves a favor… don’t schedule Launches of major interactive projects unless you can devote a good 80% of your attention to the Launch on the day it happens, and 40% on the day after it happened. For this reason alone, unless there’s a specific market driver to the date, never schedule a launch on a Friday or before a weekend. You -want- there to be staff in the agency’s office 24- to 48- hours after any major launches. Launch on a Friday and you’ll be stuck waiting for tech support til Monday morning (or paying for overtime).

User Acceptance Testing/UAT

Deployment kicks off with a phase known as User Acceptance Testing, or UAT. This is the time when the project, typically in a staging server environment (e.g. it doesn’t live where it’s going to be served up to the public, yet. Like Nike developing a site redesign on staging.nike.com vs. something up at Nike.com… just making up theoretical examples here). Everything is built and “done” from the initial round of creation’s standpoint. The project itself should exist and work in its final state, with only content tweaks and minor facade-level changes being made per Client requests. If you hit UAT and end up making architectural- or structural-level changes to the site that you didn’t plan for originally, then raise the red flag and get ready to move back into Development, or even Definition phase.

What to expect from UAT as a Client

During UAT, the Client is given the link to the project on the staging environment, and then they are given a set amount of time to find anything wrong or to break the site. At this stage of the game, what you as a Client -should- be doing is navigating to your project link from as many different computers, on as many different platforms as possible. You should be creating test scenarios and walking through sample interaction points to test and make sure the database is working properly, or to get a real sense of any problems that a typical user will encounter. What almost always happens, though, is the Client representatives give a good proofreading of the site and send back feedback which is aimed at how the site -looks- more than how the site -functions-.

At the very least, you as a Client should open up the Functional Specifications document which was created back in Definition, as well as the Wireframes document, and you should go page by page trying to do all of the actions and activities in the Func Specs, Use Cases, and Wireframes. Note any area where what was promised in the documents doesn’t work as promised in the project, and bring those areas up with your Producer. Either there were decisions which were made between the Func Specs and UAT which didn’t get updated in the Func Specs for timing reasons, or else there’s going to need to be a proper explanation why something promised from a functionality point of view is not being delivered as per agreed-upon expectations.

When all looks good and matches the written documentation or has been explained to satisfaction, the Client submits a formal approval to the agency and pulls the trigger on the rest of the Launch process.  If the web site is particularly large or involves complicated functionality, you might have a Formal Site Walkthrough meeting where the Agency walks the Client team through the website one, last time. At the end of Formal Site Walkthrough and any fixes that come about from it, the Client signals approval, and we move forward to the actual Launch process itself.

Code & Content Freeze, then Launch

Once the Client has approved the final project, the Agency developing it should issue a formal Code and Content Freeze. This is the point beyond which no changes will happen to the project until after the project is live. You need to freeze the coding and content revision process because part of what it means to have ‘flexible results’ within the Interactive Process is that coders and designers and content creators could and will tweak things to death unless you give them a point at which it’s hands off before launch.  What are they changing? Adding documentation, adjusting layouts, adding content, tweaking presentation of content, small tiny things that can be done at any time once the site is live.

Next will come the Launch process itself. Typically, the more complicated projects involve a series of coordinated steps where the new server space is created for the project, the hardware is set up, the files are transferred over, the DNS registry is updated, and finally, the site goes live.  To track all of the moving pieces and infrastructure-level sysadmin tasks, good Producers will generate a formal Launch Plan document and review it with both the internal team as well as the client team to present a checklist of launch steps.

Other projects will be so simple and straightforward that all you need to do is copy the files to the new, live server, or turn on the DNS registry changes and you’re done. Every project is different. If Agency or Client begins to feel iffy on the steps involved in the Launch, it takes about an hour to draw up a Launch Plan and circulate it for approvals. Don’t be afraid to ask for one, it’s one of the many services an Interactive Producer will provide.

The Post-Launch Scramble

It always happens. The site is perfect, every team member who ever heard the name of this project or went to school with one of the other team member’s children or siblings signs off on every document ever created… the project goes live…. and suddenly the CEO on the Client side is looking at this gem of an accomplishment that the Client team put together, and clicks on a broken link. The ONE broken link that escaped Inspectors 1-12 is the ONE link that the CEO clicks, gets an error message.

The Client Team goes into immediate panic mode and contacts the Agency team with a note of stern rebuke and strained panic in their voice to inquire, nay, demand to know why this one link wasn’t caught! Yes, it’s horrible that it happens and everyone takes great pains to ensure that everything works, but I have to tell you, these things just happen from time to time, and it’s always the Client Team’s high ranking supervisors who happen to find them.

This is why, as an Agency, the Launch is the busiest period of time. There’s going to be something wrong. You just hope it’s cosmetic (“You misspelled Smythe on page 2.4.12, second paragraph”) instead of structural (“We were supposed to put the Mission Statement in both About Us and Contact Us, but it only appears in About Us right now”)  or worse, catastrophic (“The password login screen brought me to the last user’s shopping cart, complete with credit card information populating all the fields”).  Knowing that no matter how vigilant the QA and UAT process is that there’s just going to be -something- that needs to be fixed or which doesn’t work -as expected-, as an Agency you need to ensure that there are dedicated resources on your team who are ready to drop everything else they’re doing to immediately tackle any unforeseen problems that crop up STAT so that the newly launched site gets rid of any hiccups -before- the general public notices them.

Once the project has launched and it’s out there, live, on the net, with all the immediate bugs either fixed or in queue to be fixed, then Deployment has been achieved. You might be tempted to think that this marks the end of the Interactive Project Development Lifecycle, but you would be forgetting two of the most important steps of all which follows any launch:  Measurement, and Maintenance. We’ll talk about Measurement next in Part VII.

Demystifying the Interactive Process [Part V: Development]

This is the stage of a typical Interactive/Software Development Lifecycle where the rubber meets the road. By this point in the process the Strategist has assisted the client in identifying specific desires and establishing metrics for them (Part II: Discovery). There is a formal Scope of Work, Estimate, and Project Plan made (Part III: Definition). The Information Architect has established the basic structure of the interactive experience and the Creatives have stepped up to translate the wireframes into key visual comps or designs (Part IV: Design).

Now it just has to be built. Piece of cake, right?

Yes, But…

Development is going to be one of the more difficult phases for the average Project Manager to wrap their head around when it comes to making plans, scheduling, and performing schedule adjustments once the project is underway. This is due 100% to a communication barrier, a veritable chasm which splits any agency into two distinct groups: those who code, and those who do not.

The language barrier is a simple one, and very easy to overcome once the PM is aware of the dynamic involved. The simple fact of the matter is that a coder speaks a language which requires an exacting level of precision and accuracy, a level of precision and accuracy which is typically misunderstood and completely unappreciated by non-coders. Ironically, earlier in this series I focused on how Project Managers typically feel frustrated because *we* tend to use language very specifically as compared to everyone else on our team, and yet it’s the exact same dynamic which can result in a developer agreeing that yes, doing things this way is certainly -possible-. In software development, really, given sufficient resources, time, and expertise, most anything is ‘possible’. This is why it’s very important that PMs on any sort of interactive team need to cultivate a relationship with the folks in development, and they need to take an active interest in learning as much about the big picture of what’s going on inside the Development process.

The Development Process

I’m an outsider to the development world myself, so allow me to present the extremely broad strokes for what Development actually entails. First, the Developers are going to want some sort of an official hand-off once the project is ready to move into Development. Coders tend to appreciate linear and specific instructions. So provide them with linear and specific instructions, or else turn the Development Hand-Off meeting into a time when you can work with the Developers to jot down the outline of their linear and specific instructions.

In an ideal world, the Business Analyst or the Information Architect has already generated Functional Specifications to go along with the Wireframes. These two documents together provide the best starting point for any Development team because those documents contain the specific plans that the Client has already approved.  The Developer can now check the Func Specs instead of trying to translate the PM’s response to questions about what the Client wants. The Developer can look at the overall effects being called for in the Wireframes or Use Case Scenarios (“on rollover, display X from Wireframe 3.2.12”).

Once the Developers think they understand what’s being asked (note the relative wiggle room in this statement), they will then begin to apply their own brand of planning and execution to things. It will start with the Developer opening up the code and “taking a look under the hood”. There’s more than one way to write code for most complex tasks, to the point that several coders make the case that writing code is a form of literature unto its own. It communicates the mental state of the original coder.  That’s why, unless the development team is building from scratch (and even then they should be repurposing code structures from other successful house projects, not reinventing the wheel) it’s always possible that the Development team will return quickly with bad news… “The project’s going to take a lot more work than I thought.”  Why didn’t they flag this earlier? They hadn’t opened up the code until then.

First build it, then break it

Then the coders get to work. This is where the Keebler Magic happens. The coders will begin a staring match with their computer screen and alternate between lots of clickety-tappety, lots of frownity-glare-ity, and random bouts of cursety-swearity. (Those are technical terms. Don’t believe me? Watch a coder at work.) First they’ll build the code. Then they’ll do everything they can to try and break it. Once things have gotten to the point that the Developers get bored with breaking the code, they’ll declare it done and turn things over to the QA process. Anything that happens beyond this point will always and unfailingly be someone else’s fault. Doesn’t matter who the coder is. It just sort of comes with the territory.

All along while the actual coding is going on, the Design is also likely being put together to work in an interactive environment. As Development nears a close, any of the heavy-lifting that the back-end developers are doing will eventually be married to the front-end Design-heavy coding that Production Artists are doing. Adjustments are made until it all synchs up right, hopefully on schedule.

QA, you say?

At this point Quality Assurance will take over. The project will most likely be put up in some Staging environment (which means it’s NOT the place where the project will ultimately find a home). Staging environments are usually password protected, but sometimes protected by the complete lack of interest that anyone has in half-baked projects anonymously posted without any advertising or push for visitors to get there. In smaller shops, QA is handled by a coder who didn’t actually code the thing. In larger shops, QA is a separate career specialist who focuses on finding as many mistakes as they can.

QA will then try to interact with the project on a variety of different computers, different browser versions, and different communications platforms (like Mobile) when appropriate. The QA person will look at the Func Specs, Wireframes, and Use Case Scenarios and check to make certain that everything works right and looks right. Their job is to find all the errors possible BEFORE the client takes a look at what might be a broken program or page.

Quality Assurance is actually one of the steps in the process which fits equally well in both Development and Deployment. I personally favor putting QA at the end of Development, because QA is handled internally. If there are any errors to be found of sufficient intensity, then after QA is done the project will return to the Developer to fix or update things as needed. It’s only once QA signs off on the project, or once the Developer has made all of the fixes and overruled the QA process that Development truly ends.

What to Expect As a Client

If you are working with a team for the first couple of times, you can expect there to be some bit of learning curve to happen in the Development phase. This is a difficult phase for the Client side of the house because while the Developers are happily clickety-clackety-ing you won’t see anything, or hear anything, or be given anything to sign off on. UNLESS there’s a change to the scope, or unless the developers got knee-deep in someone else’s code and discover a huge problem that couldn’t be foreseen otherwise, no news is good news but the wait can be uncomfortable for clients used to more of a micromanagement style.

This is the part which can be frustrating for another reason, too. A more subtle force is at work here, and that’s the fact that Coding is much more an exercise in Creativity than it looks like from the outside. There’s often a couple ways to accomplish the same intermediate steps, but putting them together one way will empower more robust use of those features and functions at the end, while combining them in code a different way could actually PREVENT the development of more complex features down the road. Because of this variability in coding methods and informational structures, coding can be a very personal matter. In larger development houses there will be a House Coding Style and standard which the shop is expected to follow. In smaller development shops, it’s up to the individual developers.

Pregnancy Trap

Because of this, you run into what I call the ‘pregnancy trap’. The old office chestnut goes like this. “It takes a woman 9 months to bear a child, but if I give you 8 other women does that mean I can have the kid in 1 month?” The pregnancy trap. Certain efforts need to be assigned to a single person, or a dedicated team that works on things from start to finish. If you’re working on a ‘pregnant’ task then adding more people won’t make the process go any faster. Some things in life just take as long as they take, and they can’t be hurried by throwing more money or more resources at it. Developing, more often than not, is exactly like that. (Except when it isn’t… building a trust-based relationship with coding teams can make all the difference. Until client, PM, and developers trust each other, or at least learn to trust the PM, this phase will produce round after round of unexpected troubles.)

Obviously, trust becomes a huge factor here. Since Developers are usually kept far away from the Client in many organizations, you’re going to need to trust your Project Manager. One thing that you can do to alleviate stress in long-term development cycle projects is to ask the PM to set up periodic checkpoints WITHIN the Development phase. They don’t have to be client reviews, but just times when the PM estimates that different pieces of coding will be done. From there, the PM can simply review where the project actually -is- during the Development phase without trying to coax the Developers from their keyboards.

Once Development is done, User Acceptance Testing — the part of the project where the Client gets to try everything out — will begin, and UAT is where I mark the formal start of the next stage…. Deployment.

Demystifying the Interactive Process [Part IV: Design]

After the Project Plan has been approved and is in place along with all of the other documentation from the Definition Phase, we move on into the part that everyone automatically wants to begin with when it comes to Interactive…Design.  If you’ve been following this series of articles then you will already be well aware that in the Interactive SDLC process, there are many things that are much more “involved” than their labels might lead you to think, and the Design phase is no different.

Design Starts With Architecture. Information Architecture.

All Interactive projects need to begin by taking the conscious efforts of design and applying them to the underlying architecture of the project. With a physical project, the architecture would refer of course to the physical materials arranged in such a way as to make the physical structure function as desired. On the Net, architecture refers to getting information arranged appropriately so as to invite, encourage, and produce the correct communication message, interaction, and response from your audience.

Typically, web sites contain a lot of information, and arranging that information appropriately can make all the difference when it comes down to users being willing or able to make use of it. We’ve all gone looking for simple answers to what we thought were simple questions only to realize that it was nearly impossible to find that information on a particular site. (If you haven’t, I invite you to peruse the website http://www.irs.gov.) Whenever a user gets bogged down or can’t figure out where something is, the fault will typically be found in the way that the information on the site is being organized.

To prevent getting lost amid the information, the first person who has to jump into the mix from the Agency side to help provide organization and clarity is called an Information Architect, or IA for short. The IA is responsible for designing the way that the information on the site needs to function. To do that, they will look at the SOW, Strategic Plan, and any Business Rules or Func Specs which have been generated. From there, early on in the Design phase, the IA will produce several new documents for review with the Client.

Common IA Deliverables and Why You Need Them

Some of the most common deliverables that an IA will provide at this stage include Graphical Site Maps, Wireframes, Use Case Scenarios (often included on the Wireframes), and Tabular Site Maps. Let’s take a closer look at each one and what they’re used for in the greater scheme of the Interactive development process.

Graphical Site Maps

The Graphical Site Map is a diagram or chart which is created that shows how the main pages of the web site will be organized. The diagram will show how the IA thinks that the web site should be broken up. Depending on how many pages need to be in the site, the Graphical Site Map can grow to be quite large, or might include several diagrams that expand parts of each other. The reason for this basic division is to show the Client how the IA thinks that the stated goals from the SOW and Strategic Plan, or perhaps the existing content from the Content Audit should be arranged in the new site.

If the IA does their job the correct way, everyone looking at the basic subdivisions on the Graphical Site Map should experience a bit of a “duh” reaction. When the IA manages to get everything aligned in a common sense or “intuitive” division of subject materials within the site, the results should be underwhelming. It’s only when IA is given lots of complicated inter-dependent microsites, or extensive, encyclopedic amounts of data to make easily accessible that the Graphical Site Map will actually get nods of approval or even in rare cases, smatterings of applause for the IA. But in general, if the Client is thinking “Well, duh! Of course this should be arranged that way!” then the IA has most likely been successful in rendering down the information into an organizational format which will be interpreted as ‘intuitive’ by most users. Usually.

Wireframes

Wireframes are one of the most dangerous documents that will ever be created. Why? Because a Wireframe is frequently misunderstood by Clients and sometimes Agency folks alike. A Wireframe is a formal document which goes through key pages within a web site’s organization and provides a visual representation of the overall PRIORITY OF COMMUNICATION on the page. This is why it’s dangerous… because it looks a lot like a boxy kind of layout, and it’s usually the first visual representation of what is going to eventually be included on the page.

This is where visually-conditioned Clients with lots of experience in approving designs for print-based media will sometimes forget or overlook the fact that the IA is NOT proposing a layout, they are simply providing an intermediate step which blocks out:

  • All of the elements which need to be on the page when Creatives make the design
  • Any omnipresent elements which will constrain those visual Comps that the Creatives will eventually make (like a masthead, or navigation elements on the page, search boxes in certain locations, etc.)
  • The relative importance or priority of various communication messages or bits of information (whether the News Feed on your homepage should be bigger than the Welcome Message, whether the Call to Action is to be larger than the body copy or smaller, whether it’s more important to emphasize a Call to Action leading the user to another page or to try and emphasize the content which will keep her here, etc.)

Wireframes are meant to begin laying things out in relative terms, not absolute. As a Producer, I frequently end up going on at great lengths to try and stress this difference for my Clients, and usually most Clients understand that this isn’t a layout, although until they’ve been through the process a few times they might not be exactly clear on why something that looks like a layout to them actually isn’t a layout after all. Comprehension of the full importance of Wireframes usually only comes with repeated exposure, even though intellectually most everyone understands that the actual designs in many cases will look quite different, it can take a few times at the rodeo before the reality of this shift sinks in to the point that there’s no need to remind folks of the limits of what Wireframes actually represent.

Use Case Scenarios

This sounds very complicated, but the Use Case Scenarios are simply the Functional Specifications being called out, typically in the Wireframes but occasionally separate. In a nutshell, Use Case Scenarios detail in text format what will happen on any given page when certain behaviors are clicked or interacted with. An example of a Use Case Scenario might be, “Upon mouseover button A on the wireframe will reverse the text to indicate rollover state. If clicked, a flyout window will appear and the Flash video player will automatically start [see wireframe 3.3.1 for flyout window].”  As with anything in the Interactive realm, Use Case Scenarios seem trivial but will quickly become absolutely essential for identifying communication disconnects and unstated Client or Agency assumptions *before* the Creative team spends hours designing or the Tech team spends hours coding.

Tabular Site Maps

Where a Graphical Site Map provides a visual cue to the overall organization and linking patterns of the site, the Tabular Site Map is typically a spreadsheet which provides the IA with an exhaustively detailed Excel spreadsheet that will track every single page of the entire project. The IA will typically use a decimal system of counting to indicate what level or tier of information deep any given page is (so 1.1.1 is located on a deeper tier, or more deeply inside the site, than page 3.1), any important elements on the page (video, audio, pdfs, forms, etc), the name of the physical file itself, the title of the page, and any other items that the team as a whole will need to keep track of.

The Tabular Site Map is meant more as a resource and reference ‘at a glance’ than the Graphical Site Map. Where a Graphical Site Map will often just display the visual relationship of the pages of key importance, the Tabular Site Map will aim to provide a comprehensive, exhaustive reference material for every element, asset, or page in the entire site. The good news is that the Tabular Site Map can be developed *after* the Wireframes are signed off on by the Client, meaning that this step of the process is more an administrative support function and coordination function than it is a part of the Critical Path for determining timing.

Finally, Creative

It is very useful for both Clients and Agency employees to keep in mind that it’s only after the Information Architecture has been approved by the Client that the Creatives should be engaged to begin designing the site. The reason for this is that without the approved Wireframes for the various pages of the site, the Creatives won’t know what needs to be on the page, or what the overall priority of communication and layout elements will be. The Wireframes approval process creates the generic document that the Creatives should be using when they settle down to begin the artistic endeavor of  creating the design aesthetic.

This is by no means universal! There certainly are shops out there where the Creatives begin their work without a care for Wireframes. On certain clients or maintenance-based accounts, there isn’t always going to be a need to generate new IA documentation. But in all cases there certainly does need to be some form of existing IA already in place. If a Client is extremely web savvy, at times they will actually provide their own Site Maps and Wireframes, which can be a time and money saver for those experienced Clients who are more up to speed on the Interactive process. In general, however, as a new Client you definitely want your agency to provide Wireframes for you.

Having worked in shops where Creative just went to town on a blank page, and in shops where Creative worked from Wireframes to make their design, I have to weigh in solidly on the side of the house where Interactive Creatives work from Wireframes. In the Print world, the Creatives should be used to working against some kind of physical dimensions, limitations, or specifications for the final printed piece. It doesn’t do the Creatives any good in Print to be working on in standard Letter paper size if they need the art to go on a billboard. The art just won’t expand generally to accommodate that scale-up.

In Interactive, the Wireframes represent the specifications that the Creatives need to work within, along with a kind of a Creative brief provided by the notes, Use Case scenarios, Functional Specifications, and required elements that need to go on the page. Interactive Creatives who have worked in shops which require starting from Wireframes generally tend to request Wireframes wherever they go. Most Creatives want to be spending their Creative mojo focusing on the conceptual and artistic areas of the design, not flailing about trying to figure out what else needs to be on the page. Starting from Wireframes helps to eliminate that confusion.

Print-based Creatives In an Interactive World

You might be tempted to think that an Art Director with decades of experience in Print can simply and easily design for the web without there being any sort of major hurdles or obstacles to overcome. There might actually be professionals who can easily make the switch, but I must confess I haven’t run into them. The reason is that each medium carries its own “baggage”, restrictions and capabilities that designers spend entire careers coming to know and appreciate. While the Print Art Director certainly has the aesthetic skills to present information in a clear hierarchy and interesting design, there are some very fundamental problems that need to be kept in mind while designing for the Interactive Space. Generally speaking, when the Creative Lead on any Interactive Project doesn’t have Interactive Design experience already under their belt, it will manifest in the Creative that is produced, and it generally tends to slow the process of Interactive builds down as Creative approvals require extra rounds of revisions to help tweak the design.

Having worked for over a decade as a Print Creative, I’m speaking from personal experience myself, as well as experience coordinating teams where Agency management decided it would be a good idea to rely on the Creative efforts of the Print-based Art Directors without bringing in an Interactive Designer to function as Lead Creative and help guide their offline-designer around the common pitfalls. If you are a print-based designer stuck with an interactive job, here’s some basic advice to help you through the transition.

Surrender Control

The interactive space is all about surrendering traditional control, both for designers and for businesses in general. Perhaps the biggest, hardest lesson for Print-based Creatives to wrap their heads around is the fact that you, as a designer in the Interactive space, have limited amounts of control over how the user will encounter your finished product… unless you have great help from your coders. Here’s some key basics to keep in mind.

  • Platforms vary. How a graphic displays can be affected by the monitor Gamma setting from your user’s desktop. You won’t have the same precision control over the final color, look and feel, or even size of the screen on which your work is being viewed.  This especially matters when it comes down to what you think will appear “above the fold” on the page. On one monitor, it might be the whole page itself. On another, you might not even see the headline. QA Process is your friend for this very reason.
  • Fonts. There are only certain fonts that are considered to be ubiquitous enough on all platforms to render them ‘web safe’. If you want to do fancy typography, you won’t be doing it in your running copy without first checking with your Producer to see if the budget exists to try and force downloads of your uber-coøl fontography. Stick with the “web safe” fonts you can easily Google for body copy, and save the fancy fonts for things that can be represented by graphics.
  • It’s a whole different aesthetic. White space in print is your friend. White space on the web can just look empty unless you design it properly. Do yourself a favor and find other websites which have similar aesthetics to the layout you’re designing, and critically evaluate whether the spacing you have works as well on the web as it would if it were in print. If you’re not careful, the whitespace you’re planning might on some platforms and monitors disappear entirely. It’s a whole different aesthetic out there, buddy.
  • Learn the rules of the new media before you try to break them. If you pick up a textbook, you would expect to find certain standards and conventions followed in the way that that book pages were laid out. You would want some kind of a table of contents to be in the front, perhaps an index in the back. You would want chapters to start on new pages. You would want there to be a margin around the edge of the page. And somewhere on the page you’re going to want some kind of a page number, and perhaps a running section title or chapter header to appear on the top of the page. These are all the standard conventions followed for the book medium. Well, the web has developed certain standards of its own. Buttons should look like they can be clicked. Links should be underlined. Breadcrumbs are helpful. Etc. Start paying attention to the common elements present on many ‘modern’ web pages and figure out why those elements are there before you decide to discard or reinvent them.

Reviewing Comps, Some Notes for Clients

As a client, when it comes time for you to review the design Comps that your Agency Creatives have presented you with, be certain to view them on a computer monitor at as close to 100% of the finished design as you can. If at all possible, ask your Agency to present the comps in a simple format which will allow you to view them in a web browser itself, because that’s where it will eventually live.

Understand as well that control over colors and fonts is at present beyond the capabilities of ANY Interactive agency to ensure. If you look at a design Comp on your work monitor and the red in the background looks a little orange, before you try and correct that, check it on your monitor at home, or on your laptop, or on a monitor for a different platform.

When it comes to fonts, ask your Creatives whether or not the body copy has been done in a web-safe font. Even if the answer is yes, prepare yourself mentally for there to be some differences between the static Comp you are looking at and the actual live HTML/ASPX coded web page that will eventually be launched on the web. I had one client of mine, quite savvy too, raise a red flag because the fonts on the live page after launch didn’t match exactly the fonts on the design Comp. The problem lay in the expectations, not the coding: the Comps had been generated on a Macintosh computer, and therefore had picked up the Mac version of the fonts while the Designer was working on it from Photoshop. The JPG sent over for client approval had the Mac-version of the font in it, because it wasn’t live type, it was a JPG version of the way the screen looked to the designer. When the client viewed the live page on their PC, the PC-version of the font family called for was web-safe, but it had slightly different spacing than the graphic of the Mac font had shown. It was a bit of a learning experience for us all as we figured out the source of the disconnect.

And finally… expect the design comps to look differently from the wireframes. Sometimes radically so. That’s not an error, it’s intentional. The overall priority of communications and visual elements should be clearly identifiable between the Wireframes and the design Comps, but that should be the end of the similarity. If your design Comps look exactly like the wireframes, chances are that either your IA produced Wireframes which intruded too deeply into the Creative’s aesthetic role, or else the Creative interpreted the Wireframes far too literally. You would need to weigh your options in whether or not to call for a brand new set of design Comps in a different direction.

Closing Considerations For the Design Phase

With those few minor points in mind, the Clients reading this will be relieved to know that the Interactive design process is more or less the same from their point of view as it is in the offline world. Keep working with Creatives until you get the look that you like. Just be aware that the process needs to continue, and if you’ll refer to your Scope of Work you’ll notice  that the number of rounds of revisions should be specifically called out. (“Agency agrees to provide up to three initial design directions with up to four rounds of revisions once final look and feel is determined.”) If you go over that amount of design rounds, you should check with your Producer to see if there will need to be a Change of Scope written or if timing or budgets will be impacted and how much.

The only other point I can think of to raise for Clients on the Design process is to be aware that several agencies will stagger the design process. By that, I mean that it can be common for an Agency to present Design Comps for the Home Page first and foremost, and not begin working on the other internal pages until a design direction for the Home Page has been approved. Agencies will often do this to get you as a Client to lock down an overall “look and feel” or “design direction” before putting their Creatives to work in making the internal pages. It saves time and money, since once the Home Page aesthetic is set, it becomes easier for Creatives to just extend that design look and feel onto the other pages they are creating.

A good rule of thumb for determining when the Design phase is over is to check your Wireframes. In general, every Wireframe produced by the IA should also have a Design Comp produced by the Creative… if the page was important enough to get its own Wireframe, then it’s usually important enough for the Client to approve its own unique Design. When all of the Wireframe pages have gotten Comps presented and approved, you’ve passed by the Design phase and are moving on into Development, a phase which, as we will see tomorrow, happens primarily behind the scenes in the Agency itself, and typically doesn’t require much in the way of Client approvals until the very end when Deployment is near.

Demystifying the Interactive Process [Part III: Definition]

After the options, ideas, and realities have been clarified with the Discovery process, the next step of the Interactive SDLC is Definition. During the Definition phase, everything that has been discovered gets documented and agreed to by all stakeholders. It is now that the actual project takes shape, and concrete plans are put into place which will govern all of the rest of the development process for the project.

Definition, For Clients

As a Client, the Definition phase is the one which can seem like the most redundant and particular phase of development. Conference calls and face-to-face meetings with several team members should already have taken place. The Interactive Strategist has been working with you to narrow down all of the possibilities, and you now know what it is that you will be building. After all, wasn’t everyone in on the conference calls that just took place? Isn’t the agency ready to actually get to work with making something yet?

In a word, no.

The ideas and strategies which the Interactive Strategist or Marketing Specialist has helped you decide on as a Client now need to be handed over to the Interactive Producer, who will be using all of the materials and learning from Discovery to create several documents. First and foremost, the Producer will generate a Scope of Work (or SOW), a document which will use extremely specific language to describe exactly what the Agency will be providing as the end results for the project itself. This document is presented and then approved by both sides, and usually both the Agency and the Client will sign off on the document, establishing it as the be-all and end-all contract for this particular project.

Clients, READ BEFORE SIGNING!

I’m going to let you in on a well-known fact in the industry: Agencies use language in a much more precise manner than Clients tend to do. This is very, very important, because part of that precision means that if something is not called out in full detail in the language of the SOW, then the Agency will not expect that they will be providing whatever that something is. When inexperienced Clients read Interactive Scopes of Work, they tend to carry assumptions along with them. Even if the language of the SOW doesn’t call something out explicitly, the Client may assume that one of their expectations is “just covered”, or else that it’s such an item of common sense that there’s no need to spell it out in the SOW.

Sooner or later, those assumptions will turn out to be wrong. Dead wrong. That’s why it’s crucial that you, as a Client, give yourself adequate time to review the Scope of Work. When you go into a meeting, Webex, or conference call where a Scope of Work is being reviewed, a good idea is for you to make a list of all the items that you are expecting to see in that Scope and then tick them off when you come to the language that covers it. If by the end of the review of the SOW you don’t find all of the items on your list checked off, then you need to raise those as question right then and there.  The SOW becomes a binding legal contract for services to be provided. If the services you expect aren’t in the SOW, or the SOW calls for things to be done in a way which is confusing to you, then you should put the brakes on right then and there and work with the Agency to revise the language of the SOW until everything is explicitly stated.

This isn’t just a point of legal wrangling. It’s an opportunity to check whether or not the ideas that you as a Client have been taking away from the Discovery process are actually what the Agency thinks you’ve been agreeing to. All of this, of course, requires that first and foremost that you as a Client understand just how important SOW approval really is, and that you take the time to read that contract. I have had more than one client sit through a SOW presentation with Q&A period to follow only to have them later complain that something they had assumed would be done was considered a Change in Scope. When I went back over the SOW and highlighted the language which had stated otherwise, I’ve been told a couple times:

“Well, that doesn’t mean anything. I didn’t actually read the Scope, and just because I signed it doesn’t mean I agreed to it.”

Yes, actually, it does. We have nothing stronger in our culture nor more legally binding than a written contract signed by both parties. The SOW is that contract. Please take the opportunity to double check that everything you as a savvy Client are hoping to see is actually and EXPLICITLY called out in the language of your SOW. It can save you thousands, perhaps millions of dollars, and it prevents the “miscommunication death spiral” from afflicting your relationship with your Agency.  If your Agency isn’t patient enough to work closely with you to ensure that misunderstanding doesn’t creep in at this stage, then my advice to you is to simply take your business elsewhere. Agencies work for the Clients, not the other way around. If they’re not willing to partner with you on the early steps of this process, then diagnosis doesn’t look good for the buildout either.

Definition for Agencies

Agencies know how to define things, or they shouldn’t be in the Interactive business. The more exacting and precise you can possibly be in consolidating Discovery down into a Scope of Work, the better. Obviously it is in your best interest as an Agency to guide your Clients through the process as carefully as you can. One tactic I found to be extremely helpful with my clients was to not only hand the Clients the materials they needed to review, but also to tell them the kinds of things they would be looking for at that particular stage.

My standard spiel would sound something like this:

“I’m sending you the text of the Scope of Work we’ve just presented so that you and your team can review it. What you will be looking for as you review the Scope is to make sure that everything that you and the Interactive Strategist decided upon will be represented in specific language. You’re also going to need to consider the language of the Scope very carefully to make sure that there is nothing left to ‘common sense’ which isn’t included in the document. Specifically, you’re also going to want to pay close attention to all of our Assumptions, because they outline the conditions we as an Agency assume you as a Client will be operating within.  Once you and your team are confident that everything you want to have happen, and only what you want to have happen, is contained in this document, then you should send over your approval. Please understand, by signing this document you are entering into a contract for this project to be built exactly as specified in this Scope, and you acknowledge that the SOW becomes the only actual agreement for services between us regarding this project. Do you have any questions as to what the Agency needs you to pay attention to when reviewing this document?”

Is it exhaustive? Yes. Do I recommend it for every Client? No, but it never hurts to help set expectations for approvals if time permits. I certainly recommend a similar approach for any new Client the first couple of times through the process. Because as all of the Producers reading this can attest, even this kind of speech doesn’t prevent every miscommunication, but at the very least it does represent a very good effort in very good faith to reduce as many misunderstandings before they happen as possible.

Other Documentation for the Definition Phase

Both Clients and Agencies will be generating a number of documents for the Definition phase above and beyond the Scope of Work.  Producers will generate estimates to accompany all of the hours breakdowns for the project as the SOW is coming together. Those estimates are usually included in the SOW somehow to indicate the agreed payment terms, but they still need to be generated. Some shops I’ve worked at have also included Content Audits in this phase, a formal cataloging of any web site or app which exists prior to the start of the project. Sometimes the Strategic Plan includes the Content Audit materials, and other times a preliminary conceptual Site Map will be generated as well.

If the project is going to involve heavy use of databases, interactivity, or other programmed behaviors, then it becomes essential that part of the Definition phase also includes Functional Specifications, or “Func Specs” as they’re called in the Industry. If you are working in E-commerce at all or any kind of interactive project where there are lots of conditional functions or an extended data capture as the main part of user experiences (think shopping carts and complex registration forms) then you will also want to have an Information Architect or a Business Analyst sit down and come up with a series of detailed Business Rules for how the database/form/program to be built will behave.

The Project Plan

At the very end of the definition phase, once the SOW and all of the Business Rules and Functional Specifications are generated and approved by both the Agency team and the Client team, the Producer will create a document called the Project Plan. The Project Plan is where a Producer takes a look at what is promised in the SOW, how long their own team members estimate that the project will take, and the available resources available to the Agency. From all of that information, the Producer will create the Project Plan, a massive Gantt Chart which should detail every single task or project stage, what job role (or occasionally, which specific team member) will need to perform which task, and how long it’s going to take them.

The Project Plan is what separates a good Producer from a great Producer, and it’s the point at which the all-important questions about TIMING will be settled, on paper, for the remainder of the project.  Using software like Microsoft Project®, a Producer will create the Gantt chart and work to establish what’s called the Critical Path or Critical Timing. Anywhere in the Plan where jobs can be worked on in parallel will be called out, and anywhere that a strict sequential approach is necessary will also emerge.

Saving Time

Producers are constantly asked to do the impossible with regard to timing. Sometimes they can do it. Other times, they can’t. As a Producer, it’s my job to know where we can reasonably save time, and how to do it. And it’s also my job to know when the process is just going to take however long it takes. Our stock example is to say, “If it takes a pregnant woman 9 months to make a child, if I assign 8 other women to help can I get it in one?” Uhm, no.

With that said, there are lots of ways to save time, but they frequently start by asking the Client to make some sacrifices. Part of what a Project Plan needs to account for is the length of time that the Client has to review and provide feedback on any of the many checkpoints along the way. A good rule of thumb is to allow the Client no less than 5 business days to review and provide feedback on every single touchpoint. If the project is huge or the Client has more than 4 stakeholders who need to sign for every approval, up the amount to 10 business days for the first draft of the plan.

That way, if the subject of Timing becomes a controversial issue, the first concession to be made in the Project Plan will fall squarely on the Client.

“I can cut a month off of the Project Plan right now, but I’ll need you to commit to approvals being turned around in 3 business days, not 5. If we arrange this as an expedited schedule, I’ll need you to acknowledge via email that you accept responsibility for the overall project timing if approvals take longer than 3 business days.”

Usually, Clients are working against real deadlines and will happily step up their approval cycles in order to realize the time savings. Occasionally, my experiences have not gone that way. I had one client working for a new build who agreed to the 3 day turnaround time and other time-saving expedites, and then read me the riot act when I informed them that their launch date would have to move out by a week when their senior VP went on vacation and took 2 extra days to get the approvals to me. (The schedule really was that tight everywhere else that the delay impacted the final delivery date).

One of the very last places that any Producer should make concessions for timing is within the Interactive Process itself. There is a very real reason why these steps are acknowledged as ‘industry best practices’… because after trying to work without them, the industry as a whole agrees that these are the best practices for getting things done right the first time. Rookie Producers and Clients new to the interactive sphere will skip these process steps thinking that a project is simple (deceptive!) only to find out too late that the entire project has derailed because of something that would have been caught and corrected had the basic process been followed fully. I know, I’ve learned how important all of these steps are by trying to cut out almost every one of them at one point or another, and having to scramble to deal with the fallout when seemingly-simple, straightforward interactive builds went very wrong.

Sticker Shock

In the 1990’s (ahem, 20 years ago), the buzz on the streets and in the popular culture was that the internet was fast, easy, and cheap. That was true, back when the internet’s commercial potential hadn’t yet created (and destroyed) vast fortunes. Once the internet became monetized, the populist communication platform started sharing space and behaviors of a Mall. Traditional advertising always cost money, so it makes sense that now, a decade plus after the public adoption of the World Wide Web gave Interactive media a treasured place in our hearts, the pricing structures have caught up significantly.

If all you want is what we would call a “brochure site”, static information designed once, non-interactive and never-changing, then the good news is that yes indeed, you can make real cheap web sites. But if you want any bells or whistles, any interactivity, any sort of modern, updated design, any complex data capturing and optimization…. well, then you’re going to have to make an investment at least on par with the kind of investment you’re making in other advertising budgets. I had the privilege of working for one client which made the unilateral decision to scrap their entire print-based advertising budget to free up more money for their interactive advertising budget. They got more traction from the net than they would have from billboards and minipoles, by far.

In the Definition phase, one thing that’s going to be defined is the price. As a Client, you need to be realistic about your expectations or you will indeed face sticker shock. As an Agency, you really need to start preparing your Client to avoid sticker shock by discussing pricing as you go. There are dangers to this, as we all know, because when we give a number to our clients as a “ballpark” or an “estimate” the human psyche latches on to the amount, not to the qualifiers, conditionals, and assumptions which Producers surround any ballpark with. This is why my immediate response to any client question about pricing ballparks is “About 3 million dollars.” In the nervous chuckles that follow, I try to point out to them that ballparks are all about the assumptions, and that I hate giving ballparks up front because those assumptions get quickly forgotten, and then the Agency gets asked to live up to a quote which it never actually gave in the first place.

And After Definition….

It should be pretty clear to any of those familiar with Print that the Definition phase is one of the real differences between the two project life cycles. Remember, in Print the Process is flexible but the Results are fixed. In Interactive, the Process is fixed but the Results are flexible. It’s when we encounter the Definition phase, right up here in the beginning and BEFORE anyone begins to actually build or develop or design *anything* that this point really gets hammered home.

But not to worry. Once the extremely detailed Definition process is done and the Project Plan has been presented and signed off on by both parties, you will (finally!) be moving on to getting something made, in the Design phase which we will cover in tomorrow’s article.

Demystifying the Interactive Process [Part II:Discovery]

The first step we begin with in the Interactive version of the SDLC is called ‘Discovery’. This is the stage where the agency and the client both learn quite a bit about each other and about what the other thinks about the project under discusssion. Both sides literally discover what it is that’s going to happen in the next few months as they work together to bring the Client’s project to life online.

Discovery for Clients

One of the main reasons to begin with a Discovery phase is because many clients begin with less than a perfect understanding of what they actually need within the Interactive space, let alone all of the many things which are possible. In the typical scenarios I’ve seen, the Client readily admits that they’re looking to the agency to provide the expertise in a proactive manner. I’ve been told directly by my clients that “Responsive customer service isn’t good enough for us; we need you to be aggressively proactive. You’re the experts. Advise us.”

This is actually quite laudable, and to be encouraged. A statement like that lets the agency know that they are on the hook, as it were, for more than just doing what they are told. It acknowledges the advisory role that a good agency will play, even as they educate their clients one project at a time. Eventually, experienced clients will begin to even out that knowledge playing field, but educated and experienced clients are the ideal kind of clients within the Interactive arena, because of the bonds of trust which hopefully have grown to help them get to that level. It cuts down on the time needed for explanations when both Client and Agency can speak each others’ languages.

What Clients Should Expect

In the Discovery phase, you should be talking to some kind of a guru from the beginning. Chances are, if you’re working with a larger agency, that the guru will have the job title of “Interactive Strategist”, or “Account Director”. Two different roles, but both normally in possession of the kind of specialized experience necessary to help listen to the rough ideas that the Client has for the project, and who will suggest in turn possible solutions aimed at delivering the kind of project that Clients actually need.

During the Discovery process, a Client should have at least one interview, face to face preferred, with their Strategist. The Strategist should be asking questions designed to give them a clear idea of what the actual goals of the Client are. When the Client has options, the Strategist should be delivering some Case Studies of how other people are actually using the kinds of options being presented. When the Client is responding to industry competiton, the Strategist should provide Competitive Analyses, documents which provide detailed breakdowns of what interactive tactics and strategies your competition is employing, as well as how well or poorly it’s working for them.

A Good Strategist

A good Strategist will not only plan for the immediate project, but they will set some benchmarks and a general strategic plan which will ideally go beyond the end of the current project to propose some over-arching longer-term goals that the current project will provide the initial direction and foundation for. With all things Interactive, having a plan and knowing what you’re aiming for are very important.

If nothing else, ask your Strategist to help you define some Success Benchmarks as part of the current project Discovery documentation. What that means is that the Strategist should be using their communication time with you as a Client to help figure out precise numbers or goals which you as the Client would consider to be signs of a successful outcome from the interactive project. It can be quantitative (generate a 10% increase in unique visitors to the site), or qualitative (update the User Interface of the project to be more user-friendly), but before you even begin to build, you need to have your “proof of Success” plotted out. As Sun Tzu wrote in the Art of War, the Victorious plan to succeed before ever beginning to take action. The losers begin to act, and THEN plan for victory. The same applies here.

Discovery from an Agency Perspective

Whether or not the Agency actually has the staff to retain a full-time Interactive Strategist/interactive marketing specialist of any kind, Discovery is still a crucial point in the process. For freelancers or small Interactive shops, the Discovery process can be mostly informal, but I will take great pains to underline the importance of setting up clear Success Benchmarks if you do nothing else. Even without a formal Strategic Plan, you need those Success Benchmarks. Often times, the first project that any Client will work through will result in a rude awakening to the fact that the Client is working with a set of Assumptions which are not grounded in realistic expectations. The creative doesn’t look the way they imagined, or there are lots of little extras they realize they want only after the job is almost complete. By having a concrete, Client-signed set of Success Benchmarks, you remove the guesswork. And more importantly, you provide an opportunity to help intercept and correct mistaken assumptions.

Remember, Clients not only want you to be aggressively proactive, during the Discovery phase they need you to be aggressively proactive. You can’t just dupe the Client into signing off on what you know will be bad Success Benchmarks, and then hide behind the documentation. During the Discovery process, you need to present options to the Client, but you need to do so in a way which will add to their understanding, not circumvent it.

Adjusting Client Expectations From the Start

Frequently, this is where the Client’s reach will exceed their grasp. They may be able to recognize the bells and whistles of greatness that they would really like to see in their finished project, but this is also the first of many areas where it is the Interactive Strategist’s duty to begin to introduce reality into the dreaming. Part of the Discovery services that you offer to your Client is not only as a way of enriching their dreams, but also as a phase where you begin to aggressively and proactively set their expectations to be grounded in the harsh reality that the Interactive Producer will be quick in forcing them to face when the next phase, Definition, gets underway.

Or, as I like to put it, before you can prep the Client for a successful launch, you have to get their visions on the ground, first.

How Long Does This Take, Anyway?

Discovery is one of those curious phases… it’s not technically required for every project. There are projects where the focus is mostly execution, not strategic planning. However, Success Benchmarks are essential for every build. Discovery, then, will last anywhere from a few hours spent drawing up and getting Clients to approve their Success Benchmarks, to months of planning sessions. It really depends on how knowledgeable and experienced the Client is, and how aware of the Interactive SDLC they are.

For that reason alone, it’s always best for Clients to come to the table asking how long Discovery will take, and more importantly, how much the Agency thinks it will cost.

Cost?

Yes, cost. During Discovery, the Agency is providing you with access to an Expert. Experts are not cheap. In fact, on most Interactive Teams, the Strategist is one of the highest billing specialists you’ll deal with. In professional agencies, expect the bill to run upwards of $275/hour of their time, and Strategists as a rule don’t like to rush. They are entrusted with developing an overall strategy for how the Client will make money off of the internet, and that’s not something you would WANT to rush. Nor is it something you would want to linger over, either.

Discovery is the first pain point for many Clients because this is where a good agency will make certain that the Client’s illusions are swiftly deflated. This is where the cold hard reality begins to set in… the hype that you heard in the 90’s about the web being fast, and cheap? Not the case any more. Nowadays, just like everything else, you get what you pay for.

Discovery is also the phase where the costs should theoretically go down the more knowledgeable and experienced that the *Client* is, because Clients can and often do come to the table with the Discovery phase already taken care of in-house, or by another specialist that the Client hires directly. This can backfire sometimes, but in general, the more the Client understands the Interactive process and how to maximize their use of the Interactive medium, the less time that the Agency has to spend informing and adjusting Client expectations, and the more time that the Interactive Strategist can just ‘plan the work’. If there’s already an overaching Strategy Plan in place, then subsequent projects within the same Strategy can effectively minimize the time and money spent in the Discovery process.

That never means you should completely do away with Discovery. As much as the more tactically-minded clients would balk, you ALWAYS want to see an Interactive Strategist putting an hour or two toward your project. As an Agency, you always want clearly defined Success Benchmarks to be working against. As a Client, you always want someone who knows your account and has the overall plans for your interactive development clearly in mind from the beginning, to avoid duplication of efforts or working at cross-purposes to your established Interactive goals.

The End of Discovery

At the end of the Discovery process both sides will gather everything that was learned in the Discovery phase and they will boil it all down into several documents. Once you’ve begun generating the kind of documentation for the project that will actually define all of the elements of the project, you are moving from the Discovery Phase to the Definition Phase.  We’ll look closer at Definition in tomorrow’s post, but for now keep in mind that perhaps the single most important document to be generated out of the Discovery and Definition phases is the Scope of Work. Chances are there’s already a Scope of Work of some kind in place to cover the Discovery and Definition part of the project (because how else will you know exactly what you’re paying money to the Strategist for or how long the process will go on without a SOW?) in which case the Definition phase will often produce an Adjusted SOW, or perhaps a Project Plan based off of the SOW and what was decided upon in Discovery. Even if your Agency doesn’t separate out Discovery from Definition, when you start talking about things like Sitemaps, Project Plans, and [adjusted] Scopes of Work, you’re moving on from Discovery and into the Definition phase.

Discovery is one of the most fundamentally important phases in the Interactive SDLC. Without it, the initial Risk level for the project jumps by 50%, at least.  Even if you don’t have a formal Strategist, or a formal Discovery phase, do NOT consent to the beginning of ANY Interactive project until and unless both Client and Agency agree upon and sign off on specific, results-oriented Success Benchmarks. Just don’t even begin until you both agree how everyone is going to determine whether the project was a ‘Success’ or not.

Trust me. It’s the most important step for the Discovery phase as a whole. Ignore the Success Benchmarks, and you’re already setting yourself up for failure, because at that point, the Client is free to declare ‘failure’ on anything, for any reason whatsoever. And on the other hand, the Interactive Agency can declare ‘success’ on anything, for any reason whatsoever. If you want to avoid lengthy post mortems and arguments over who said what when to who and just exactly what context it was used in… then take the time to establish your Success Benchmarks for all stakeholders.

Next up, Definition!

Demystifying Interactive Process [Part I:Introduction]

When you want to build something that will live in the Interactive space (internet, web, mobile media, web 2.0, social networking, etc.) there’s a set of basic steps you need to follow in order to complete the project. Those steps have been culled from what’s called the SDLC, or Software[Systems] Development Life Cycle, a pattern which has been used in software and network systems development for years prior to the adoption of the same basic principles within the arena of commercial Interactive projects.

There are many variations available out there and in many cases the actual steps of the process will be determined entirely by the specific needs of the kinds of projects you’re building, but in general you can render down the SDLC as it applies to the Interactive space by considering a model called “The 5D’s”, even though it’s got two M’s in the very end.

The 5D’s Interactive Process

The phases of the so-called 5D process break down as follows:

  1. Discovery (exploring want vs. need, could vs. should)
  2. Definition (setting expectations through uber-specific documentation)
  3. Design (planning the architecture of information, experience, AND traditional visual Creative)
  4. Development (putting the plans to work, coding the behaviors)
  5. Deployment (getting it from Development environment to Live)
  6. Measurement (tracking metrics and analyzing them against success benchmarks)
  7. Maintenance (updating, upgrading, and minor edits to existing functionality and content)

Note well that there are actually 7 steps, and more than just the letter ‘D’ used to describe them. But it started with just the 5D’s, and got Measurement and Maintenance thrown in as logical followup steps to acknowledge the fact that interactive projects require more effort beyond ‘Deployment/Launch/Go Live’ to consider the project successfully completed. [Props where props are due, the two additional ‘M’ steps were added on the recommendation of the inimitable Elisa Carson, a very wise and savvy Interactive Producer I had the pleasure of working with at a past job.]

In the series of articles I have planned, I’ll be looking into the 5D process day by day and outlining some of the basic items which need to happen at each stage, as well as what kinds of professionals will be involved in the team as each phase happens.

A Resource for All Clients and Interactive Professionals

There’s a certain class of Interactive Professionals who are employed in specifically designed Interactive shops which eat, live, and breathe the 5D’s or some other house-grown variation on the SDLC. This won’t be of any use to those privileged few, the proud, the lucky… but what about the rest of the world who may or may not be involved in Interactive builds for very much of their job duties? What about the poor administrative assistant who ends up doing all the coordination work to help her too-busy-to-learn boss keep the new website project going? Suddenly “Web Master” duties are getting farmed out to already overworked corporate professionals. And what about small businesses operating outside of the ‘professional Interactive space’ who want to utilize the internet to help them make money, but are frankly put off by the Technobabble that usually accompanies such endeavors?

This series of posts is aimed intentionally at a broad audience. As such, we’ll be looking at this from a high level of general steps. Each house, each developer, each studio, and certainly every Interactive Producer has their own specific process which has developed to help them build the things they build for the clients they work with. But I dare say that the overall phases of the process outlined here should be present in more or less this order for every Interactive job that gets developed. It streamlines things, it manages expectations, and it includes all of the “best practices” of the overall industry.

Follow along as we go over the basics for the next week or so here at Internet Kerfluffle, and hopefully this will help get everyone using the same words, with the same expectations, for the same steps.

Special Case: Those Familiar With Print Process

As a former graphic designer with over a decade of experience in the Creative and Production realms for ‘traditional media’ (e.g. Print, or ‘offline’ media), my first exposure to Interactive was working as an Interactive Producer in an otherwise-completely Print-based agency. The results were disastrous as expectations went kerplewie and project budgets immediately either ran overboard big-time, or else clients were unhappy with their results, 9 times out of 10. It was that experience that led me to find my training in grad school for a Masters of Interactive Communications from Quinnipiac University (detailed on Graduate Interactive Communications, my grad school blog for those who want to poke around a bit into my experiences there).

While I was studying full time on nights and weekends in the professionally-based MS program all about understanding the business of the Internet, I moved to another job with another historically print-based marketing and promotions agency, where I would frequently get into shouting matches with my coworkers on the Account side because of the impossible things they were expecting as a matter of course. The experience took some getting used to, but by the time that layoffs came for the entire department  I had learned some very important things about the difference between the Print process that all of the agencies in Connecticut and their clients were used to, and the Interactive process.

I can boil down the main difference as follows.

  • In the world of Print, there is great flexibility in the process of developing materials. Once the materials are launched, however, the results are fixed and cannot be changed, only re-done from the beginning at great expense.
  • In the world of Interactive, there really is NO flexibility in the process of developing the project. Yet once the project is launched, you have a lot of flexibility over minor changes and updates.

Before my colleagues jump on me, let me explain what I mean by ‘NO flexibility in the [Interactive] process’.  Obviously, when looked at entirely by itself, there’s always going to be some measure of flexibility to any process. But when you compare it to Print, you can begin to get a better sense for what I mean.

Print Emphasizes Form, Interactive Emphasizes Function

In the world of Print, you have a date by which the materials need to be in the market, and you have your printer telling you how long they need the files in advance of that date in order to make it to market.  There is no question in Print what the final product does. It displays, wherever it is put with whatever gimmick it’s got to make the target audience look at it, and consider doing what it tells you to do. (Drink more Ovaltine™!) Up until the date that the Printer needs those final files, and sometimes even a bit after that, the Client and the Creatives and the entire project team can change every single thing about that project — what it’s going to look like, which products will be featured, what the headlines say, where the Call to Action message is, what color the background will be, etc.

Once it’s printed, though, those particular posters, or newspaper ads, or billboards, etc…. they exist. They’re done. You can throw them away and print new ones, but you can’t really change what you’ve already done. You have to start over again with different files and print whole new different posters.

Thus, PRINT = Flexible Process, Fixed Result.

In the world of Interactive, things are quite a bit different. Opposite, really. In order to determine the date that you’re going to be able to get Interactive projects into the marketplace (e.g. Launch/Go Live date) you need to count -forward-, not backward. And what you are counting forward from is nothing less than a completely detailed and 100% specific definition of EXACTLY what it is that you will be building in the interactive space, and more importantly, what it’s going to have to be able to do. You can change the process, but EVERY decision you postpone until ‘later’ in the process creates higher and higher risk that the entire project will derail, run late, or become VERY expensive, VERY quickly (and needlessly).

The reason for the difference is that in Print, the end result is a Thing that gets provided by someone else. That Thing already exists. Everyone knows what it does. It provides a surface to hold the Creative being Printed. In Interactive, you are building a miniature piece of software. If all you want is something to hold the Creative being Printed, then you’re in luck because those are the easiest kinds to build. But once you want to actually take advantage of the bells and whistles, the interactivity and responsive behaviors that online information software like web sites have to offer, well then you’re going to have to be very specific extremely early on in the process.

Unlike the world of Print, in Interactive there’s no such thing as successfully starting a project without knowing exactly what you’re going to end up with when the project is done.  In reality, in the world of Interactive, what you are ‘launching’ is not the message, it’s the medium itself. Once a web site is up and functioning as planned, you can go back into the exact same project and update things… so long as it doesn’t “break” the functionality or the overall organization built into the site when it was developed. You have a lot more control over the basic parts of the project even after launch. But before you can even begin to work, you really need to know exactly what it is you’re going to do for the end product.

Therefore, INTERACTIVE = Fixed Process, Flexible Results.

What That Means For You

In a nutshell? It means that for any Interactive Project, the more specific you can be about things the earlier in the process, the more likely it is your project will be successful (which is defined by all Interactive Producers as ‘on Scope, on time, on [budget] target’. The more that you leave things open (and woe to you if you Interactive agency allows you to leave things open for long beyond the Discovery phase) the more likely it is that you will run into endless Change of Scope updates, budgetary overruns, and timing delays.

If you or the boss you work for is thinking, “We need to launch Project X in six months, we can just start the Agency working now and we’ll finalize plans in the next month or so,” that is a huge red flag of danger. If you want to save the day for the entire project, right then and there say the following:

“Let’s check with the agency and see if we have room in the schedule for a 2-month Discovery phase.”

Really, it’s that simple to avert disaster. To see why, check out Part II where we’ll discuss what a ‘Discovery’ phase is, and why they will save time and money in the long run.