Requirements Documents for Web Design

In my other life (yes, I have many lives) as head of product management at Focus, I often discuss with team members what questions a requirements document should address, especially when we're considering adding new pages and features to the site.  The following can serve as a useful list for those in the broader Focus community involved in Web site development.   My context is small technology businesses with limited but skilled resources trying to quickly add new features and page templates.    

1. What's the basic background on this requirement?

Sure, if you're in a big company you'll be doing an MRD or PRD with lots of review cycles.  However, for most Web site updates in small companies, you only need to address the basics to get everybody on the same page

• Who is the intended audience?  Everybody or a segment of your audience?
• What is the goal of the feature or product change? Why are we adding this feature or making this change? 
• Are there web examples to consider? (I love to learn from those who have already done it)

Now we quickly get into the details.

2. Is this page(s) or feature(s) static or dynamic?

• Is this a template?  Are there many instances of this page?  Or is this a single, static page?
• Does the page change based on user attributes (e.g., member vs. non-member viewing)?
• Does the page change over time by itself based on any type of logic (e.g., showing the newest widget on the list)?

Note 1: Make sure you can define dynamic change in a quantitative way

3. Are there multiple pages that require integration?

• If there is more than one page?  What is the logic defining flow or subnavigation between pages?
• For example, if users enter on page A and clicks on X, where should they go?

There are often many scenarios to consider here, so catalogue as many scenarios as you can.  Flow charts and process flows can help.

4. How will you handle URLs and search engine optimization (SEO)?

• Do you need to create a new URL for the page(s) or will you be changing URL(s)?
• If changing URLs, do you need re-directs?   Do you need to change internal linking?
• Are there any SEO requirements for this page (URL slug, page title, etc.)?
• Is it OK if this URL gets crawled or should it be in a don't-crawl file? 

5. How do users get to this page?

• From where else on the site do you link to the new page(s)?
• Are links to this page static or dynamic based on who is looking at the link?

6. Are there links within the page?

• If yes, where do these links go? Do they go to an existing page or does a new page need to be created?
• Is there any parameterization that happens based on linking? (e.g., if A clicks on link, go to Y, but if B clicks on link, go to Z)

7. Are you capturing any data elements on the page?

• Are you using existing forms/fields or do you need additional forms/fields?
• How will data be input for each field? Picklist? Multi-select scroll box? Open text box? How does form-field validation work?
• What type of error checking do you need upon submit?
• What will you do with this data? How will it be used?

8. Does the page or feature require design? What design guidance might you give?

9. Does the page or feature require copy creation or review? Who should create and edit the copy? Marketing? Editorial? 

10. Does the page or page component need to be "authored"?

• How do you make changes to the page?
• Are changes made manually by UI engineering?
• Is there a content management system (CMS) component?
• If there is a CMS component, what are properties of the component that need to be programmed?

11. Are there any process implications of rolling out this page or feature? Are there other impacts on other features?  When you launch:

• Do you need to remove other pages? Do you need to change any links on the site?
• Do you need to port X to this new format or (re)program something in the CMS?
• Do you need to remember to manually program A, B and C every X amount of time?
• Do you need to make sure operational emails and marketing creative, takes into affect this change, etc.?

Answering these questions is obviously just a beginning.  How you document and communicate your answers can be just as important as the answers themselves.  Let me know what other questions you as the reader think should be added to this document.