I’ve been working full-time at (add)ventures since late 2007, but thought it would be worth it to share my thoughts on the process of interactive projects. When I was interviewing at (add)ventures I was asked the question ‘how do I tackle interactive projects,’ and this got me thinking about not just the steps, but the philosophy behind them. While I think this might have been more than was anticipated, I thoroughly enjoyed the process!

Untangling the Web of a Site Project

Undertaking a web project of any size requires a number of steps and disciplines. While the time and resources required may scale with the project, the steps and skills necessary stay largely the same. In order to present the process in a clear and cohesive manner, the following narrative has been laid out. For smaller-scale projects many of these steps may naturally fold together, or be accomplished in an afternoon work-session rather than days, weeks or months. The initial request for a proposal or project brief will go a long way to set the stage for what is to be developed.

Some Tips

Research, educate, present. Map thoroughly - both topographically (what content lives where and connects to what) and by scenario (who is using it and how will they move through it). Never start with the home page.

Study the Client

To discover what is important and relevant, one must learn everything one can about the client’s:

• Brand
• Audience (demographics and typical behaviors)
• Marketing goals
• Business/strategic goals
• Current site and technologies
• Competitive landscape - what are similar/competitor companies doing?
• What do they think they want to do?
• Ongoing needs - do they have staff/‘will’ to support what is undertaken?

Once the answers have been gathered, develop broad-stroke strategies with regard to content, stylistic and technological foundations. While content and application ideas should certainly encompass what was initially presented, there will likely be a number of areas where further development could greatly enhance impact, reach and return on investment. Finding ways to connect as-yet-disparate areas of the client company creates vastly greater opportunities to turn interesting ideas or novel concepts into measurably successful marketing and business initiatives.

Present the overall vision in a working-group meeting with appropriate stakeholders. Gauge response, start a dialog and discuss it. The best ideas don’t matter if they are not well understood and received. Educate where necessary and appropriate, but don’t condescend. Real-life metrics carry infinitely more weight than abstract concepts, so relate ideas to reality in concrete terms wherever possible.

Now three tracks of work can develop in parallel: visual design, information architecture and technology recommendations.

Track I: Design

Visual style and language should be designed and presented in a traditional manner - develop three very different approaches, with three example pages of each approach. Remember that prior to this the client should provide guidelines for branding, color palettes and typographic treatments. Never present a home page - you can’t possibly know what it should include at this stage. Takeaway from this presentation should be the approach that is best received, along with notes about any features or aspects of the other two that are successful, and any aspects of the winner that are not.

[img_assist|nid=27|title=Final Design|desc=|link=popup|align=right|width=210|height=274]From this three new variations should be developed, again with 3 example pages of each. Care should be taken throughout to ensure that no designs are presented that will be unreliable or impossible to produce, and that the example pages for every approach contain the same content and features. It’s too easy to get sidetracked by content or functionality - that’s not the aim of this process. Present again with the 3 new versions. Put things on paper. Bring scissors and markers. By immediately putting marks on the printouts it removes any sense of ‘doneness’ - it’s important to convey this as a working process, not a choice of fixed alternatives. The takeaway here should be a relatively finalized design style and language. There are always refinements, and new icons or language to expand upon. But a final revision based on this meeting should get physical sign-off from appropriate stakeholders so that the process can move forward with authority.

Track II: Information Architecture

The second parallel track involves structure and usage. Mapping the content that needs to be a part of the site is a necessary step. By visualizing the breadth of content on a larger scale it is much easier
to see gaps in existing content, areas of duplication, opportunities for reuse and new ways to understand the scope and structure of the site. Along with the mapping process, user profiles should be generated. Are there different kinds of site users that comprise their target audience? Do they have different needs and styles of navigation? Examples would include current customers versus prospective ones; younger, more tech-savvy users versus older users more likely to approach a site in a more linear fashion; public users versus internal administrative ones. These profiles can be generated based on demographics, goals and features. They become personas against which style, language, features and functionality can be judged. A site might not be able to be all things to all people, but it has to stand up to the rigors of everyday use and access, both internally for administration and maintenance as well as externally to serve the needs of its visitors.

Content map for North Sails One Design International site

Usability

Underlying and informing the process of the first two tracks is a crucially important element that spans these two areas: usability. It is easy for seemingly good design to be poorly usable; likewise content groupings that make sense within the context of the client’s internal business units may not translate to intuitive navigation to an end-user not familiar with that structure. Part design, part logic, part psychology: usability encompasses all these things, and when done well makes good design great, and makes navigating a website second nature even to first-time visitors. The best sites’ designs are great because the designs serve the content and user: not the other way around. Design must lead the viewer to the content, and let the content be the most important thing on the screen rather than competing with the beautiful shiny graphics comprising the navigation. Organization of the content must fit the goals of the user: why are they there, and what do they need to accomplish? Testing should take place at every stage of the project. It can be more or less formalized, but until you put a design, a map or a prototype in front of a few people not connected with the project you will never really know how the average user will react. Results may reinforce or contradict assumptions made to this point, and waiting to find this out after launch could be disastrous.

The ‘Home Page’ Dilemma

Design of the initial page of the website can be a volatile and controversial conversation in and of itself. Once the content for the site has been mapped, marketing and business goals discussed, and a visual language define, then it is time to start this conversation. Have stakeholders make lists of what they feel should be there. Present your own list, compare them and prioritize. The editing and removal process is almost as important as the initial lists. It must be clear, useful and engaging without overwhelming the user. This is a difficult process, and it is to be hoped that the trust built up during the agency-client relationship thus far will lend credibility and authority to final recommendations.

Track III: Technology

[img_assist|nid=23|title=Video capture hardware architecture|desc=|link=none|align=right|width=250|height=640]The third track can often be partially dictated by internal requirements of the client: technology standards, accessibility needs and stated business goals all must be considered. While it is true that many underlying technology choices can yield similar results, they have dramatic impact upon time to develop, budget and maintainability. We may have recommendations that we feel strongly about, but if the the internal IT department has a standardized platform or existing skillsets then there must be a very good reason to recommend alternatives. Making decisions early and well in this area will have a huge (and hopefully positive) impact on the success of the project and the relationship. Alongside the decision for development platform comes recommendations for specific applications. Content Management Systems (CMS) make a lot of sense in almost all cases - keep the design intact while allowing the client to update most content on a day-to-day basis. It rarely pays to be in the business of updating content, and even if the agency does do the maintaining, it is far more easily handled through a web browser than by updating myriad pages of static HTML. There are enough options in this arena that there should always be an appropriate choice to be found. Besides basic content management what opportunities are there to find the ‘killer app’ that will drive enthusiasm and return on investment? It is to be hoped that there will be more than one, but I think it’s important to find the first and really make it worthwhile.

The simple truth about web projects is that quite often the budget required to produce a good marketing site is still quite a bit higher than expected or desired. However, with a creative and holistic approach to incorporating some internal business process automation that ties well into public-facing initiatives, much greater value can be derived from the proposed solution. This provides solid metrics and real numbers to compare favorably against what often is only a modest increase in the overall budget.

A great example of this is taking the marketing brief to create a downloadable customer rebate form and making it something that can be submitted directly online. Connect that to a protected internal page and email notification so that accounting staff know right away that a rebate has been submitted. Rebates can be issued and status recorded on that internal page, and formatted reports can be automatically generated from the collected data. A once-disconnected set of tasks taking hours a week for several different employees has now been consolidated into minutes, and their customers have just had their satisfaction with the level of service received has just increased ten-fold or more.

An application such as this could end up only adding 15-20 hours of design and development time - a small portion of an overall budget - but would present a productivity savings of up to $3-5,000 annually or more. More importantly, it breaks the boundary of the project existing solely as a marketing exercise and starts to involve other departments. I truly believe that website projects can only become more valuable and beneficial to the client when their business is considered as a whole. There are inevitably countless ways that burdensome tasks can be streamlined with web technology. It may not be appropriate with every project, but by taking the time to educate the client about those benefits they will be far more likely to consider it the next time a horribly repetitive task starts to eat up hours a week of their time.

Track Summation

One more important point to make about these three parallel tracks. It is generally best to never combine meetings to discuss them. Even if you simply plan a break between sessions, it’s important to consider them separately. Design discussions can too easily be sidetracked by whether or not someone likes the content used in the example page - so having content inventories or maps on the table can quickly draw focus away from necessary decisions. Likewise it may well be that few of the people you have in the room for evaluating use-case personas will have their eyes cloud over within 30 seconds of the discussion turning to the relative merits of Object-Oriented development methodologies, operating system vagaries and Agile approaches to project as a whole. Different tasks, different stakeholders, different meetings. It’s just much clearer and more productive that way.

At this stage of the project there should be several documents that have received official sign-off with the client: example designs complete with logo, color and type specifications and a style guide for the site. A thorough map of the content for the site along with an itemized ‘content inventory’ will serve as a checklist during the remainder of the project. Finally, a set of requirements for hardware, operating system, software and application platform should be set out in detail. Plans for a Content Management System (either an existing one or one to be developed), specific applications outside the existing CMS that need to be developed, what existing internal systems need to be connected with and how all need to be mapped out in as much detail as possible.

Pitch vs. Project Plan: Do you have the job yet?

What is not always clear is how much of the above must be done as part of the initial pitch in order to win the project versus what becomes next steps in order to define the scope of work and final budget. A certain amount of work will doubtless need to be done to get the job in the first place, but there is a lot of value in the application specification process and it needn’t be given away. While enough needs to be done to come up with an initial budget range, it has been my experience that rarely is enough known from the initial meetings to accurately forecast the time and expense required to fully implement some of the custom or more involved applications. Fortunately much of the rest of the project can be defined and budgeted, so with a carefully worded and presented proposal, additional expense for unforeseen complications can be handled.

It is also common for the detailed application specification work to be broken out as a separate consulting contract undertaken as it’s own project. The deliverable can be a document serving as a blueprint for production. With a new client, this can also serve as an introduction to the agency’s capabilities and greatly increase confidence with the agency and thereby make it far more likely the agency will win the larger project designing and producing the entire site. The danger that the client will take that deliverable and go to another company to produce it is mitigated by the fact that it has been handled as a separate consulting contract (generating income before winning the larger project) and is further outweighed by the goodwill and confidence engendered with the client by delivering a competent analysis and professional specification.

Now What?

A design has been created, content mapped and an application framework has been selected, with detailed specifications documenting all specific features and functionality required including all client systems that need integration and how that will be accomplished. At this stage a determination can be made about whether or not an external vendor will need to be involved for production. Smaller and/or simpler sites may only require ‘slicing’ the designs into solid HTML and CSS (the code and style for the page layout) and integrating with an existing CMS, while more complex sites may require addition development of the graphic language and style to accommodate more features and functionality. If custom application development or other programming is required then further work must be completed to create a ‘Functional Specification’ or ‘Requirements’ document. This would be a very detailed usage scenarios, any specific requirements for data to be collected, used or interrelated, and specific use cases for the various ‘personas’ (sometimes referred to as ‘actors’) developed in the initial phases of the project. This helps visualize how different users will interact with the project when deployed.

At this point, as initially, there are several different tracks proceeding somewhat in parallel. The design must become presentation; content must be gathered and/or developed and organized; the underlying technology must be developed and put in place. Whether this takes days or months depends on the scope of the project and the level of organization and planning that has taken place thus far.

Presentation Layer

The visual design for the site must be turned into presentation: the graphics, HTML and CSS elements needed to turn the application framework for content management into the website with the look and feel initially designed and approved. Integral to this process are accessibility and search engine optimization (SEO): how the HTML and CSS are structured and applied make all the difference in how well or poorly the site displays to different users - browsers, platforms (on the desktop or in their hands), sighted or not all are impacted by these choices. Search engine ‘bots’ are another category of user that benefit from this work: making navigation that works for a screen reader also works well for search ‘bots.’ By making further refinements to where content is placed in the page and how it is marked within the HTML results in search can be further improved. Other aspects of SEO are addressed in programming: automatically incorporating keywords in page headers and using ‘search engine friendly’ link and URL structures also make a big difference.

Content Development

Content for the website is a much more two-sided conversation with the client. Quite often much of what is needed for the site already exists within the company somewhere, and depending on scope and nature of the engagement may require a lot of iterative work with the client. If the agency is being tasked with writing the copy for the site the requirements are a little different, but there are still many common elements. From the the initial stages there exists a ‘content inventory’ which can be further developed into a set of outline documents. It is generally less intimidating and more approachable to have measured doses of content that needs collecting or generating rather than have the whole lot dumped on any one party. The outlines can be used to collect content or at least content notes. From here it may be the agency’s job to craft well-constructed content, or it may be that with the agency’s help, individuals within the client company can be trained how to write copy effectively for the web.

What is often missed during this phase is consideration of how people tend to read while browsing. Writing for a good newspaper is a far better stylistic analogy than any other form. People tend to look for the quick ‘gist’ or skim. Usage of well-chosen headlines, subheads and pull-quotes greatly enhance the experience (and the likelihood that the content will be read at all), not to mention also aiding in search results. (Certain heading tags within the HTML are given more weight than others when indexing a page.) The content stage is the one requiring the greatest contact and collaboration between agency and client during the production phase of a website. It also helps set the stage for future maintenance of the site - either by the agency or those groomed for the process within the client company. Education and cooperation here are of paramount importance.

Production

Production and/or implementation of the actual application framework and custom programming is the area of greatest danger during this entire project. All other work is almost entirely within the purview of the agency’s core competencies, but this area is the one most often involving a third party. That party may simply be a software vendor, or it might be another individual or firm. The ability to manage that involvement effectively and convey the vision, requirements and spirit of the project is crucial. Technology is inherently vulnerable to Murphy’s Law, and the more people, products and computers that are involved makes that vulnerability exponentially greater.

During this phase I firmly believe that the fluid nature of the web and its related technologies should be exploited to their fullest extent. Work quickly with prototypes and keep deliverable cycles short and iterative. Since data requirements should be well developed at this point, any work outside an existing content management framework should be broken into component parts that can be rapidly prototyped and refined. This rapid cycle turnaround keeps the momentum going and also helps correct mistakes, miscommunications and flaws in the original design before they become major obstacles. Programming can often take the shape early on of a ‘one path to a solution’ approach, and it can take some careful explanation and management in order to arrive at the most usable end result for the user. Every one of those users will have a slightly different perspective on how to accomplish a given task, and the system developed must accommodate more than one way to attain that goal. This I have found to be the most challenging aspect of technical project management: knowing what can be done versus what should be done, and finding the balance of usability and the effort required to attain it.

Test It

While there should be various forms of testing going on throughout the process, it is best to devote several days or more if possible to testing and debugging the site. Different browsers, platforms and devices should be used. New users should be introduced to the site and their reactions, successes and failures noted. Nothing works better than letting new users loose on a site to expose those niggling loose ends in code, architecture and interface design. While this is one of the first things that tend to get cut short, it is crucial to test. There is nothing worse than the client (or their customers) discovering major issues right in the middle of the launch party.

Launch It

Obviously, since all of the above steps have been so carefully undertaken, that actual launch of the website will surely be anticlimactic. Or, in reality, more likely this is a time that becomes more frantic than any other: last minute technology issues, installing the site on production servers, coordination with online and offline marketing efforts needing specific ‘landing’ pages, and of course, promotion of the site launch itself. It is a tremendously satisfying feeling to ‘flip the switch’ and start seeing the reactions from both the client and the end users of the new site.

And Then…

Once the site is live, there must be a period of intense scrutiny paid to log files, feedback submitted and any other reports received from the client or site users. There will be issues that crop up; it is almost inevitable. Issue tracking is important, so they can be logged, investigated, resolved and reported on. Keeping this issue log open to the client can be a valuable relationship tool. It continues the sense of openness and trust that hopefully has been built at every step of the project. After an initial post-launch period it may make sense to remove that access, but keeping the tracking system in place will also help in responding to questions of ‘build defect’ or ‘feature request’ when it comes time to determine hourly billing required for a given issue.

Support issues aside, the true test of the project is how well it is maintained in the months and years following. While some projects are finite in their purpose (as with sites promoting an event or specific campaign), many will be in use for years. Often far longer than we expect (or would like, given the rapid pace of change in the industry). Keeping in touch with periodic reviews, feedback and suggestions will help the client get the most out of their investment, and if we have done our job right, will spark future projects. If that one great collaborative application was a success, this will hopefully open the client’s eyes to other areas where thoughtful application planning could open new opportunities for revenue streams or significant cost savings and productivity gains. As I will generally ask - find the tasks that take up the most time, and start there exploring ways to make that one thing more efficient. By keeping it smaller and simpler, with easily defined benefits, it is much easier to ‘sell’ and to produce. Being agile in this manner is sometimes a tough mindset to adopt, for both the agency and the client - but the benefits can be enormous, and the results exponentially greater over time. If we have done our job correctly, every time the client pays for a project it is generating even better results. This makes it that much more likely the client will return: it makes too much sense, both intellectually and financially, not to do so. That is the happiest result of all, for everyone involved.