- Featured Columnists
Table of Contents
- Web Basics
- Publishing on the Web: Putting Files on the Server
- Web Design Process and Workflow
- Project Management
- Mark My WWWord: HTML and XHTML
- Standards Compliance
- Meta Tags and Search
- Enhancing Web Page Interaction
- Web Graphics
- Web Page Optimization
- Overview of Servers
- Server Programming Basics
- Careers in Web Design
- Intellectual Property for Web Designers
Last updated Oct 17, 2003.
It's time to get down to business in creating the requirements to define what objectives to meet. The first rule for beginning a Web site project is to get to know the audience. This is the first rule because the work surrounding the Web site is about helping visitors get what they need while meeting the goals for the Web site.
Getting to Know You, the Audience
How do you get to know an audience? Through a number of ways, and the only restriction is budget. Start by listening to the marketing department if the company has one, read customer emails and bulletin board comments, and you'll start to get a feel for a typical customer profile. If possible, gather data by conducting surveys or focus groups. A user profile ideally includes information such as age, gender, occupation, online frequency, connection speed, computer hardware and software information, location, online habits, and household income and spending (among other factors, depending on the site).
A site selling groceries may target mothers. Two profiles come out of the research: working mothers and stay-at-home mothers. A summary describes the average working mother and the average stay-at-home mother by age, neighborhood, hobbies, likes, and dislikes. Prioritizing determines which group the site should target first. Let's say the working mother is the higher priority. The site would focus its message surrounding a long day at work and coming home to the family with no time to shop. Do it from the comfort of your home, and have the groceries picked and delivered. This process is a way to get a real-world understanding of the users' personas.
Where do you start? First, take a "user-centered" approach to design, add a cup of easy-to-use, and everything will be A-OK. The work takes more than this, but it's a start.
After identifying goals to ensure that the Web site meets a real need, it's time to get your hands dirty. The seeds of the project are planted, and it's only a matter of time before you're ready for cultivation to a full-fledged site.
Leave Little Room for Multiple Interpretation
When gathering requirements, clarify to everyone involved the purpose of the requirements because it means different things to different people. Some organizations have multiple requirements gathering stages, starting with high-level requirements working to the more detailed design requirements.
A frequent problem with requirements documentation is vagueness. "Provide client support for 14 days after implementation" is ambiguous. What does support mean? Other words that sound good, but are considered vague include the following:
One way to improve the previous requirement is by explaining what "support" means. "Provide client support for 14 calendar days after implementation. The support includes fixing bugs, ensuring that the site uptime is 99%, and reviewing the error logs and addressing the errors."
The trick is to target measurable goals or think SMART: Specific, Measurable, Attainable, Realistic, Tangible. The error log has 20 errors. At the end of the 14 calendar days, how many errors are left? The result tells you whether or not the contractor met the requirement. "14 days" can be interpreted two ways: calendar (every day including weekends) and business (typically Monday through Friday, counting as five days).
If the requirement can't be clarified at the time it's written, put a "TBD" (to be determined) and revisit it later. It's not against the law, but close the TBD items before moving to the next phase.
Break It Down
Many projects get broken down and implemented in various stages to get up and running sooner with a minimal rollout. Because of this, it's necessary to prioritize requirements. Of course, everything is high priority to the client. Review and prioritize the user classes and tie it in with the requirements that meet the needs of those user classes. That will help with the prioritization to ensure that the higher-priority users are first served when the site launches. Down the road, the client could find that certain features aren't needed after seeing the site in action.
Power of the Signoff
Before closing the requirements process, explain to the client that requesting functionality after signoff involves increasing costs, pushing out the schedule, and requiring a change request form. When the final budget and scheduled is locked in, get signoff from the right people.
Watch out for folks who think they have signoff power. Review the roles and responsibilities of the people involved in the project and contact the person who would know who has signing authority. Hold a detailed walkthrough of the requirements to avoid potential finger pointing later down the road with comments like "Who agreed to this?" and "This isn't what we wanted!" Save copies of all signed documents and anything related to budget and schedule.
If you're watching TV, and someone gets up to go to the kitchen, you might ask, "While you're up, can you grab [enter food or beverage here] for me?" Most of the time, the person agrees and it only takes an extra few minutes, if that. What if you were to say, "Oh, and how about a sandwich? Go ahead and add chips. Oh, what the hey? Bake some cookies." Your TV-watching cohort may think you're out of hand at this point.
This is an example of scope creep. When applied to the Web, scope creep is what happens when a genius in the marketing department gets a bright idea that becomes a minor addition to the design, which then becomes 73 minor additions, and very quickly becomes a major headache. Guess what? There are also geniuses in other departments coming up with their own brilliant ideas. These minor additions are no longer easy fixes that take an extra few minutes.
Work around the fun by having a Change Request template or similar form for documenting new requirements and conducting an impact analysis. The form describes the implications of adding the change along with related tasks, estimated level of effort, and impacts to the schedule, time, and cost. The client reviews the change request and signs off or revisits the request with modifications. The next time another request comes, whip out Mr. Change Request form. Scope creep is annoying, but it's an opportunity to increase the time and cost for the project.
The requirements phase is frustrating and painful, making it difficult to be specific early in the project. Even if the requirements are broad and open to interpretation, it's OK to work in the details during the design phase with input from the client and end user.