As the computer monitor buzzed warmly, the moment of truth arrived… shattering my dreams into a million small, unrecognizable bytes.
The four months leading up to this moment had been spent dreaming and molding the vision my company had for a new website. However, nothing could prepare my eyes for the electronic carnage laid before me. This couldn’t be my website, could it? It was nothing like I had imagined. The beautiful layout I had approved a month ago looked more like my teenager’s bedroom – messy, dingy, and smelling like moldy pizza had been left under the bed. The navigation was difficult to maneuver and the shopping cart was so worthless that I would have gladly traded it for the rusted variety you typically find under a viaduct.
Happily, after several bottles of anti-acids and working with real Web gurus, I now know much more about developing websites. My hope for this article is to teach the top seven disasters of website development and how to avoid them, so you can forgo the “electronic carnage.”
Disaster #1 – Finding out your website doesn’t have the functionality you’re used to finding on the competitions’ sites.
Tip — Identifying the things you would like to have on your site can be easily overlooked. Don’t. Instead, try “comparison shopping” by visiting competitors’ sites. Ask yourself: “Is it easy to navigate?” What would you change? Look for simple tools, search options or other aspects that make the site user friendly. If they have a shopping cart, go through the buying process and keep track of the things you like and the things you don’t. This should help you in your search for navigation nirvana.
Disaster #2 – No one can find your website, even with accurate search terms and/or well-trained bloodhounds.
Tip — During the 90’s marketing professionals had the misconception that once a website was up and running, the customer would visit and shop. While that philosophy may be true with some brick and mortar stores, it doesn’t work with websites.
So before you start to build, write down all the search terms that most represent your web site. Just think: “what words would I use if I were searching for my site?” When you are done, give those terms to your copywriter, to be integrated into the headlines and body copy. Also, look for strategic partners that may complement your website. Then build links to their site(s). In return your strategic partner can put a link to your site on theirs. The organic ranking for your site will be greatly enhanced and your site will enjoy much more traffic.
Disaster #3 – Everyone that visits your site has a hard time finding what they want so they abandon it for a competitor.
Tip — Building a site map of your site before you start building will greatly enhance the navigation aspect of your site. Remember your functionality brainstorm? Now is the time to start grouping similar topics or tools and organizing them into a map that is intuitive and easy to follow. By having a site map, your web programmer will have a much easier time planning for the navigation.
Disaster #4 – Everything that could go wrong with your site, goes wrong – from functionality to marketing copy.
Tip — Can you imagine building a sky scraper without a solid blueprint and an engineer’s specification document? If there were ever a backbone to the web development process, it would be an effective and usable copy deck. A copy deck breaks down each page of your website. It’s considered the blueprint before construction begins. This document should house your marketing copy, product descriptions, visual references, links, and functionality descriptions. This process can be lengthy if done correctly. But spend the time. It’s well worth it.
Disaster #5 – Your graphic design doesn’t translate on the web.
Tip — This problem can be a result of two different problems. A) Your design preceded the copy deck. B) Your site was designed by a print designer.
Designing your site before the copy deck is developed is like hiring an interior designer before the house plans are finalized. You may be presented with some good options. But the options may not be right for the space. Your website is no different. Your designer will have a much easier time if he/she understands how much copy will reside on each page, how many products will be presented and the messaging hierarchy. Once the structure is complete, your designer will have an easier time formulating a design that will support the intent of the site. Form follows function is a good rule of thumb.
Also, note that there is a big difference between graphic design for print and graphic design for the web. Be careful who you use to design your site and stay away from print designers. An experienced web designer will present design options and colors that will translate very well within a web environment. And the programmer will appreciate it as well. Be sure to ask for a portfolio of websites from your prospective designer. Make sure what you are seeing was designed by the person you are thinking about hiring. It will make all the difference in the world.
Disaster #6 – Your programmer thinks he/she understands what you want. But when you see the final product it’s nothing like your vision.
Tip — It all boils down to communication. And if there were ever a need for communication, a website is the time. Sit down with your site programmer and go through your copy deck, page by page. Call it a pre-production meeting or whatever you want, but ask questions. Ask your developer to summarize your wishes in terms of functionality and design. Don’t assume anything. If it is not clearly spelled out within the copy deck and you don’t discuss what you want, how is the developer supposed to read your mind? Take your time. It may take a few hours or a few days. But putting in the time now will save hours and hours of heartache.
Disaster #7 – Your site is “live”, but it’s broken.
Tip — There is nothing more frustrating than going to a website that is broken. You may find links that point to nowhere or you may be in the middle of checking out and the shopping cart function malfunctions.
Testing your site is crucial. You should have several people “test” the site before it is published for the whole world to see.
You may find different problems within different browsers. Have a person on your team test the site within different browsers. You may find your site works great in Firefox, but doesn’t work when viewed in Internet Explorer. Remember to test the different versions of the same browser as well.
Also, it is a good idea to develop the site on a test server that is configured exactly the same as the eventual host server. Or, if possible, develop the site on the host server. This will reduce problems when the site goes live.
By implementing these tips from one who has gone before, you should have a much more enjoyable time with your website development. Keep in mind that website is not an easy thing to create. There’s a lot of planning and communicating that needs to happen, but if you can make it happen before you go live, you won’t find yourself wanting to hang yourself with a DSL cable later.
This entry was posted in: Uncategorized