Some hidden factors that should influence your intranet design thinking

Something I’ve noticed with all major Digital Workplace and Intranet projects is that a lot of people focus on the important features and forget the important factors.

When people think about designing an intranet or digital workplace, there are a myriad of tools and methodologies available to help them consider the features and content they need to support. Today, most projects are getting pretty successful at looking at these things:

  • Content – What the site says
  • Features – Everything from feeds to self-service elements
  • Navigation – What do you need to navigate to, and why?
  • Corporate Identity – What should it look like? Of course it needs have the corporate identity.
  • Usability – Make it easy for your reader? Can the user orientate themselves? Can they find their way around?

But there are a number of more subtle balancing factors which you can play with to determine what lands on your pages and they have a non-traditional impact on the simple answers we get from normal business requirement analysis.


Do the choices you are making reflect the corporate strategy? Are you able to adapt when that strategy changes?

If your strategy is to consolidate there is a strong case for a single corporate intranet but if your strategy is to have diverse brands with diverse strategies then a single corporate intranet isn’t really going to add value. However, syndicating content directly into the separate intranets may just be a good answer.

Brand values

Much deeper than corporate identity, does the intranet represent your values?

If your values encourage openness and active feedback, then refusing to put a commenting facility on news doesn’t really live up to that. It’s easy to send out the wrong message and often intranets fail to give any really meaningful message at all.

Staff Impact

Can you roll out without training people? Are you actually changing something more fundamental then just the screen they are looking at?

When you roll out your intranet then all the fantastic work you’ve done on usability should minimize the roll out impact. But the soft changes can be really quite far reaching, if you think back to the dim and distant past email destroyed many quick discussions around the coffee machine, stopped people picking up the telephone and actually slowed down the process of communicating especially when tonality needed consideration.


Can you actually manage the structure that you have set in place? Do you have the resources, governance and willingness to take the journey you have started?

I often see great expectations for what a new Intranet will deliver, but the consideration of how much resource can be put into generating, editing and controlling content is often overlooked. There is no point designing a highly visual news rich corporate communications portal if you don’t own have a couple of good writers, a plethora of good images and a copy of Photoshop.

The X factor:

Of course there are also a secret set herbs and spices that actually deliver the real flavour.. this is where it gets fun.  It’s the behaviour you want to encourage, or even drive. This is what transforms organisations and this is where you need to consider usability in a totally different way.

I put it to you that it’s not always about making things easier for your users. If you want to change the way people deal with polices or standard operating procedures, you may want to make it harder for them to find a policy stored in collaboration spaces than it is to find official (and governed) policies.

The take home is that intranets and digital workplaces are complex beasts. Really good system design has to go beyond that of the internet, we don’t want to make people work hard to use an intranet but we might want to help them learn new ways to work.

The Room of Requirement – 10 Magical Tips for Intranet Requirement Gathering

Harry Potter had it all, amidst the moving staircases, the ghosts and the young wizards and witches, J.K. Rowling gave him the room of requirement. A perfect addition to any school for young wizards and  a stunning example of personalisation at its best:

“It is a room that a person can only enter when they have real need of it. Sometimes it is there, and sometimes it is not, but when it appears, it is always equipped for the seeker’s needs”.

Source: Harry Potter and the Order of the Phoenix  by J.K. Rowling

It has some interesting features when we think of it in Intranet terms:

  • It’s there when it’s needed; de-cluttering the halls of Hogwarts when it’s not needed
  • It’s easy to get there and find it when you actually do need it
  • It’s equipped for the seeker’s need, so it’s going to help you do the task that you want to do
  • It’s not decorated with posters and news items that nobody wants to read, just the relevant ones about long lost relatives and intrigue in the ministry of magic
  • Harry trained an army in it so it’s got some good collaboration capabilities
  • It kept the enemy out, until they used a totally brute force attack, so good security features

On the downside

  • It did have an awful lot of clutter in it though… good enough to hide things that you don’t want to be re-found
  • It didn’t really present a common user experience

I’m sure that Harry wasn’t really all that interested in the Hogwarts intranet, but it would be interesting to see what a typical user made of the Room. Especially given the way requirements are often defined in Intranet Projects.

  • ‘I don’t know what I want, but I’ll know it when I see it’
  • ‘Make sure it’s got all these social features that we’ve heard so much about and plate-spinning elephants’, even if they don’t fit in the doorway.
  • ‘Can’t you just adapt our Internet?’
  • ‘Could the door be a mixture of blue and green with small red spots to highlight where the door knobs are?’, ‘Content? That’s professor Snape’s department’

Requirement gathering for an Intranet project is an art form and in my experience there are a few things you should bear in mind. Here are 10 magical thoughts about business requirements and the gathering thereof.

Thought 1:

There is a difference between business requirements and requirements gathered from the business. Ask 20,000 people if they think the Intranet should stream video the answer will be yes, ask the IT department and the CFO for the money to upgrade the network to support 200 of those people concurrently live streaming the video, the answer may be quite different.

Thought 2:

There is often more to a requirement than meets the eye, it’s important to tease out the real detail. It’s not just a matter of requirement = function, requirement may be resolved with a number of different functions. If your requirements document says ‘we need a personalized news channel’ you’ve probably got something wrong. If it says ‘we need the ability to target specific messages to specific groups of employees’ which will be solved using a personalized news channel, a targeting system based on a taxonomy or channel approach, coupled with features to help employees find items that are no longer on the front page’ then you’re probably going more in the right direction.

Thought 3:

A lot of requirements for Intranets can be copy paste from other projects, even down to the functional description, but beware, just because two different projects use news on the homepage, it doesn’t mean that the REQUIREMENTS for news are the same. One company may require news to keep the employees informed whilst reflecting a radically different Strategy to another, for example showing which department the news came may be interesting for the user, but it may also undermine a single company approach and would be better served with a topic based classification.

Thought 4:

Some requirements will vanish when you follow through the consequences with the business. A seemingly simple function like a CEO blog may be much less attractive when the commitment to generate the content is required before the function to display it can be built.

Thought 5:

There will be more requirements than budget. You will have to prioritise.

Thought 6:

Requirements change, come and go. System requirements should be able to support different business requirements as flexibly as possible. The more you can match sets of generic functions to different requirements the more agile you will be with your workplace.

Thought 7:

Some project requirements may work against the current interests of parts of the business (usually individual department heads). You may need to find ways to create buy-in with transformational requirements. For example, replacing many small departmental intranets with a single portal will lead to ‘loss of control’ & ‘lack of agility’ type discussions, often culminating in masterly inactivity when it comes to migration. Providing migration assistance, methods for spreading migration over a longer period and improved ways of doing things specific for that stakeholder may be necessary.

Thought 8:

Be prepared to launch and learn. Put methods in place for continuing to gather, prioritise, refine and shape. What you think your requirements are can change based on how the system is used. A very detailed permissions model for editors may be so restrictive in practice that it needs revamping totally to be usable in the real world. Which leads to rule 9…

Thought 9:

Think about requirements in steps, are there ways to implement part of the requirements whilst testing the true case for more detailed elements. This can get you some quick wins with the business and help you to be sure that requirements are requirements.

Thought 10:

Don’t get cursed. It’s easy to get hexed into Analysis Paralysis, a state of perpetual requirements gathering. Believe me this is not a magical place to be!