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.