The classic texts of project management outline the importance of initial planning and design activities. While they only consist of 10-30% of the project, they lay the groundwork for everything to come.

This is no different in the world of SharePoint intranets. Quite the contrary: with the breadth of SharePoint, and the effort and cost often required, it’s even more important to start with a clear plan.

Based on our experience across many organisations, this is our rule of thumb:

Spend 10-15% of the budget of SharePoint intranet projects on planning and design.

What does this mean in practice? Let’s explore a range of projects at different scales, with some example activities (these lists are not compreshensive):

Small, mostly out-of-the-box deployment

Total spend: $25k
10-15% on planning & design: $3.5k

The goal is to deploy a simple intranet using out-of-the-box SharePoint capabilities wherever possible, using configuration rather than development or customisation. Software licenses may be minimal, with external developer support around deployment and setup.

Planning and design activities should include:

• determine an overall scope (what will the intranet do?)
• confirm what SharePoint functionality will be most useful and successful
• learn lessons from past intranet projects

Medium-sized corporate intranet

Total spend: $150k
10-15% on planning & design: $20k

A typical intranet project, deploying SharePoint as the platform for a redesigned corporate intranet. Core SharePoint features are supplemented with development to deliver key capabilities. Typically involves a mix of publishing and collaboration.

Planning and design activities should include:

• uncover and confirming staff needs
• determine an overall intranet strategy and scope
• develop a concrete project plan (beyond just technical aspects)
• select key SharePoint functionality required
• target customisation and development activities
• apply best-practice techniques to determine navigation and design
• establish simple but effective governance and ongoing management

Strategic intranet project

Total spend: $500k
10-15% on planning & design: $75k

Larger intranet projects, either deploying SharePoint in big organisations, or aiming to go beyond a “standard” intranet. Significant amounts of customisation and development will be used to meet specific business needs, and to provide a strong foundation for future growth. Significant use of all aspects of SharePoint, including integration with other systems.

Planning and design activities should include:

• create a common vision amongst all stakeholders
• determine an overall intranet strategy and scope
• create a roadmap for short- and long-term activities
• establish pilots for leading-edge features
• conduct a full user-centred design process for the intranet
• establish the best project team
• build in-house intranet expertise and knowledge
• execute a change management and adoption plan
• establish robust governance
• draw on global intranet best practices

10-15% of planning doubles the business benefits

While getting the technical deployment of SharePoint right is obviously crucial, the best implementation in the world is worth nothing if it misses the mark when it comes to business and staff needs.

To often, implementation starts before the most basic of questions are answered (such as: what will the intranet actually do?). Without an overall vision, plan and scope, it becomes very difficult to make the hundreds of practical decisions that are involved in deploying a SharePoint intranet.

For this reason, this is our experience:

The 10-15% spent on design and planning doubles the business benefits delivered by a SharePoint intranet project.

Time and time again, we’ve seen a small amount of up-front planning and design work have a huge impact on SharePoint intranet projects. The project progresses faster, with less stress and uncertainty, delivering a result that works well for staff and the business.

We do the 10-15%

Step Two have been the leading experts in the intranet space for over a decade. Our role is to know what works (and what doesn’t), and to provide practical methodologies for intranet teams to follow.

In a SharePoint project, we don’t deploy or write code (there are plenty of people who do). Our role is to work with or alongside the geeks, providing the 10-15% of planning and design activities that ensures project success.

We draw on our unique experience, insight into intranet projects across hundreds of organisations, and a clear understanding of the SharePoint platform. Bringing this together, we provide the techniques, answers, examples and screenshots that maximise the value of SharePoint investments.

We can also provide ongoing support, to keep things on track, and to see the project through to a successful conclusion.

Want to know more? Get in touch

Developing navigation to ensure the pathways and language are optimised to steer staff to the information they seek is fundamental to a successful solution. A number of familiar and well established user-centred design (UCD) techniques can be called upon to develop this navigation.

Essential UCD techniques include:

• content inventory and evaluation
• card sorting
• information architecture development
• wireframe development
• usability testing

However if the architecture itself is not tested, significant time invested in wireframe development and site build may be wasted.

Having a simple and effective method for assessing the proposed site architecture, before wireframing, allows the designer to refine and retest the site map before developing site visuals which tend to be more difficult and expensive to rework.

[October article by Stephen Byrne, read the full article]

There are many articles and blog posts out there that measure the value of this UCD technique. This article focuses on a more specific aspect of the technique, which comes out of experience conducting a number of projects using card sorting — the use of offline and online card sorting methods.

What is card sorting?

Card sorting is an activity which asks participants to sort a selection of content — web pages, menu options etc — into categories that make sense to the individual or group.

Conducting this activity provides researchers with a user’s perspective into the groupings, and will typically inform information architecture (IA) designs.

It’s a simple technique, and perhaps the most widely used during intranet and website redesigns. Run with multiple groups of staff, it can provide valuable insights.

(August article by Alex Manchester, read the full article)

This is shown in the way that the current crop of mobile applications are designed:

• We are rarely asked to login to mobile applications, once our identity is initially authenticated.
• Our personal identity is a key element of many mobile applications.
• Applications are tailored to our personal needs, providing simple interfaces and a handful of relevant options.
• Location in the real world (my current location) is used in many applications.
• Applications are designed for a single user (“me”), tied to the device itself.

All of this has some big consequences for enterprise solutions.

An impersonal enterprise experience

On the whole, enterprise apps are impersonal. Intranets provide information for everyone, and users are expected to find for themselves what is relevant to their situation. Even when some personalisation or tailoring is done, it is very limited, often restricted to the homepage.

When using enterprise applications, users are often asked to login. These usernames and passwords may vary from system to system, and few applications have a “remember me” option. Once in the apps, users are again expected to work through long menus of all-purpose options.

Replicating this experience when delivering mobile enterprise applications is very problematic. Users, conditioned by consumer apps, will find impersonal enterprise apps to be clunky and frustrating. Worse, the productivity gains hoped for will not be realised, as users struggle through complex options on small handheld devices.

Designing personal enterprise apps

Mobile enterprise apps should be as personal as consumer apps. We know much more about our staff and their needs than application developers know about consumers. Staff have a long-term engagement with the business, rather than the fleeting interest of consumers.

Delivering personal applications simplifies the user experience, and delivers greater productivity benefits. It also means that the full capabilities of mobile devices are exploited, rather than just delivering “handheld desktop apps”.

To do this:

• Have staff login once, remembered for all future uses.
• If this isn’t possible, ensure that staff only login in once per session, with single sign-on provided for all apps and functionality.
• Make personal identity the foundation for every piece of mobile functionality, from the mobile intranet to specific enterprise mobile apps.
• Tailor information and functionality to ensure it is specific to the staff member. For example, the five relevant leave policies should be displayed, not a list of 100 documents. Similarly, menus should list only those HR actions that can be taken right now, not every possibility for the whole organisation.
• Proactively deliver information and notifications, using the functionality of the mobile device to do so in real-time, where possible.
• Exploit the full capabilities of mobile devices, such as targeting information based on the staff member’s current location in the real world.

(Of course, these approaches generate some security and information management challenges. In practice, these may be better handled at the device level, rather than burdening each app with a security straightjacket. As experience grows in delivering enterprise apps, practical approaches will become better understood.)

How will you deliver a personal experience for staff?

The intranet can suffer and benefit from this collective organisational shorthand. Good intranet teams need to ensure any jargon used on top level pages such as home page and landing pages is appropriate.

For example, ‘Richard’s blog’ might be highly appropriate when it is owned by the CEO, often referred to and covered during induction training. On the other hand, ‘OSKA’ might be used as the name of the online training system based on the software used, and have no real relevance at all to staff.

The key factor in assessing any jargon-like terms that appear on the intranet is to determine the level of understanding of the terms by all staff. Do not assume that everyone knows what it all means.

How to jargon test

Depending on the size and diversity of the organisation, there are many ways to jargon test the intranet. One of the most effective ways is to review possible jargon words with new starters. This can be as simple as a joint discussion while reviewing the intranet online.

A more sophisticated option is to identify and list possible jargon words and then ask staff to share their understandings of the words. It is very important to ensure that staff do not feel like they are being tested, and they understand they are helping you with testing the intranet. One of the difficulties with this approach can be that words in the list might have different meanings in different contexts.

[November article by Catherine Grenfell, read the full article]

In practice, teams given the task of designing and deploying enterprise search find these projects much more complex. Many questions need to be answered:

• Which information sources should be indexed?
• How should the results be presented?
• What functionality should be provided for staff?

To answer these questions, teams need a clear vision of the desired end state, including an understand of staff needs and tasks.

With power comes complexity

The problem with enterprise search tools is that they are too good. Most modern search tools can index an incredible range of information sources, including but not limited to:

• intranet(s)
• public website(s)
• document and records management system
• staff directory
• collaboration spaces
• business systems
• fileshares
• emails
• third-party information sources

[November article, read the full article]

• to find a specific piece of information
• to complete a task

In both cases, staff come to the intranet at the point of need, with a clear goal in mind. If the intranet is well-designed, and they can find what they are looking for, they will then close the intranet and get back on with their job.

Intranet teams work hard to deliver this vision, carefully crafting the homepage and top-level navigation menus. Major sections, such as HR, IT and Finance are also designed to improve task completion.

This still leaves a lot of content. In any larger organisation, there will be many business unit sites or sections on the intranet, and these can quickly become filled with ‘blah blah’ or ‘about us’ content.

Irrelevant content and poor page designs can have a huge impact on the intranet as a whole, reducing usability, findability and staff satisfaction.

Even in the absence of a major intranet redesign or content cleanup, redeveloping business unit landing pages (their ‘shop windows’) can greatly improve the site.

This article will outline the problems of poor design, and will share examples of how to deliver business unit sites that work. Best of all, these improvements can be made incrementally, within the limits of the central team’s time and resources.

[October KM Column, read the full article]

While these discussions echo the policies established for public-facing websites, intranets may require very different approaches.

Even on public sites, browsing the web shows that practices have changed greatly over the last few years. Previously, any link to an ‘external’ site (managed by another organisation) would open in a new window (or a new tab, in modern browsers). On government sites, there would even be an intermediate page, warning that ‘you are leaving this site and we are not responsible for the content that you may read’.

On recent websites, links opening in new windows have become much rarer, suggesting that both practices and user expectations are changing. So what should be done on intranets?

Many possibilities

There are a wide range of policies that could be put in place:

• all links open in the same window (no new windows)
• links to public (external) sites open in new windows (or new tabs)
• links to systems or applications open in new windows
• links to documents or other non-web content open in new windows
  
• any link that takes the user away from the current task open in new windows

• links to other internal ‘intranet sites’ open in new windows

[September 2010 one-pager by James Robertson, read the full article]

With four times the content of our last book, What every intranet team should know, this is the definitive textbook for intranet teams planning to design or redesign their sites.

In 275 pages, this book walks through a practical user-centred approach to the design process, richly illustrating each step with full-colour screenshots from organisations across the globe.

We’ve already had some great feedback:

“I cannot recommend this book too highly, and it should be bought by every intranet manager. Even if you are not contemplating a re-design you probably will after reading the book.” Martin White

“In his most recent book Designing intranets James Robertson promises nothing less than ‘creating sites that work’. An over-promise? Not at all!” Lukas Karrer

“Highly recommended: even experienced intranet managers will find something new in this book.” Sam Marshall

Read more and obtain your copy

This generated some discussion and debate. Most recently, it has led Toby Ward to write some passionate posts about the length of the homepage. He started by stating that employees demand a clean home page, no scrolling, saying:

Your employees demand a clean, white home page, with absolutely no scrolling. This is a fact, supported by dozens of employee focus groups, at dozens of leading, and medium size organizations in North America.

Toby then followed this up with speed kills on roads; lack of speed kills the intranet, including:

The problem with designers, not all designers, but many of them, is that they’re trained in creative and web design. The intranet is not a website. Let me repeat: THE INTRANET IS NOT A WEBSITE! The same creative concepts for the web, and marketing driven websites, don’t always apply to the intranet.

Be warned, these are robust articles, stating strong opinions!

Intranets aren’t short of opinions, from staff, stakeholders, consultants and experts. As I discuss in eight intranet design mistakes, it’s important not to fall into the trap of “design by opinion”. I also commented at an intranet workshop yesterday:

There are plenty of statements made about design and usability. The simpler they are, the more likely they are to be wrong.

This includes classics like the “3-click rule”, and “7+/-2″. The “homepage should never scroll” falls into this trap.

Toby seems to have based his design decisions on what staff say they want. This is like asking people “do you want more or less crime”, and being surprised at the outcome. (Task-based usability testing wasn’t amongst Toby’s list of techniques.)

There is clearly a “traditional” approach to intranet homepages that squeezes everything into a single screen. This features news, with navigation at the top, quick links on the side, and a few tools. Considering how often staff complain they can’t find anything, we have to question whether this is the best approach.

Now don’t get me wrong, I’m not saying long homepages are definitively the right way to go. But I do want intranet teams to step back and to take a fresh look at how to design their sites.

What am I sure of is that it’s hard to deliver a truly useful homepage in just a single screen. There’s simply not enough space to provide more than basic information and navigation. So if we can design long homepages that are also usable, that opens up a new world of opportunities to deliver better sites.

So let’s get away from “right” and “wrong”. Let’s instead:

• Fully research staff needs, going beyond surveys and focus groups that only gather opinions.
• Take a robust user-centred approach to intranet design that includes techniques such as usability testing.
• Avoid opinions and assumptions wherever possible.
• Keep an open mind on the best design for each situation.
• Focus on delivering an intranet that works well for staff, and delivers concrete benefits for the organisation.

Intranet teams are already experimenting with new approaches, and I’ve featured a number of them in my upcoming book on intranet design. I look forward to further innovation, testing and refinement.

What are your thoughts on this topic?

With any redesign comes the opportunity for a fresh new look and feel. Drawing their inspiration from the best of public-facing sites, intranets are shrugging off their dated appearance and joining the modern age.

These design improvements matter. As discussed in the earlier article Should the intranet look sexy?, intranet sites don’t have a marketing role, but they do need to have a professional and engaging appearance.

Fundamentally, this is about trust. Staff need have confidence that the intranet will provide them with accurate and up-to-date information. An old, ugly and dated site sends the opposite message, that the intranet is uncared for and under-resourced.

There is an also an emotional element to intranet design. Intranets should reflect the cultures of the organisations they serve, and can also help to drive cultural change.

At a basic level, intranets need to have a clear brand and identity of their own, distinct from the public-facing site and providing continuity as the organisation evolves and restructures.

As intranets are hidden within organisations, it is hard to know what good intranet design looks like. This article shares a few examples from across the globe, not as definitive ‘right’ designs, but as inspiration for other teams to follow. While very different in their design approaches, all the showcased intranets have elements to learn from.

[July KM Column, read the full article]

The best approach for helping staff is to focus on tasks. These are the activities, simple or complex, that staff need to do on the intranet. The goal is to streamline and simplify how these tasks can be carried out.

Uncovering staff tasks

It is valuable to understand the full range of tasks, including common activities done by a wide range of staff, and important tasks that deliver business benefits to the organisation.

There are many ways of identifying these tasks:

• Interviews and focus groups. Discussions with staff, whether one-on-one or in a group, will naturally uncover information about key tasks. Staff will also express frustration with current bottlenecks, as well as highlighting their most important activities. Guide these discussions to ensure that sufficient information is gained about intranet-based tasks. (See the earlier article Conducting intranet needs analysis for more on this.)

[CM Briefing 2010-07, read the full article]

Within the intranet industry, the homepage also inflames passionate debate. This is particularly true on the question of how long the intranet homepage should be.

In the earlier article Seven roles of the intranet homepage, a range of purposes were identified:

1. news
2. navigation
3. key tools
4. key information
5. community and culture
6. internal marketing
7. collaboration

Effective designs find a productive balance between these seven roles, without any one being excessively dominant.

This turns out to be extremely difficult if the homepage is kept entirely ‘above the fold’, squeezed into a single screenful. Within this limited space, homepages often end up being mostly news with a little navigation squeezed into the edges. Internal marketing and a few key links round out the mix.

If the homepage is made longer, much more content and functionality can be included. This could increase the value of the page, and help to balance competing priorities.

But can it be made to work?

[May KM Column, read the full article]

Finally getting a stakeholder session with our HR guys and owners of ‘people’ related content on our intranet. Negotiations over the process and protocols have been as torturous as organising the Nixon/Frost debates, but I felt this was essential before we begin any part of the process. All is now agreed. Echoing James Robertson’s theme of putting ‘people at the centre’ our aim (if we get our way) is to avoid the hierarchy titles used by HR and focus on a ‘tab’ called ‘People.’ Part of my thinking behind this is the ability for us to incorporate other ‘people’ related content into this area, that is not owned by HR, providing a richer, broader experience for the user.

Intranet projects may confront challenges such as:

• unclear intranet ownership and governance
• tight timeframes
• limited (and often insufficient) budgets
• varied (and sometimes competing) stakeholder opinions
• large number of end users (staff), with widely varying needs
• technology considerations and constraints
• limited team experience and skills relating to intranets
• poor access to best practices and other intranets

Is it any wonder that intranet projects go off the rails? Even the most experienced and well-resourced teams can struggle under these circumstances.

It is useful to explore common mistakes made on intranet projects. These have been distilled from observations across many organisations, in both the public and private sectors.

The purpose of outlining these problems is to help teams avoid them, and to highlight good practices.

[February KM Column, read the full article]