Website requirements document best practices

Building a website or selecting a content management system (CMS) requires a clear idea of what features and functionality the site will need. How you define and implement those features will go a long way in determining the success of the site. That’s why a comprehensive requirements document, which gives your site developers a clear description of site functionality and workflow and the objectives behind that functionality is critical.

What should a requirements document include?   Alas, there is no magic fill-in-the-blanks template you can finish in an hour.  You need to do some research and thinking.  However, carefully answering these 6 questions will serve as a pretty good website requirements template:

1. Audience needs: How should your website serve its target audience?

Do you have evidence that shows your readers want to be served that way? For example, you may provide industry news coverage because the web makes it possible to publish news quickly. That’s fine, but is that what your readers really want? Talk to them, look at your web analytics, and look at your competitors. Don’t just look at how much traffic you get for a particular type of content; also look at how long that content attracts readers after it’s posted. If it’s basically dead after 2-3 days, your readers are telling you something about the value of the content.
What about the devices your readers use to consume your content? It’s important to understand how smartphones, tablets, and computers are being used. There is plenty of insight in your analytics, but if your current site is a disaster on a smartphone, then you are almost certainly losing readers. I can’t imagine any media company launching (or redesigning) a website that doesn’t use responsive design principles.

2. Advertiser needs: Is your site set up to deliver the marketing solutions your advertisers are looking for?

If your advertisers are focused on getting sales leads, then make sure you have a good form-building tool and a way to capture and report registration data. If video is the hot ticket for advertisers, make sure that makes the short list. Display advertising still sells, but it’s not doing as well as it used to. Don’t load your site up with a lot of ad positions that will end up filled with house ads. The requirements document should also address the following questions:

3. Who are your competitors and what are they doing? How do their sites compare in terms of traffic, functionality, freshness and revenue?

When you researched reader needs, did you discover an underserved segment that your competitors are overlooking? Where are they vulnerable to a smarter approach to serving readers or advertisers? You’ll want to spend some time exploring competitor websites and looking at services like and to get an idea of traffic levels, audience makeup, and reader engagement.

4. How will your website stand out?

Think about how you can set your website apart in your market for both readers and advertisers. Copying a more successful direct competitor almost never works, so resist the temptation. Boil these unique selling propositions (USPs) down to no more than three clear sentences, and make sure everything you build incorporates them at some level.

5. How will your editors, marketers and others use the CMS?

Internal users tend to be largely ignored in the redesign process. If you want to improve your editors’ lives and also increase their productivity, spend some time to understand editorial workflow. The administrative screens of most modern content management systems have improved a great deal in the past couple of years, but all of them can benefit from some pruning of links and features only developers care about, and logical ordering and labeling of those that remain. This is especially true of open-source platforms like Drupal.

6. Who will manage the community?

Article and forum comments can bolster your brand with thoughtful discourse, or they can tarnish your reputation with nasty comments or spam. Make sure someone is explicitly responsible for moderating user-generated content on the site, as well as for “priming the pump” to seed discussions and set the appropriate tone.

Time to talk to the developer

With a list of prioritized features, it’s time talk with your developer. She’ll quickly point out areas that need more detail. For example, if you specified “site registration” without explaining the steps of the registration process, you’re not done yet. If you want article ratings, do you want a 1-5 scale or a thumbs-up/thumbs-down? Can anyone comment on articles, or must you be a registered user?

These are business decisions, not technical ones. If you’re not sure how you want a process to work, investigate how other sites do it and develop a rationale for what will work best for your editors, readers and advertisers.

Write the creative brief

When you have fully described how your site and each of its features will be used, the requirements document is now ready for the designer (or to start building if you’re using a prebuilt design template.  If you do have a designer ready to execute a custom design for your site, you’ll want to now write a creative brief based on what you learned from putting together the requirements document.  You’ll get a better design, and more quickly, by following the requirements doc with a creative brief.

Taking the time to build a detailed requirements document will make far better use of your developer’s time, and will lead to a much better website for your brand.

A version of this post originally appeared on eMedia Vitals.

Leave a Reply


You are commenting using your account. Log Out /  Change )

Google photo


Twitter picture


Facebook photo


Connecting to %s