Getting Web site development right
Two of the most popular search terms for this blog are "b2b website" and "corporate websites suck." The second due to a 2005 post called Why Corporate Websites Suck and some ideas for fixing them.
But, as I was writing a memo about site development for a client, I realized that I haven't written about Web development here in quite some time. Since people seem to be coming here for just that sort of information, seems like I should rectify that :-)
So here's a step by step outline that covers the most important part of the process: defining the requirements and navigation for the site. I strongly believe that you must have a clear picture of the path(s) you want your visitors to take through your site, to get to the desired result, before you commit one line of code or design a single page.
These are the steps I follow. Every time. New site or redesign.
1. Assemble a team that represents the key stakeholders in the site. You do not need every individual, but you do want to be sure that the representatives are truly cross-functional. In some cases, you will want someone from the actual business area. In others, it may be more effective to have members of your team interview the relevant people. Some of the functions that should be included are sales, marketing, business development, communications and customer service.
I do not recommend having the Web designers or developers too involved in this stage. You want to keep the discussion at a business level until you have a solid idea of what is needed across the company. Developers often get too wrapped up in how to do something rather than what is necessary, which should be the focus early in the process. Involving developers too early also can steer the discussion toward what the developers can do easily rather than what the company really wants. Later, when you get to the development stage, you may make concessions due to cost or complexity but it is too limiting and undermines creativity to start this way.
2. Once the team is assembled, the first order of priority is to identify the objectives for the Web site. These objectives should be closely aligned with your overall business goals. Some of the questions to ask:
a. Who are you trying to reach?
c. What do you want to tell them?
d. What do you want them to do once they are at the site?
e. What are the priorities of the business now and for the next three years?
It is helpful to pull the web stats from the existing site to better understand what your site visitors are doing. What areas get the most traffic? What are people coming to your site to see and do? It’s okay to let the team refer to areas on the current site that they feel need to be kept or improved, but don’t let them get bogged down in what they don’t like or think does not work. The point of this work is to develop a specification for the new site; rehashing previous decisions, good or bad, is not useful and slows down the process.
You are going to have multiple audiences and multiple objectives – everything from sales to customer service to media outreach to things very specific to your business plan. This is exactly what you want at this stage.
3. Next, you determine priorities. Of all the objectives identified in the previous stage, three, maybe four, will be critical to your overall business objectives. These are the priorities and the elements that should get attention on the highly valued “real estate” of your home page. For the most part, everything else can go on inside pages. Typically, the core priorities fall into these buckets:
* Identify product set and market segments so visitors know they are in the right place;
* Communicate key company news/events/messages to constituents;
* Customer service.
4. The team should then discuss content. Starting with the existing content. What stays/goes? What should be improved? What new sections do we need? What data do we need to capture from our visitors? How will we let people search our site? Keep the team focused on the desired result, not the technology that might be used to get there. And don’t worry about writing the content yet; that comes later.
5. One or two team members should be deputized at this stage to develop a straw man home page, home page navigation and inside navigation. Their job is to synthesize all the discussions into a cohesive navigation. You still should not be thinking about design or functionality. Keep thinking content. The key questions:
a. What action do we want or expect to visitor to take?
b. How can we drive the visitor through our site to accomplish our priority business and site objectives?
As mentioned above, you need to stay focused on the visitor. How does she use the site? What did she come for? Every click should move the visitor forward to accomplish her objective. The goal as we develop navigation is to ensure that she is never more than one click away from the next thing she wants.
This is just about the most important part of the process: Making sure you have defined a clear path through your site for your users so they get what they came for.
Never assume that the visitor will figure it out. If you want him to do something, make that the attractive option. If he wants to buy something, make sure he can do it easily and quickly.
So, if we sold apples, our home page would make it clear we sold apples, and perhaps the range of varieties. Within one click, the visitor could get more information on the specific varieties (product page). One more click gets him to the order page, or perhaps the dealer search page if we don’t sell direct.
We can offer more information about our apples, but we have to make the desired path crystal clear. Otherwise our visitors get lost.
Typically, the home page has its own navigation, and the inside pages have two levels of navigation: a top line navigation which contains all the items that are common throughout the site, and not that different from the home page navigation, and a side navigation, which contains all the navigation items for the specific section of the site.
6. Once you have your straw man, the team reviews it and the straw man is adjusted accordingly based on feedback. Continue the review and revise process until you have a defined home page and navigation that meets the approval of your key team. This should all still be in outline and very rough graphic form “FPO.”
Now it is time to involve the Web developers and designers.Whether you are putting the project out to bid or using an inside development team, I always recommend that the marketing team and key stakeholders get a clear picture of what they really want from the Web site before involving the techs.
I also stay away from delivering a “spec” to the Web team in the first pass. I find it more useful to present what the site needs to achieve from a business and customer perspective to see how the vendor(s) respond. You may discover that some of the things that you’d like to have require more funds than you have budgeted. This is where the priorities developed earlier come in so handy. The budget needs to deliver the priorities first, and the “nice to haves” come after.
The goal is to develop a scope of work that delivers as much of your core needs as can be accomplished, along with a plan to incorporate any additional elements as time and budget permit.
7. You then move into the development stage of your site which typically will have three main areas: Design, Development and Editorial. Your Web developer will probably offer both Design and Development (functionality, coding) services. Editorial, ie writing the site, is best project managed by someone in-house using a combination of internal and external resources. If you spend the time upfront as I've outlined, the actual development project will be far simpler and smoother than you perhaps have experienced in the past.
The comments to this entry are closed.