Recipe 2.1. Writing a Functional Specification for Your Site


Problem

You need to determine the purpose and goals for your site.

Solution

Write a functional specification that describes a road map for creating an online experience and get all the stakeholders interested in your web site's success to read the spec, approve it, and follow it.

A functional specification document can vary from a two-page outline for a small, quick turnaround web design project to a lengthy, multipart treatise for a complex web application. Regardless of the size and scope of your project, a functional specification for a web site should:

  • Identify the audience

  • State the goals of the web site

  • Establish a method for measuring success

  • Define interaction points

  • Describe the site both textually and visually

  • List key decisions to be made

  • Identify and assess similar sites

  • Outline a schedule

  • Provide a guide for testing

Discussion

Most of your web site projects will benefit from some kind of blueprint to guide your work and manage the expectations of those for whom you're working. A functional specification document can do just that. By unifying the needs of users, the capabilities of available technology, the vision for a new site's look-and-feel, and the business needs of those who are paying the bills, a functional spec makes a web site project go much more smoothly than a project that proceeds without one. For web site builders at the crossroads of these oft-competing interests, a functional spec offers a useful tool for avoiding "feature-creep" along the way and deflecting criticism and complaints when the project it defines is complete.

"Feature-creep" (a.k.a. featuritus) is the term jaded web site builders use to describe projects whose list of requirements grows and changes as the deadline looms.


In Recipe 4.8, I explain why it can be useful to maintain your web site the same way software companies do their productsas code to be compiled and delivered in its most streamlined state to users. Writing functional specifications is a key first step in any successful software development process, as well as most modestly complex web applications. Likewise, any web siteno matter how smallcan benefit from using a functional spec as its starting point. That's because the prose, visuals, and schematics of a functional spec are almost always easier to argue over and change than the actual HTML code and graphics of a half-finished web site.

Reality Check

Before you begin writing a functional spec document for your project, do a reality check. Ask yourself "Is this process absolutely necessary?" Often, you will find that unless you're building a web site by yourself, for yourself, and plan to keep all the goals and requirements in your head, a functional spec is the best way to get a complicated project off the ground. But don't write it just because you can, and when you do, keep it shorter than you think it needs to be. You can feel more confident in the agreement a functional spec elicits when you know everyone has read it.

Beware that functional spec documents have inherent flaws: as political documents, they can be used incorrectly to appease stakeholders rather than make them aware of tough decisions ahead. As prognosticators, functional specs can fail to anticipate changes in the inherently uncertain world of web designthe inevitable phase that a friend in the business refers to as the point "when the wheels come off." Don't blindly follow your functional spec off a cliff. In the end, realize that your functional spec is a snapshot of what you know about a project before it starts and a compromisethe first of many you'll make to get the project finished.


Writing functional specs begins with information gathering. The three main questions you need answers for are:

  • What will this web site do?

  • Who will the web site do it (the answer to the first question) for?

  • When does the web site need to be done?

If you're working one-on-one with a client, you might be able to get what you need in a short introductory meeting combined with a questionnaire. For larger projects involving more stakeholders, the first step of information gathering is often simply figuring out who has the information you need. Getting answers to these three big questions also usually requires shaping them out of answers to more specific questions posed in your client questionnaire, or in interviews with the key project players, such as:

  • What is the intended launch date for the site?

  • Do you have any user feedback about the current site (if there is one)?

  • How will you measure the new site's success?

  • Who is a typical user that visits (or will visit) the site?

  • What is the site's key idea or "take-away" concept for visitors?

  • What is the primary "action" the visitor should take during (or after) a site visit?

  • Why do your target visitors choose to do business with your company?

  • How does your company (or organization) differentiate itself from its competitors?

  • What web sites do you find compelling?

  • How do most people find out about your current web site?

  • Who will be responsible for updating and providing content?

Start by listing all the goals that can be accomplished with the site (or a new component of an existing site), then prioritize the list from most to least important. Elevate the top two or three as primary goals (or core functionalities) of the sitethe objectives the site must achieve. On the next tier, list secondary goals. Make sure you identify these as the "nice-to-have, if-there's-time" objectives. Also, list the non-goalsthe wish list requests that this web site project will not accomplish. As time, budget, and technology limitations come into better focus in the creation of the functional spec, expect some goal-shifting among the three lists.

When defining your audience, remember that your visitors don't care about technology constraints or marketing plans, they just care about the subject of the site and getting what they want from it. Start by writing a real-life depiction of the web site's target audience and why they will use the site. Often a web site's audience is not comprised of just one stereotypical user, but a variety of distinct, but related, visitor profiles, or personas.

For example, consider the hypothetical user personas included in the specification for a web site that will promote new medical office space:


Target user

Physicians who will move their medical practices to the new building.


Other users

Therapists and pharmacists who might want to lease or sublet space or establish ground-floor retail establishments in the new facility, or prospective patients who live in the neighborhood.

Also, try to discover as much about the browsing requirements and technological capabilities of your audience as possible and include a benchmark statement in the general audience profile that anticipates those needs. For example: "Doctors in our target audience have access to newer PCs with high-speed Internet connections, but have little time for web browsing. The site will be designed for quick, productive visits using Version 5.0 browsers (or better)."

Finally, make sure the functional spec acknowledges realistic estimates for the time involved in meeting the goals, as well as external factors that affect the project completion date. The time to find out about the major tradeshow or direct mail campaign that the site needs to support is right now. Outline a schedule that works backward from a hard deadline and includes milestone dates and time at the end for testing (see Figure 2-1).

Figure 2-1. A timeline helps highlight task priorities and schedule conflicts


Lay out the interaction points between visitors and the site by providing as much detail as possible about screens, links, and buttons. Because people process information in different ways, provide both visual and textual descriptions of the site (see examples in Figures 2-2, 2-3, and 2-4). For small, simple sites, this can simply be a list of navigational elements, a site map showing how pages will be organized and linked to one another, and mockups of the page templates. More complex sites and web applicationssuch as membership or e-commerce sitescan benefit from flowcharts, wireframe layouts (see Figure 2-5), and dummy HTML prototypes that map out a user's interaction with the site (as discussed in Recipe 2.9).

Figure 2-2. A schematic site map lays out a potential navigation scheme


Figure 2-3. An icon-based site map outlines a site's levels and pages


Figure 2-4. Details about a form-intensive layout should be hashed out on paper first


Along with these schematics and hands-on depictions of a web site project, a thorough, functional spec will also include individual descriptions for the components of the site. For example, a description of a user survey page might specify: "Respondents will be asked their gender (radio button choices for "male" and "female"), their age (pull-down menu with choices "1319," "2029," "3039," "4049," "5059," "6069," "7079," "80+"), and how they heard about the site (checklist of choices providing by marketing department)."

Identifying decisions to be made over the life of a project is another main goal of the functional spec. Compiling a planning document before work begins on the site helps nail down answers to easily forgotten or overlooked project questions: who will provide the content, who will write the content that doesn't exist yet, who will maintain the site, who will get online order notifications by email, what will the text of the mailing list sign-up confirmation and error messages be.

Share your functional spec with the interested parties to help them understand their responsibilities, suggest changes, and fill in holes as necessary; and when you've got everyone's agreement and approval, begin the project.

Figure 2-5. Wireframe designs isolate layout, navigation, and functionality from color and visual design


See Also

Recipe 2.9 talks about how to map your requirements to a flowchart. Recipe 9.10 explains the importance of getting feedback from potential visitors before your site launches. For a contrarian view on the need for a functional specification for your web site project (and the lively discussion that follows), see 37Signals's "Getting Real, Step 1: No Functional Spec" at http://www.37signals.com/svn/archives/001050.php.



Web Site Cookbook.
Web Site Cookbook: Solutions & Examples for Building and Administering Your Web Site (Cookbooks (OReilly))
ISBN: 0596101090
EAN: 2147483647
Year: N/A
Pages: 144
Authors: Doug Addison

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net