This is the first in a two part series.
Developers are often cocooned in a shell, isolated from much of the greater operations of their employer. All too often, IT is treated as a black box, frequently with GIGO (garbage in, garbage out) results. Project specifications are often driven by people and departments with little understanding of technical matters, and the people implementing the specifications have little understanding of the why of the project. When the why is "create or expand an Internet revenue stream," the result can be disastrous.
Many Web sites (especially online stores) are, and should be driven and run by the Marketing or Sales departments. They are experts at selling the product. They know the market, the competition, and more. What they do not know is Web development, and on occasion they do not understand Web design either. This creates bad project specifications, where the how is dictated in a demanding yet vague way, and the why is completely ignored. I have been given project specifications similar to these way too often:
* Look similar to site XYZ, but with our logo and colors
* Have a drop down menu system like site ABC
* We want to collect the following information from visitors at every opportunity: [insert list of the most personal and intimate details of the visitors' life here]
* Spiffy Flash intro
* A lengthy "About Us" page that gives the users plenty of pictures of our CEO and facility
* A shopping cart system, preferably one that does everything that a live salesperson would do, with a strange interface and bizarre options for the user
* "Community building" features, such as a forum, product ratings, instant messaging between registered users, wikis, blogs, RSS aggregation, and a million other buzzwords of the week
* "Viral marketing" systems like affiliate programs
Sound familiar? That pretty much sums up nearly every Web store project specification that has been dictated to me. It is pretty interesting how most of the items on the list are, at best, only loosely related to the why of the project: to sell products! Here is what a why oriented project specification might look like for a Web store:
* Must appeal visually to our target audience: [insert target market demographics here]
* Site must be extremely usable by our target audience, and very usable by non-target audience members
* Site must present the most useful and interesting product information up front, but allow visitors to get as much product detail as they need, to simultaneously encourages sales, as well as minimize the need for customers to contact us before making a purchase
* Site must be consistent with our corporate "look and feel" in a manner that does not compromise usability
* Site must be a secure as possible
* Site should foster a trust relationship between our company and the customers, particularly new customers
* Site must have search engine optimization baked in from Day 1
See the difference? Interestingly enough, not a single item on the why oriented project specification precludes a single thing on the how oriented list; however, many of the items on the how oriented list can preclude items on the why oriented list, depending upon a number of non-technical factors. For example, if the target audience is "well-to-do, young graphics designers using Macintoshes who are at work," a site with a lot of Flash pieces that often emphasizes form over function is not likely to hurt sales, and may even boost them a bit. If the target audience is "retired people on limited incomes," chances are that anything with a font size smaller than twelve points, or that requires "the latest and greatest" in plugins, or a good deal of technical savvy will not be able to sell much product at all.
In other words, we have a classic case of missing the forest for the trees. The trees are technological and aesthetic hows. The forest is the business why of the project in the first place. Even worse, it is not enough that when the development focuses upon technology that the business reasons for the project are forgotten. In all too many cases, the technology actively prevents the business reasons from ever being fulfilled. In the next article in this series, I will provide some examples of how focusing upon the technological aspect of Web development as opposed to the marketing side of a Web project can hurt more than help.
Justin James is the Lead Architect for Conigent.