6 Commonly Ignored Website Requirements & 10 Tips To Remember

The leading cause for website or software application failure is not having a requirements document
prepared and shared with everyone attached to the project. Typically, business and functional
specifications, along with possible web design guidelines are gathered.

What do most requirements documents miss?

The purpose of a formal requirements document is to be sure that everything that appears on the website or application is supposed to be there. In cases such as ecommerce or application driven sites, there’s a better chance that managers from several departments, plus content writers, stakeholders in
upper management and project managers all feel they own a part of the pie.

This means they’ll fight among each other and their designers to put in their special thing, regardless of any logic or purpose behind it.

Requirements are traceable elements and functions. Top companies invest in people who write
test cases that are applied to the project based on the requirements document. The purpose of this
discipline is to find defects, anything that doesn’t look or function as planned and it acts as a backup to
those who still push for something extra, especially towards the end of a build.

If it’s not in the formal requirements and there is no test plan for it, that special extra something can be postponed to version
two or added as an enhancement later.

Today’s Requirements Documents

The days of simple business (goals, priorities, type of site) and functional (back-end, front-end user
interface) requirements are gone. We use the Internet in countless ways, to do countless actions. Our devices have changed.

Search engines have changed, as has search engine marketing. Accessibility, while still at
the bottom of the barrel, is gaining in demand as more people understand what it is and who it is for.

Human factors research and now, the neurosciences, have added reams of data on how we interact with
computers, websites, applications and gadgets.

Therefore, I recommend to anyone wanting to create a proper formal document, that they include the
following sections:

1. Search engine marketing
2. Usability/User experience design
3. Social media marketing
4. Accessibility
5. Content Writing
6. Mobile

Search Engine Marketing Requirements

First and foremost, this not only documents what types of techniques will be applied to the design, but also alerts management of the need for SEO help. Everything should be written down, including organic SEO, paid marketing, link development, and the nitty gritty, such as picture captions, video transcripts
and rules for embedded links.

Usability / User Experience Design

The usability section is often neglected entirely, as evidenced by the enormous volume of websites in the
fashion industry, ecommerce and manufacturing with websites that are frustrating to use. This section
is not only vital for your designers, but also for performance testing and software QA testing. Again,
adding this area to requirements lets management hire out for help if it’s not available in-house.

Test cases are fun to make for this section because it’s easy to check and validate what was done or not.
Look for usability heuristics on the web and use them as guides for requirements. Remember browser
and web standards compliance here, as well as target audience research to help with color, information
architecture and leading tasks.

Social Media Marketing

This may seem odd but one of the common questions these days is where to put
social sharing icons. Should your project include “Share This” and if so, what pages? Will your target
users be comfortable with sharing?

An ecommerce site that wants user generated content may want to
flesh out ideas in this section. Blogs and forums can be put into this section. Don’t limit this area to just
Twitter and Facebook. A social media marketing specialist knows how to truly implement this type of
marketing based on your specific needs.

Accessibility & Compliance Standards

This is not just for blind people. It’s a huge oversight to neglect this area. This section forces
your team to learn if you must follow Section 508 or PAS 78 (UK) guidelines.

Use this section to document requirements for alt attributes, title attributes, and accessibility techniques for forms.
Remember to include guidelines for Attention Deficit Syndrome, contrasts, readability, users who use
JAWS and those with an unsteady hand (MS, Parkinson’s).

Content Writing & Style Guides

Some companies may put content writing in with either usability or search engine marketing. That’s
fine. The important points for nailing down guidelines for content are consistency, embedded link
placement, anchor text rules, video transcripts, how to structure headings and sub-headings, and more.

Be specific if different departments participate with their own content. This is when style sheets and
guidelines are really helpful.

Mobile Device Requirements

Mobile devices are hard to keep up with but if your web site is the kind where your target users may
want to access it while on the go, this section of requirements is a must.

News and ecommerce sites should pay attention to mobile variations. Sites designed in all Flash would fail this requirement. Local
sites are good candidates for mobile design and of course, any site that offers an added “app”.

What Else Should You Be Thinking About?

The key to a robust requirements document is finding an enthusiastic team of skilled people to prepare
it. Someone from all the departments that have a stake in the project must be part of all meetings.

These requirement gathering sessions are great for whiteboard brain storming. The following are some
items that may be overlooked but when considered, will add to an incredibly successful launch of your
final project.

1. Discuss the willingness (or not) of stakeholders on their openness to new things. This is a risk evaluation. Are they willing to try new things and if so, what are some things they may want to try.
2. Training. Employees are a great source for word of mouth marketing. Are there ways to include
   them in marketing? If there are actual storefronts, train associates in how to ask questions
   to get customer feedback that can be used later for social marketing or the actual design and
   location for web tasks.
3. Don’t neglect local search. The requirements and marketing for local sites is its own niche.
4. Conversions. Yes, it’s crazy but everybody thinks their site will magically bring in revenue. The
   usability section must include persuasive design techniques.
5. Analytics shouldn’t be an afterthought. If your site is going to relying on Google Analytics, the
   code can be added during the build in preparation for going live.
6. Testing. Never put this at the end. Split A/B testing can be done on test servers for example.
   And of course, test cases prepared based on the requirements can be applied once the build
   begins.
7. Target marketing research and demographics should be added to the formal document. You
   want everyone to be in agreement, as well as unified in their understanding of who they’re
   focused on.
8. Reputation management tracking can be added to the social media marketing section. It won’t
   come in until after launch but make sure it’s included in the overall plan.
9. Establish a process that allows key stakeholders to know what key decisions are and allow them
   to sign off or discuss. Keep them in the loop, even if they say they don’t want to be bothered.
10. CYA. This is main reason I promote requirements documentation. Cover your ass. With
    everything documented and traceable to top goals, you get a solid foundation to work from. By
    communicating every change (called “Change management”), every defect, every fix, and every
    breath in writing, no one can come back and claim something was missed or done without their
    knowledge.

If you already have a website, it’s not too late to create a requirements document. It may be best to
have someone outside prepare it so it’s objective and something isn’t subconsciously overlooked.

It’s never too late to test what exists now and re-test and track after a repair. I’ve seen even the smallest changes
make a direct and immediate increase in conversions. Requirements gathering are well worth your
investment in time and resources.