The BEST Facebook Comment Thread EVER

Long string of facebook comments

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.

Drew Tal

Porcelain Promises by Drew Tal

Porcelaim Promises by Drew Tal

I’ve been meaning to do a quick post on this artist for a while now. Drew Tal has a show that’s being advertised along my commute to work. I used to do fine art work in ceramics myself, so I love this juxtaposition of cultural icons. Some very nice and provocative work on his site. Check it out.

Return soon

I know I’ve been in the middle of my ‘Demystifying the Interactive Process’ series of articles. I’ll come back to it soon. Been adjusting to life without a car and freelancing as an Interactive Project Manager in Manhattan. Between commute/mass transit and my day, not much time for finishing blog posts. Will be back online again soon.

Memories of Concepción, Chile

I spent 2 months in Concepción, Chile, in the summer of 1992, as part of study abroad. I wanted to go far off the beaten path. I wanted to be away from other US college students. And I certainly was. Let me frame it for you a bit… 1992, the dictator Pinochet had relinquished his direct control over the Chilean government a few years earlier, and the Chileans were coming out of a cultural period defined by Fascism, a fascist regime which had been in the business of suppressing collegiate uprisings, disappearing thousands of people, and imposing strict rules which have left an indelible mark on the Chilean social scene, at least as I found it in 1992 compared to the free-wheeling, pre-9/11 devil-may-care US cultural naivete I had come from. Bill Clinton was the front runner for the presidential elections in the US and had attracted the attention of the Generation X by playing saxophone on the campaign trail. Reaganomics were finally coming to a close, and there was a real sense across the globe that finally, the Americans were coming to their senses and turning away from ridiculous Republican-based foreign policies. (Their words, not mine. I just happened to agree with them).

Culture shock set in big time for me, and I felt perhaps the most isolated and alone that even Gen X loner/slacker me had ever felt. But I still tried, and since there were only 2 other gringos in their 20’s in the entire city of Concepción at that time, we tended to draw attention. I paid a visit to the American Institute in Concepción, part of our cultural outreach in sympathetic nations, I guess. There are American Institutes all over the place outside of the US, or at least I was told there were when I went there. Wealthy Chilean school children went to the American Institute for culture classes, part of the ‘outreach’, I guess. I just knew that by my second week there, I was starved for some American culture, so I stopped by to visit the Institute and talk to some of the instructors and students there.

I remember standing in the upstairs hallway waiting for one of the professors who wanted me to talk to their classes, and having a gaggle of Chilean school children come up the stairs together. They saw me standing there, and although my hair is medium brown I was considered by several Chileans as ‘blond’. With my Scotts complexion and height of 6’2″, I stood out head and shoulders, literally, over many of the Chileans. The children stopped together as a unit and stared, perhaps no older than 6 or 7 years old. Then, when one of the adults shepherding them tried to get them to keep walking, they pointed to me directly and said, “He’s a giant!” It made me want to bellow out “Fee, Fi, Fo, Fum!” but I guessed that it wouldn’t have the same cultural translation, so instead I just smiled and waved at the children as they passed by, unable to tear their eyes off of me as I said ‘Saludos de los Estados Unidos’ (Greetings from the US) as they walked by. Their guardian adults were all laughing over the reactions, and I was too.

An Extremely Rich Culture

Chile was not what I expected. I had been carrying around stereotypes of 3rd World nations in Latin America, and I landed squarely in a definitely 1st World nation, and one of the richest in the world, but not necessarily in monetary wealth. In Chile, I ran into quite the interesting cultural phenomenon. The people in Concepción, at least, would remark about things in terms of how ‘rich’ they were (¡Qué rico!), but when they used that phrase they were never talking about material goods. They were speaking about experiences. Flavors. Views. Emotional responses. Artwork. Theater. Movies. Anything experiential. Concepción literally conceptualized ‘wealth’ and ‘riches’ as being cultural experiences, not items to possess. Oh sure, being a 1st World developed nation, Chile had their version of consumerism and materialistic importance, but the people as a whole had not given up on the notion that the best things in life weren’t things. Exposure to that attitude has stuck with me quite a bit throughout my adulthood.

A Symphony of Street Sounds

I had been a music major prior to becoming a Spanish major, so I carried with me the notion of listening to the sounds of my environment, intentionally. Different places sound differently, and Concepción was no exception. Like most Latin American cities, Concepción had its official, main Plaza, a public commons area which formed the conceptual heart of the city, if not necessarily always the economic, cultural, or geographical ‘center’ around which the city revolves. The Plaza in Concepción was huge and arranged in a circular pattern of wood and wrought-iron benches around a massive stone fountain. The Plaza was faced by the city’s official (Catholic) Church/Cathedral (much smaller scale than the Cathedral in Seville, Spain, but about the same size as St. Patrick’s Cathedral in NYC). Government buildings, courthouses, a Community Center/Theater, and movie theaters also ringed the Plaza, most likely paying dearly for the Plaza-front real estate.

On the other side of Concepción was the University. The University’s main gate was the end point for the only street to cut diagonally across the city, named simply ‘El Diagonal’. The Plaza connected to the University Gate where the Diagonal boulevard ended by means of a very busy, bustling street which seemed to form the economic heart of the city, at least in terms of retail businesses and restaurants dependent on foot traffic. I bring this up because I used to catch a bus into Concepción from the Villa San Pedro across the river Bio-Bio, where my host family and I lived. I would often get off the bus at the Plaza instead of the University, and I would walk across the city on that one street… just to hear a veritable Symphony of Street Sounds.

At the Plaza, the sound of traffic was muted because traffic diverts away from the Plaza when it comes to automobiles. The Plaza is really more for pedestrian public. Or it was, 20 years ago. The bells of the cathedral tower would chime and resonate over the sounds of the falling water when the fountain was turned on, and the cooing of pigeons in the park. As well, the shoe-shine men would circle the park looking for businessmen who wanted their shoes shined. They would circle the rows of benches with their shoeshine boxes and brushes, tapping the handle of the brush against the box while they would politely ask anyone who sat still long enough whether or not they wanted their shoes shined. In my mind, the Symphony of Concepción begins with the fading sound of traffic, the tolling of the bell towers, the cooing of pigeons and the fluttering of wings as the shoeshine men tap and call to the public, asking them plaintively “¿Límpialos? ¿Límpialos?” (Meaning “Shine ’em? Shine ’em?”) while falling water provides the background tempo.

If you then start at the fountain and walk away from the church, down to the side street which connects the Plaza with the University, the natural sounds of water stop falling and get replaced by the babble of the crowds. At the edge of the Plaza the lepers would gather, pitiful men and women sitting on the sidewalks with a small paper cup nearby, calling out in singsong misery, begging for the kindness of strangers. “Una monedita, una monedita por favor” is how their chorus goes, slow and lamenting, a visual reminder to be thankful of what you’ve got.

As the beggars and lepers begin to be heard, you immediately will hear a strange chorus of rapid, sustained, and loud clicking sounds as the street vendors walk up and down outside of the bustling street with little plastic children’s toys in their hands, looking like a white plastic stick with two sets of plastic balls attached rigidly to the stick on joints to pivot. They would put five or ten of these little clicker stick toys in their hands and walk around by the edge of the Plaza and the busy street, and they would shake their hands back and forth to make the two strips of hard plastic balls clack together over and over again while they simply announced the price to passersby. “¡Trescientos pesos, solamente trescientos pesos!” (‘300 pesos, only 300 pesos!’ about $1 US at the time). The clattering of the tchotchki salesfolks would emerge in waves of noise and sound punctuated by silences every time they made a sale. Taken together, they sounded like a strange omnipresent set of Urban Cicadas, droning out the poignant cries of the wretched leperous beggars as you walked farther along the street.

Just when the clatter toys and salespeople seemed to rise to ascendency against the growing sound of the street, you would walk up closer to the Keno booth, an official Chilean lottery which ran every 10 or 20 minutes similar to some NYS lottery games. Just before the periodic Keno balls would be broadcast to all of Chile, the salespeople would shout out into the crowd, “¡Keno Keno Keno! Keno. ¡Keno Keno Keno Keno!” They tended to either bark out in patterns of three or patterns of four, which when put together forms the basic foundation of all polyrhythms, a pattern of three against a pattern of four.

The Keno barkers, backed by the clickers, get joined by the rest of the chorus of people advertising all of the restaurants that exist in the upstairs spaces over the little merchant stalls and retain shops. The primary fare didn’t vary much from restaurant to restaurant, more like a string of mom & pop diners all serving pub grub or diner fare, but Chilean style. Barking to attract customers seemed to be the way of things, because every restaurant along the street did it, and eventually I figured out that I got better service and better prices when I became a ‘regular’. Normal cuisine for lunch was either “Bird sandwich with avocado” or “Steakums with avocado”. Or hot dogs. Chileans *love* hotdogs. They call them ‘Completos’ (Completes) and they serve as an excuse to eat tons of condiments. Mayo being one of their favorites. It’s sort of like the ‘Taco Bell’ phenomenon… the food looks like the real deal, or at least takes the name of the real deal, but it’s vastly out of cultural context or anything else recognizeable to the native culture. Hot dogs are Chilean junk food, and they *love* them with a passion that puts the American hot dog to shame. To shame!

By this point the auto traffic has also picked up, so honking horns get added to the chorus of people and city noise, now in full crescendo. The hiss of air brakes from diesel public transit buses joins the fray, and the candy-sellers who hop a ride on buses to offer a plethora of chocolates and caramels and crispies for the inflated price of 300 pesos called out a repeating chorus of “¡Dulces! ¡Chocolates! ¡Dulces! ¡Chocolates!” (‘Sweets! Chocolates!’)whenever they would establish eye contact with a member of the public.

By this point the noise of traffic overwhelms the Symphony, since we are arriving at the point where the Diagonal comes to rest outside of the pedestrian-only University of Concepción campus gates. The traffic fades too as you cross onto the campus, and cars are replaced with the sound of college students, meeting and kissing (everyone kisses everyone else of the opposite gender, sometimes of the same gender, it’s how they greet) and laughing and shushing themselves, the droning sounds of lectures and the movement of people en masse between classes. A peaceful sound, punctuated with livelihood here and there. Bird song returns, and by the time that you pass by the massive Campanile, the sound of academic bells tolls the hour. By the time you reach a small public memorial area designed to allow for large crowds to congregate, you will hear the gentle lapping of the water of the lowest level of this little outdoor forum. Water tinted black among the lowest level of where the crowds would gather, and did gather in the 70’s, when Pinochet came to power and supposedly massacred a group of communist students who had convened there to stage a protest. The water on the lowest level tinted black was a memorial to those fallen idealists, and had the urban legend among the students of being tinted black because it was impossible to remove the blood stains from the concrete.

There, with the fading sound of bells and barely perceptible sound of the lapping water, the Symphony ends at a monument to lasting freedom, surrounded by the bored disinterest of the modern Chilean college students as they shuffle past on their way to classes.

Those were the sounds of Concepción as I knew her. I would get off at the Plaza and walk the length of the city every day, just to hear the Symphony played out, over and over again.

My Host Family

I don’t know whether or not my host mother has survived. We lost touch about 18 years ago when I cut short my stay due to extremely bad financial planning and extremely strong culture shock. I reached out to her once since then via email, but in my enthusiasm I think I ended up with diarrhea of the mouth and just sort of overwhelmed her with TMI, or bad translation attempts when I tried to write in Spanish again after 15 years without practice. We chatted the once and then no further responses. Which is fine, she’s certainly entitled to her life without the briefly associated college exchange student bothering her further. She and her family will probably never realize just how important a role they played in my own development toward adulthood. Which is as it should be, I suppose.

I’ve lit a candle for her. For profesora Marta de las Nieves Contreras Bustamante and her son, Félix. I’m hoping they were not in the city proper when the quake hit, but instead were at home in Villa San Pedro, on the southern shores of the Rio Bio-Bio. That’s assuming Félix is still living out of his mother’s home, and not off in University or studying abroad, or living with his father now. I don’t know whether I’ll ever find out if they survived, but my thoughts are with them, and with all of the Chilean people affected by this earthquake. That house had been built by her father, and it was more than just a room I rented while I was studying abroad… that was my home, too, if only for a short time.

I was only in Concepción a brief time, but it was a formative time. An essential time. It was, and always will be, an experience I can only describe en la manera de Concepción…¡Qué rico! I join with the millions who look to Concepción now with hope that the beauty and richness of the city finds a way to survive in the hearts and minds of the Chilean people once again.

Demystifying to continue… but…

Just a quick update note for anyone who has been following the article series ‘Demystifying the Interactive Process’… our Friday installment is going to be delayed. I was in an automobile accident Wednesday morning and I am still recovering. (The last two posts had been written and saved to be published previously.)

I’ll post updates about it once the insurance claims have been resolved and paid out. Meanwhile, enjoy your snowy Friday, those of you in the greater NY Metro area and surrounding Northeastern areas.

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 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 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.