7 Principles for Great Intranet Design

By Ronnie MacPherson, ImpactReady Knowledge Advisor

The development, launch and management of an intranet can be a daunting prospect for any organisation. Introducing new technology into the workplace is often challenging, but intranets have gained particular notoriety for being especially difficult to embed. To an extent this reputation is justified: there are countless examples of intranets developed at great expense, only to languish in a state of disuse, barely noticed by the employees who were supposed to benefit most. However, intranets can also have an impact as positive and significant as the other communication innovations that have revolutionised the workplace.

The following note sets out some key principles to bear in mind during intranet development, launch and management: how can the problems associated with intranet design be avoided and, more importantly, how can the value of an intranet be maximised for an organisation?

Principle 1: An intranet is not just like a website

People often consider an intranet to be akin to a website: certainly, an intranet is broadly analogous to a website and this comparison can serve as useful shorthand when introducing the concept of an intranet to new users. However, the danger in conceptualising and presenting intranets in this way risks introducing certain expectations and preconceptions as to what an intranet should do and how it should perform.

For many people – and especially for less technically literate individuals – websites are still a relatively one-way, passive form of communication: people go to websites to search for information, they retrieve that information, then they leave. While intranets can and do serve a similar function, far more important is the genuine interactivity of intranets: users will almost always be contributing and maintaining information just as much as they retrieve information. As more people engage with social media, this concept of genuine two-way interactivity is becoming more familiar, but it is vital to remember that many people still have little exposure to such platforms, and may be very apprehensive of engaging in a web-based technology that requires them to regularly generate and maintain content.

On a similar note, many people still conceive of the internet as a relatively chaotic and frequently untrustworthy domain. In many instances people may transfer part or all of these perceptions and concerns to their organisation’s intranet and, accordingly, they could potentially lack the desire or confidence to fully engage with the platform.

In summary, comparing intranets to websites can be useful when trying to describe the broad concept, but it is vital to identify and describe the differences alongside the similarities.

Principle 2: Organisation, processes and staff first… technology second

Poor technology and software are undeniably a major cause behind many failed intranets and – due in part to the clear visibility of poor technology – it is perhaps the most common aspect that attracts blame for failed intranets.

Arguably though, a far greater cause of failure is the conceptualisation and treatment of intranets as a technical solution, rather than as an integral part of an organisation’s processes. Most intranets fail because of an overly techno-centric, top-down approach to design, implementation and maintenance: the intranet may be technically ‘perfect’, but without the genuine participation and involvement of the users – the organisation’s workforce – how can the design possibly reflect the workforce’s processes and needs and, by extension, the organisation’s processes and needs?

The clearest (and possibly most frequent) example of this form of failure arises through the tendency for organisations to devolve responsibility for intranet development and management to their IT department. But without continual strategic guidance and design input from an organisation’s ‘core’ workforce (including management), and without the involvement of the staff that are closest to an organisation’s day-to-day processes, there will always be a risk that a technically beautiful but functionally useless intranet will be delivered.

Successful intranets are designed around the organisation’s needs, not the technology’s needs. Too often, organisations develop intranets that have all manner of bells and whistles, but are not designed to cope with the specific processes of the organisation; even worse, some organisations then try and change their own processes so that they satisfy the requirements of the technology, with a frequent result being organisational inefficiency and, more terminally, staff frustration.

Organisations should instead treat intranet development as any other internal change process, involving staff from all areas of the organisation to develop a comprehensive, shared understanding as to what processes could be improved by an intranet, and what processes work best ‘offline’. Such an approach has multiple advantages:
Involving staff from all areas of the organisation is likely to reveal day-to-day processes and tasks that management or ICT staff would not have identified
Conversely, involving a broad base of staff could identify processes that are not suitable for integration within the intranet: it can serve as a ‘reality check’ against potentially overambitious technical solutions
A bottom-up, participative design is more likely to increase staff buy-in and ownership when compared to an imposed, top-down, techno-centric solution

Principle 3: Make it relevant

Staff will only engage with an intranet if it adds clear value to their day-to-day work. The advantages of any given intranet tool – whether in terms of ease, time efficiencies, or informational value – need to be demonstrable and transparent from the outset. This demonstration of relevance is particularly important for less technically literate staff: they may be less confident and more sceptical, so it is vital that benefits are highlighted clearly and related directly to their own jobs. Ultimately, staff should not feel that using the intranet is a chore – they will only use the system if it saves them time or adds value to their daily work in other ways.

Principle 4: Keep it simple

Closely related to the principle of relevance is the principle of keeping design simple. Techno-centric designs often throw numerous tools into the system, only a handful of which may ever be used by the organisation. However, staff-led designs often suffer from the same problem: a balance needs to be struck between the enthusiasm and demand for tools from more technically literate staff, and the need to ensure buy-in and participation from the less technically literate staff. A simpler design that initially focuses on supporting only a handful of key organisational processes is far more likely to win comprehensive support from across the staff base than a system that is all-singing, all-dancing, but potentially overwhelming. Additional tools and processes can be brought in gradually, as the whole organisation becomes more familiar with the system and its basic functionalities.

Aside from the general principle of simplicity, there are two specific design principles that are commonly applied to augment simplicity and ease of use:
One-click navigation: as far as possible, the intranet should be structured so that the user is only one or two clicks away from their desired destination: avoid deep, hierarchal navigation structures wherever possible
Strong search functionality: due in part to the dominance of Google, many (if not most) users will go straight to the search box, rather than trying to navigate the intranet: as such, a comprehensive search facility is essential

Principle 5: Don’t force collaboration

Virtually all intranet software will come with the option of collaborative tools such as discussion boards and wikis: more pertinently, virtually all intranet software vigorously pushes these collaborative tools, often holding them up as the centrepiece of the system. But these tools tend to be quite unappealing to less technically literate staff and, even with more technically literate staff, a critical mass of regularly active users is often necessary for these tools to take root and show their value. Certainly, there will be instances when specific organisational tasks gain considerable value from the use of collaborative tools, but the temptation should be resisted to ‘force’ these tools on the organisation, despite the hard sell given by software companies.

On a related note, intranet software also tends to promote its ‘personalisation’ capabilities: the ability for individual users to change the intranet design to suit their aesthetic preferences. However, personalisation has little functional value and could become one more (unnecessary) element for staff to take on board. In keeping with all the above principles, avoid promoting personalisation until any system is well bedded in.

Principle 6: Managing the intranet is not an IT task

As implied above, intranets are more likely to reflect the needs of the organisation if design and development is overseen by a broad staff base, rather than the IT department in isolation. The same applies for the ongoing day-to-day management of the intranet: the system should not be conceived of as an IT platform, rather it should be conceived of – and managed as – a process as integral to the organisation as human resources or finance. Of course, the technical development and maintenance will need to be supported by IT professionals, but decisions around direction and functionality should rest with staff that are close to core organisational processes. The ongoing oversight and strategic responsibility for the intranet should be allocated within the existing organisational structures accordingly.

Extending from this, day-to-day intranet support can also be delivered outside of the IT department. Most day-to-day support requirements will not be truly ‘technical’ in nature; rather they will come from staff that either have limited technical literacy or are simply unfamiliar with the system, and will revolve around the need to learn or understand simple tasks or navigational issues. Support for such requests can be provided by intranet ‘champions’ that are familiar with the system and – crucially – are more familiar with core organisational processes than IT department staff. It may also be less daunting for staff to approach these ‘champions’ and, potentially, the champions could fulfil a triage role, ensuring only the genuinely technical enquiries are forwarded to the IT department or specialists.

Principle 7: Incentivise intranet usage

A bottom-up, staff-led approach to design and management will help to ensure the relevance of the system, and should help to ensure day-to-day participation. However, if intranet usage is not comprehensive and processes are suffering due to non-participation, the ‘carrot’ of the staff-led approach may need to be accompanied by a ‘stick’: it may become necessary to link staff objectives and performance assessment to intranet usage. For example, if project progress reports or indicator updates are to be submitted via the intranet, are these being processed completely and on time?


While their reputation is often negative, intranets can and do add genuine value to an organisation, improving efficiencies and communications in as fundamental a way as email, faxes and telephones have before. Central to the development and acceptance of an intranet is the way in which it is conceived and treated by staff and management alike. Intranets should not be thought of as an IT product: rather, they are a core organisational function, supporting and improving day-to-day processes and communications. With this realisation in place, and with the buy-in and participation of staff, an intranet can become as intuitive, normalised and integral as sending an email or picking up a phone.

Applying these principles to SharePoint

Don’t get tempted by the many bells and whistles within Sharepoint. Work out what is needed by each team (most probably just the ‘shared drive’ function to start with), and keep the design simple and focussed on those core functions.
Practically, this may be best achieved by identifying someone on the staff team who is keen to learn the ropes, then asking them to design the various team sites that the organisation requires… but encourage them to maintain a consistent design across those team sites as far as possible.

Microsoft really push the capability for individual teams to design their own site, but this can easily result in a fragmented, incoherent site that just imposes another technical chore on each team (and one that requires quite a steep learning curve at that). It is better to develop the necessary site-building skills amongst a handful of ‘champions’, rather than getting many people to build technical skills that they will rarely if ever use again.

Don’t get distracted with functions such as ‘personalisation’ that offer limited real value to performance. If staff want to do this and have the technical know-how, they’ll do it under their own steam… but it doesn’t really have any practical value and will just serve to confuse the less IT literate staff. Despite this, much of the Sharepoint training we’ve seen really pushes the personalisation aspect.

If your organisation is locked into a support contract with an external Sharepoint support company, rather than just using them as troubleshooters, get that company to send over examples of ‘good’ Sharepoint intranets… i.e. try and access design and usability support from the company, rather than plain technical support.

Most importantly, if Sharepoint management is already embedded within the IT department, decentralise it to user-departments, or at least get a senior manager onto the steering group. Some ‘pure’ IT specialists can have trouble understanding why this shiny new software is so under-used. This may be blamed on a lack of IT literacy amongst the staff base, which can further result in a vicious circle of more ‘walls’ going up between IT staff and other departments.