Skip to content
Thoughtfarmer intranet blog
Intranet Management

How to better communicate your intranet requirements

Capturing the needs of stakeholders is important, but the form of those needs and requirements is critical. Learn how to effectively communicate your intranet requirements to ensure you get the right platform for your organization.

4 minute read
intranet content
You might also like…
Intranet use cases Thumbnail
Intranet use cases

Are you a company looking for a new intranet? Are you looking for a way to make your evaluation process a lot easier?

Selecting an intranet solution can feel overwhelming. There are many different products and platforms available, which makes differentiating between them all a little challenging.

Most organizations will appoint a project owner (typically a communications manager, IT manager, or HR manager) to gather requirements from project stakeholders, identify a list of vendors, and evaluate these tools against the requirements to make a recommendation and selection.

While this process can work, it often results in a solution that doesn’t quite meet the needs of its users. Software is often purchased based on features, whereas success hinges on whether the intranet is easy to use. Sure the platform has all (or most) of the features deemed important, but if they are difficult to use, employees won’t use the intranet, and it will quickly become a wasted resource. 

How can organizations avoid this trap? Capturing the needs of stakeholders is important, but how we capture those needs and requirements is critical.

How can use cases impact your intranet journey?

Use cases focus on users, and can go a long way in helping you push forward a business case for intranet software.

Read more
Intranet use cases

Communicating intranet requirements

A while back we received a set of requirements from a potential client who was in the process of evaluating ThoughtFarmer. They sent us a detailed spreadsheet with their requirements, but what was different was the way they documented their requirements.

Instead of a list of features written as “the system shall do X,” they instead took each requirement and placed it in the context of the user. It’s a user-centered requirement, without a massively detailed use case.

Each requirement was written using the following format:

As a [role of user] I would like to [description of task] so that I can [description of end goal]

Here’s an example of a single requirement.

As a… I would like… So that…
User to be able to post blogs about the things I am working on people can keep up to date with things I do, which may be relevant for them as well

What’s special about this way of documenting intranet requirements is that they identified who this requirement was for: the user.

They also included requirements from many other users, including the Intranet Manager, the IT Manager, and the Intranet Editor. We quickly got a sense of the different roles they had involved in their intranet, which helped me get a sense of their would-be intranet requirements.

In the above example, they stated what they wanted: the ability to blog. 

Specifically, they wanted users to be able to write about what they were working on. They also stated why they wanted such a feature: to keep people informed about what their colleagues were working on. In short, they gave us a bit more context around the request: we want a blog and here’s why.

The advantage for us (as a vendor) is that context removes the requirement to work with assumptions. If you simply poll your stakeholders, you might come back with a specific feature, but additional context may suggest an alternative feature—or customization of an existing feature—may be more appropriate to achieve a specific end goal.

Next steps for documenting intranet requirements

When documenting the requirements for your intranet, ask yourself the following:

  • Who’s the user?
  • What do they want?
  • Why?

This approach will go a lot further in clearly communicating your intranet requirements in the form of the needs and wants of your end users, instead of a long list of features.

In the case of this potential client, we were able to clearly articulate how ThoughtFarmer met their users’ needs, and they went on to purchase and successfully implement ThoughtFarmer inside their organization.

If you’re interested in using this approach, we dive deep into some examples in our Intranet Use Cases guide.  

Editor’s Note: This post was originally published in November 2009 and has been completely revamped and updated for accuracy and comprehensiveness.