Feb. 26, 2011, 11:54 a.m.
posted by legendcoder
Writing a Functional Specification for Your Site
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:
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.
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.
Writing functional specs begins with information gathering. The three main questions you need answers for are:
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:
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:
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).
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), and dummy HTML prototypes that map out a user's interaction with the site (as discussed in Recipe 2.9).
A schematic site map lays out a potential navigation scheme
An icon-based site map outlines a site's levels and pages
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.
Wireframe designs isolate layout, navigation, and functionality from color and visual design
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.