Designing a good intranet by collecting requirements
Designing a good intranet is difficult, not least because ‘good’ means so many different things to different organizations.
Some are looking for a collaboration tool, a means to share work and ideas. For others, it is all about documents, how they are stored, and how they are filed. Others still want something more like a traditional intranet, with news, department sites and so on.
So how do we ensure that at the start of a project we are collecting the right requirements for these very different systems? There are numerous means and methods, but the number one rule we always stick to is this:
“Make sure you are talking to the right people.”
Our requirement gathering process can take many forms depending on the problems we are trying to solve. We often run workshops, tackling subject areas like 'infrastructure,' 'metadata,’ and 'content migration.' These workshops could involve shadowing people or systems, round table discussions with a particular group, or one-on-one interviews.
But no matter the method, no matter the system being designed, it is imperative we are talking to the correct people.
Let’s look at an example of a classic company intranet solution
It is easy, on these types of projects, to spend a lot of time with the ‘project board’ and the senior management team. The first group have been set up to deal with the project and the second are invariably paying for it. Both will have strong views about what the intranet needs to do. It is important however to focus requirements gathering on the majority of normal staff, the people on the ‘shop floor,' who will use the intranet day to day. It is these people that have the best insight into what the intranet should (and shouldn’t do), simply because they are the primary users.
