f you were to ask my Internet Software QA Manager what the hardest part of training me was, he would roll his eyes and tell you it was the discipline of the testing methodology. I had no trouble learning Rational testing software. I was perfectly fine with communicating between business units of the company. What drove me nuts was the organizing and planning for web sites. Not only this, we had to write it all down into a formal document! Who had the time for that?
I cant express to you how often I thank the IT guys whom I worked with, who would listen to me grumble and then get all giggly with pride when I completed my documentation , test plans, test cases and tons of hours functional testing. Without fail, this slow process of thinking, planning and visualizing details before any ounce of code starts added up to a clean, working, usable end product such as a new web site or proprietary web-based application.
Requirements gathering are something I teach. Ive been laughed at for bringing up the topic to search engine marketers and those new to web design. In a time when you can buy a web site template or grab a free blog template, who in the heck is thinking of details like target market or error message guidelines? And yet, in nearly every case of site testing Im hired to do, there is no site requirements documentation and I can tell. There is more of a chance of target market analysis applied to copywriting and SEO than there are web site requirements used for guidelines, user and functional testing and making sure business objectives have been met. Its difficult to convert traffic to sales when even you havent figured what your web site is expected to do.
Without getting all technical and drop-dead boring on you, Id like to offer some basic help with requirements that you can apply right now and use to make sure your web site isnt going to tank on you. Feel free to adapt this to your own way of doing things. The most important part of this process is to get everyone thinking and working off the same page.
Business Requirements
Start with a Parent requirement. The easiest way to think of this is to ask yourself, What is the objective of this web site? or What are the goals we have for this web site? For us now, our example is an ecommerce web site that sells hand-made pet toys, clothing and accessories.
Our Parent Business Requirement is
BR1. Sell hand-made pet toys, clothing and accessories online
BR2. Provide information on our company
BR3. Enable affiliate sales
Other possible business requirements might be offer search, provide services, get sales leads and To inform on [insert topic].
Next, place details under each BR (Business Requirement).
BR1. Sell products online
BR1.0 Add shopping cart
BR1.1 Marketing (SEO)
BR1.2 [insert and list the ways you plan to sell online; i.e. user generated content, social media, weekly sales, coupons, online accounts, etc.]
BR2. Provide information on our company
BR2.0 About Us page
BR2.0.1 Provide bios of staff
BR2.0.2 Presidents message
BR2.1 Blog
BR2.2 Catalog
BR2.3 [insert and list the ways you plan to provide information; i.e. testimonials, blog comments, forums, product reviews, press releases, contact page etc.]
As you can see, this tedious process has a purpose. It helps everyone associated with the project ask questions regarding goals and objectives, as well as determining ahead of time how to achieve these goals. Once its determined you need a shopping cart, someone else can take the lead on researching and recording the requirements needed for it. Do you want the shopping cart to be built in-house? Should it be SEO-friendly? Easy to use? Each of these is a separate requirement if you want it met. If SEO-friendly is not a requirement, then you can incorporate a shopping cart that has no intention of impressing Google.
Other Types of Requirements
In addition to business requirements, it helps to create User Interface Requirements (UIR) and Functional Requirements (FR). I always suggest a section for SER (Search Engine Requirements), which is where search engine marketing, organic search engine optimization, social media and PPC plans are outlined. In my projects, I also add an UR (Usability Requirement) section.
Functional requirements are a programmers paradise. This is where issues like servers, data bases, programming language and error message procedures are made. Why is this important to know beforehand? Consider search engines. If decisions made in this section conflict with the SER section, the end product will have problems such as complicated URL strings that make engines hiccup.
User interface requirements are extremely helpful for creating web site guidelines. In companies where business units or departments each have their own special place on the web site or Intranet, one set of guidelines keeps the entire site consistent. Usability Requirements are where usability, engagability and accessibility decisions are made. By the way, accessibility should be a business requirement for sites that must meet Section 508 or PAS 78 legal requirements.
Documented Requirements are Your Weapon of Choice
Weve all been in situations where a web site project is in development and one-third of the way through someone from management decides to throw in something like videos of silly pets. For our pet example site, this may work, but where does it go? The design has already been worked out. Does the video go on the homepage? Is it used to help market products or is it some crazy it would be fun to have idea? Does it mess with bandwidth requirements? Youll need to bring in your accessibility people to help make it meet accessibility standards. In other words, a flurry of activity surrounds this new stranger, the video. Rather than simply plopping it in somewhere, a requirements document acts as insurance that doing so wont blow up the site or wreck a key objective.
Make sure every item added to your site is traceable to a requirement. Finally, keep testing to be sure requirements have been met. This is typically done by creating formal test documents but you can also write up checklists for things like user interface and SEO to insure everything you wanted done has been accomplished.
Usability consultant, Kimberly Krause Berg, is the owner of Cre8pc.com, UsabilityEffect.com and Cre8asiteForums. Her work combines usability testing with a working knowledge of search engine optimization.
Images courtesy of tyger_lyllie and sh1mmer
Great Post Kim, I couldn’t agree more! I can’t tell you the number of times having well thought out, documented requirements has helped us to keep a project on track and fight against scope creep.
Great post Kimberley! I’m an SEO but I also dabble with my own sites too. I always have trouble explaining to the developer what I need from the site.
Thanks,
Wes
Thanks for the feedback. It’s a hard topic to get into without putting folks to sleep 🙂
Great post! I’m going to try this as I map out my new website!
Do not forget about the Brand. When we creating a website, we also should think about the company brand. And the creative will give us more traffic to our site.
Great post, I only fell asleep once! Just kidding, I’m forwarding it now 😉
It is best to pen down your requirements and constantly check back to ensure the effort is on track with your objective.
Rif Chia
It really is a great idea to have your clients to put down specific goals of the site and then get together and review and confirm and work towards that goal.
That way if they come in with a random request because a competitor has done something new to their site, you have a fall back and can ask them if their random request is in line with the goals of the site that was established.
Can I just add, that was one of the funniest comics I have read in ages!
I can’t remember when was the last time I asked functional requirments and other such documents when talking about a small website. We only do that for large projects that require months of development
Thanks for the clear explanation of the different types of requirements. I actually just wrote about requirements on my blog yesterday, and a former colleague forwarded me this link. You did a great job at really explaining what’s meant by requirements (in a friendly, personable tone) 🙂
Thanks for this post Kimberley! I’m an SEO but I also dabble with my own sites too.
Kim, First of all thank you so much for all of the great tips. I just recently started building websites. My goal is to start doing affiliate sales first. Then I figured once i got my site ranked good enough then start doing actual sales for my self. Is this the wrong type of aproach? Or is this a good market stratagy?
.-= Baby Gates recently posted: Baby Gates =-.