Determining Options that Make Good Business Sense

Now that you've got a good sense of the various economic models of Web sites, and some thoughts about the site you want to plan, you need to make some decisions about the information architecture and technical infrastructure.

Objectives

By the end of this lesson you will be able to:

More on Economic Models

You may find that the economic model or models that you have chosen for your Web site need to be changed or adjusted over time. At the most basic level, you need to create or offer something that other people want and are willing to pay for. It may be a product or service, or it may be a popular Web site that offers advertising space that is valuable.

The Impact of Your Decision

Once you've decided what economic model or models you will use for your site, you'll need to consider the impact of that decision. For instance, if you plan to sell advertising, you need to plan for closely tracking your statistics, and possibly have them verified by a third party, and you need to actually sell the ad space. You'll also need to think about how the ads will be served on your site. Will you handle it yourself? Or will you contract this out to a third party?

Just as your economic model may be a result of your business, the model you choose will affect your business.

The Business Requirements of the Site—They May or May Not Directly Parallel the Economic Model

A business Web site must meet a business need or set of needs. It doesn't make any sense to create a site without understanding what needs that site has to meet. There has to be a reason behind the site and there should be some justification for spending the time and money to build a commercial Web site.

The business needs associated with Web sites may or may not directly parallel the economic model of the Web site. For instance, an insurance company might have a marketing and informational site with no direct revenue model but the site supports itself through advertising by other companies. The economic model of the site is support through advertising, but the business model is focused on the marketing of the insurance company.

On the other hand, a product sales company may have an e-commerce site that also uses internal advertisements to draw people to different parts of the site and draw revenue from its online sales. Here, the economic model is online sales and the business model is the same. Further, given this site's business and economic model, there is an additional advantage created by adding the functional component of internal advertisements.

The need to keep users on the site and encourage them to visit other areas of the site and, ultimately, to make more purchases at the site, spawns a functional requirement. The business need is to generate (profitable) revenues through sales, so the functional requirements are to help users make their purchase on the site and to keep them on the site making more purchases.

As we go through this lesson, we will look at numerous business models and the site requirements they might engender. But this can only be the start. The development of Web sites offers so many options and opportunities and the technological tools continue to evolve at such a rapid pace, that it would be folly to try and cover every possibility here. This lesson will lead you through the steps you should undertake to understand the functional and content requirements of a site.

Starting with the Basics

As we discussed in Lesson One, the most basic site will need to provide, at least, basic marketing information about the company. Even with this basic functional requirement you'll want to create the following documents: With these documents in hand you will have a basic site plan. The content matrix and site map comprise the core documents of an information architecture, which will be supported by the technical infrastructure. You'll want to begin with these steps for just about any serious Web site. The system blueprint and real estate allocations become important when you're creating a more complex site.

These site design documents are the overall blueprint for your Web site and are crucial to the development of a successful site—especially if a team is involved. You should distribute these documents to your team, even if you think that not everyone needs them. They may well come in handy.
Information Architecture:
The design of the organization, indexing, labeling, and navigation systems to support browsing and searching throughout the web.
 
It's also important to recognize that these should be considered living documents. No matter how well we plan, things will change over time, especially in Web time! Be sure to keep your site design documents up to date and then redistribute them to the team as they are updated. You may want to set up an intranet or extranet just for storing and distributing the latest documents.

In order to start generating these documents, you'll need to start by organizing the content of your Web site.

The Creative Brief

A creative brief is a document that outlines key issues about your site from a goal-oriented perspective. It helps you set the rules from the beginning so you and your team start from the same place with the same information. The creative brief should cover: Sample Creative Brief

Site Goal: Sell high-quality baker's chocolate through online sales supported by information and recipes and recipe and experience exchanges.

Intended audience: Professional and home bakers. Key demographics: professional pastry chefs in urban areas; women and gay men aged 28-70 with an interest in high-quality food and dining. Average annual household income > $60,000.

Branding of the site: rich, sensual, foil-wrapped, authentic, intense, serious but also welcoming and encouraging of sharing.

Brand promise: by using this brand of chocolate in your desserts, you will be creating an exquisite taste and texture experience.

Users gain: recipes, tricks of the trade, companionship and colleagues, and great chocolate through a hassle-free purchasing process.

If you are working with a team, be sure to share this document with them. As the development of the plan for the site and site itself proceed, be sure to consult the creative brief on a regular basis to be sure you're staying on the right track.

Information Architecture—Organizing the Content for the Ways Users Seek Information

The organization of the site's content is the core element of the site's information architecture. Just as a marketing brochure is designed to catch the eye and draw users in, providing different areas for different types of information (e.g., front cover, back cover, inside, etc.), a Web site must also be designed to help the user locate and use the information they're looking for.

Browsing Through Choices

At the highest level you need to deal with the fact that people can only browse through a limited number of choices at one time. Usually, it is best to keep the number of choices below seven. Since it is likely that your site will have more than seven components, you must group these components into categories, so that you have seven or fewer top-level categories. This action is also called classification and works the way libraries classify books into different subject areas. Note how a site like Yahoo deals with a large number of items on its home page.

As you organize the content into categories, or "buckets," you will likely find that your naming scheme needs to be adjusted so that items in the same category have the same style of name (for example, nouns vs. verbs or "Contact Us" vs. "Contacting Us"). You'll be documenting your naming scheme in the Content Matrix.

Browsing through Documents

At the content level, the information architecture also refers to the way individual pages are strung together and linked with each other. For instance, you may want to include glossary entries for technical terms used in a document. In this case, the term itself could be a link to the glossary itemæhere it would make sense to have that link open a small window with the term definition on top of the original document window rather than taking the user to a new page entirely. This too is an element of the information architecture.

Using a Database

Some site content is best stored in a database and retrieved into the site using queries. These queries can be "live" (entered by the user) or embedded into site links and scripts. The advantage to using a database is that you can greatly reduce site maintenance and increase the quality of information the user receives. This type of organization tends to work best when the content is made of up discrete chunks of information rather than linear or narrative content.

An obvious example of a database would be a product catalog containing 100 products. Each product record might contain:

To display each product page, all you need to do is create a template that contains calls to the database. As the product record is called up through a query, the template fills in the appropriate information for that product and displays it to the user. This way you don't need to program 100 separate HTML pages, just the one.

And adding new products is a snap! All you need to do is add the record to the database and the photo of the product to the correct directory and that's it. Now imagine the timesavings if you have an even larger catalog and numerous product changes each day. . .

A less obvious example of when a database back end might be useful is a newspaper/newsletter example. Suppose you publish a newsletter each week with articles from a number of sources. If you put each of the articles into their own record in a database, you can allow your end-users to sort and locate particular articles very easily with no reprogramming of the site. For instance, you can set up a link with an embedded query to show all the articles about NASA space probes published in the last month. As time goes on, the link on the HTML page stays the same, but it only pulls up the latest month's information.

Of course, creating a database is no simple task, but learning how to do it or getting help from someone else may pay off for you in the end in terms of better sales and more efficient maintenance.

Now that you've thought about the organization of the content of your site, it's time to start documenting the blueprint for the site. We'll start with the Content Matrix.

The Content Matrix

This somewhat self-important term describes document that lists the content of the Web site (whether it currently exists or not), where it currently exists (if it does), what it will be called in the new site, what action needs to be taken to ready the content for the site. As an example:

Item # Item Description Current Location New Name Action Needed
1.0 Home Intro Copy \\server\marketing\current_docs\HomeIntro.doc None Edit down to web style by Mary; add embedded links to Baking Blocks and Eating Chocolate.
1.0.1 Home photo \\server\photos\??? None Need to select photos for montage
2.0 Catalog Intro \\server\sales\current_docs\CatalogIntro.doc Catalog of Chocolate Clear usage on Web thru Johan
2.1.0 Baking Intro \\sales\current_docs\Baking_Intro.doc Baking Chocolate Tyrone to create public version
2.1.1 Baking Blocks \\sales\current_docs\Block_desc.doc Block Chocolate Need to optimize writing for Web delivery
2.1.2 Baking Chips None Chocolate Chips Need to write—contact copywriter
2.1.3 Baking White None White Chocolate Need to write—contact copywriter
2.2.0 Eating Chocolate \\sales\current_docs\Eating_Intro.doc Eating Chocolate Tyrone to create public version
etc....
3.0 Chocolate History \\library\docs\History_of_Chocolate.doc A History of Chocolate Need to optimize writing for Web delivery

How you fill out this matrix will depend on the scope of your work, your appointment (or your authority), and your knowledge. It may be that the scope is narrow enough and you hold enough authority that you can fill out the matrix on your own. What is more likely, however, is that you will need to work with a group of people to discover, plan, identify, brainstorm, and assign the various data elements.

Two areas, in particular, call for group input: what items belong on the Web site and what those items should be called. Each member of a team brings a different perspective and what seems obvious to one person might seem strange to another. It's important to remember that on the Web you're reaching a wide-ranging audience so the more input you get at this stage the better.

The example provided here should not be assumed to describe the best way to do a matrix in your situation. You may want to add columns to your matrix depending on your needs. For instance, if copy pieces are short enough, they can be included right in the matrix rather than in separate files. Or, if setting content priority is important, then add a "Priority" column.

Make the best matrix to fit the job you're doing.

Setting priorities now will help in the real estate allocations as well as the interface design itself. In addition, it will help you decide what content should be included in the final site. You don't to include content just because you can. Include only the content that users will be interested in and will directly or indirectly serve your business need and economic model. Cluttering the site with useless information will negate the effectiveness of the other, useful content. Setting priorities at this stage will help you identify what text should and should not be included.