A cohesive site requirements document will spell out, in detail, how to write content for searchers, how to optimize for engines, and how to display media to sell a product.
Football might seem to be a clumsy game where men run up and down a field. But we cheer touchdowns because we like to see a well-executed plan that's the result of extensive research and planning. Players study film, practice drills, and test new strategies. The same process is part of Web site development. Successful sites are well-planned, documented, and executed. Web developers and designers study their competition and come up with a solid foundation. It all starts with a requirements document.
|Items to Include in Detailed Requirements Documentation|
|User interface requirements||UIR||includes IA, design, fonts, images|
|Search engine requirements||SER||SEO, PPC, SEM, and linking|
|Social media requirements||SMR||blog, forums, social sites|
|Usability and accessibility requirements||UAR||usability heuristics, mobile, Section 508, PAS 78|
Business and Functional Requirements First
Typically, the requirements gathering phase of a Web design is performed by your team as you gather around a whiteboard or conference call. The leading business requirements are laid down first. Is the site an e-commerce site, directory, blog, or informational site? What do we want the site to do, and why? What do we need to create a successful Web site?
Top-level requirements are called parent requirements. They anchor the site's plans. Your team discusses all the goals, no matter how big or small, for the site. There may be several business requirements, such as "provide services," "get sales leads," or "to inform." Parent requirements are broad strokes that are later more fully defined.
Along with business requirements, the other set of parent requirements are functional requirements. This is your programmers' domain. Functional specs refer to technical, server, and application issues, and are typically derived from use cases, mental models, and user personas. Functional requirements determine guidelines for browsers, operating system, accessibility, bandwidth, performance, platform, mobile use, and programming choices.
The process of gathering information at the start of your project helps many members of your team throughout the development cycle. This includes those who create the information architecture, those who do QA testing, and the sales department. A final requirements document can be used to create test cases to ensure every requirement is met.
The Forgotten Requirements
Let's look at this example of business requirements for an e-commerce Web site:
The process of writing down all the desired elements can be a painstaking exercise. In the example, everything is traceable back to "BR4.0 Sell online." The shopping cart is intended to help, but there is a requirement for a search engine-friendly one. One option is build a custom cart. If that is agreed upon, a separate set of functional requirements are written just for the cart. Every requirement and every guideline is traceable to a parent goal. Any time someone wants something added that can't be traced to a business requirement, it is not included.
Very few companies consider marketing or usability at the earliest stages of development. But what about "BR4.2 Marketing" from our example? To meet the user-generated content needs, team members will need to confer with those who are determining functional specs, which include the kinds of software applications that can be used for comments and customer ratings.
Organic search engine optimization (SEO) and search engine marketing (SEM) are not typically applied to requirements documentation, but they should be, so that certain techniques - such as how to structure title tags or guidelines for link labels - are worked out in advance. A business requirement may be "BR6.0 Be found in search engines."
Most site owners take this for granted and don't begin the process. A requirement for SEO can be broken down into functional requirements for on-page optimization as well as details like robot.txt. When every piece is documented, anyone can go through the site at any point to test for compliance.
When approaching the discipline of requirements gathering, it's imperative that all stakeholders from each area of the development process are communicating. Of equal importance is testing during the development phase to make sure requirements are met and there are no conflicts.
For example, a search for "leather fringe boots" displays several search results. One result is a boot with no fringe. Did the page have incorrect content on it? Or, was it the right boot but the wrong images? Why were the photos not showing the boot properly?
A few things could have occurred. There may not have been a requirement for specific title tags and page titles. There may not have been a requirement that all images be shown at all angles. It's likely that there is no requirement that covers searcher behavior. This is closely tied to usability. A cohesive document will spell out how to write content for searchers, how to optimize for engines, and how to display media to sell a product.
Requirements documentation is a group exercise. Who is the site for? How will you meet user expectations, including searchers? Written Web site guidelines, based on the site's requirements, determine design consistency, site maps, and mockups.
If your main goal is to sell products, do you showcase some of them on your home page? Are product pages optimized for search engines as landing pages? Search engines are unable to deliver site pages the way you want them presented without first including SEM into the overall requirements documentation. This means that every element on the page has to meet criteria traceable back to business and functional requirements, as well as meeting supportive requirements such as marketing and SEO.
This was originally published December 2009 in SES Magazine.
Join the Industry's Leading eCommerce & Direct Marketing Experts in Chicago
ClickZ Live Chicago (Nov 3-6) will deliver over 50 sessions across 4 days and 10 individual tracks, including Data-Driven Marketing, Social, Mobile, Display, Search and Email. Check out the full agenda and register by Friday, Oct 3 to take advantage of Early Bird Rates!
Kimberly Krause Berg is the owner of UsabilityEffect.com, Cre8pc.com, and Cre8asiteForums.
Kim launched Cre8pc.com in 1996, offering search engine optimization and web design resources gathered and tested while working as Webmaster for a technical magazine publishing company.
She was in charge of web design and also getting 13 web sites registered and ranked in search engines. As she moved forward in her career, she freelanced from home in search engine optimization (SEO) and web site building under the Cre8pc domain. In 1998 she started the Cre8pc Website Promotion Club in Yahoo! and co-moderated the Home and Small Business Club, where she gained a reputation for helping people and making SEO and Marketing easy to understand.
Hired by such companies as Unisys and Verticalnet, Kim worked as a User Interface Engineer and eventually moved into the Quality Assurance Software Testing field, where it was her job to test and develop the methodology for in-house web site usability.
IBM Social Analytics: The Science Behind Social Media Marketing
80% of internet users say they prefer to connect with brands via Facebook. 65% of social media users say they use it to learn more about brands, products and services. Learn about how to find more about customers' attitudes, preferences and buying habits from what they say on social media channels.
An Introduction to Marketing Attribution: Selecting the Right Model for Search, Display & Social Advertising
If you're considering implementing a marketing attribution model to measure and optimize your programs, this paper is a great introduction. It also includes real-life tips from marketers who have successfully implemented attribution in their organizations.
September 17, 2014
September 23, 2014
September 30, 2014
1:00pm ET/10:00am PT