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.

Advertisements

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.