- Meetings, Meetings, Meetings!
- What Is the Site Supposed to Offer?
- Who Gets Final Say?
- Who Will Use the Site?
- Moving On
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
What Is the Site Supposed to Offer?
The result of the meetings you do have, in the case of Web-based products, should be a nice, clear list of features. If the site is meant as an information space, the result should be a clear idea of the content’s purpose, and the beginning of an idea about how the content should be created and organized. (The final information architecture will emerge later, and future articles in this series will discuss ways to achieve this objective.)
Nailing down the goals is no easy task, especially if the involved parties are particularly opinionated. (All too often, the CEO has a pet feature that simply must appear in the final product, despite any evidence that it would be damaging to the user experience.) When people form a team, large or small, to get involved in the creation of a site or product, they immediately begin stockpiling lists of features they want to include. Unfortunately, it’s very easy to become attached to a bad idea. It’s your job to make sure that logic reigns and each person is willing to concede his or her whims to let good design practices shine through.
To determine which features to include and which to leave behind, think about the product’s ultimate goal and keep only those features that are absolutely necessary to support the activity that the product is designed to perform.
Consider a Web-based tool intended to manage to-do lists. This tool might—and likely should—include a way to name lists, add to-do items, rearrange items, set reminders for items, mark items complete, and perhaps indicate a progress percentage for each item. Some of these pieces of functionality are indeed quite necessary to support the activity of managing to-do lists, but the last item on the list, the ability to indicate a progress percentage, may not be absolutely necessary. The best thing to do is move it to a secondary list—perhaps called "potential features"—and see whether the need for it truly arises during the user research phase. If so, return it to the primary list and move on. Just make sure that this juggling of lists doesn’t happen too often. Usually, the list you first created will capture the real "soul" of the product. Each addition will make it more complicated and potentially less usable, so this should only be done when you’re 100% sure that the addition will contribute to a complete product.
In the case of information spaces, content is king, and instead of seeking out a feature list you’ll be looking for content with depth and meaning for those who visit the site. There is definitely more room in information spaces to let in the occasional non-vital piece of content, but you should still form a definitive model for the focus and purpose of the content and stick to it as much as possible.
Whatever the content or feature, find out as early as possible what will be required for the site or product to meet its need. Then stick to this list with a clenched fist, only letting in that which is later revealed to be absolutely necessary for a complete product. If you doubt this approach, take a look at the Google home page for a quick reminder. The page has changed a thousand times, but it has never become even the slightest bit cluttered. As a result, its primary function is as clear now as the day it was launched.