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.
Requirements Gathering Takes a Team
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:
Search engine marketing
Usability/User experience design
Social media marketing
Accessibility
Content Writing
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”.
Map out everything at the beginning of your project.
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.
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.
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.
Don’t neglect local search. The requirements and marketing for local sites is its own niche.
Conversions. Yes, it’s crazy but everybody thinks their site will magically bring in revenue. The usability section must include persuasive design techniques.
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.
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.
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.
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.
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.
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.
