I have been asked to offer advice for the development of an intranet for a large international company.

The client will be developing the intranet in Sharepoint and is keen to use a user-centric approach for its development and I have been asked a question:

"how do approaches for UX differ between intranets and normal websites"

I'm finding this quite hard to answer succinctly because its complex and nuanced. By and large the procedure will be much the same insofar as one must carry out substantive user research and develop iteratively, but I'm still having trouble with any specific differences of approach between ux of intranet vs website.

Have you developed for intranet? what were your experiences and how did they differ from developing for normal websites?

caveat: this is a general question that I have been asked lacking any real specifics

  • 2
    snarky but mostly true comment: the main difference is that intranets are usually burdened by having utterly horrific enterprise systems that run it (SharePoint, Lotus, a plethora of custom hobbled-together internally built IE6-only monstrosities, etc.)
    – DA01
    Oct 27, 2011 at 19:15
  • I ran a Lotus Notes intranet back in the 1990s - and thought it was pretty good - for MANAGING Corporate Information - which is what it was orginally designed for. What it was less good at (at the time) was doubling up as an email system and web platform.
    – PhillipW
    Oct 28, 2011 at 12:27
  • Wouldn't the difference really be between a closed set of users and an open set. In the closed set there may be standards and norms that they follow and which you could use that you shouldn't in an open set.
    – JohnGB
    Oct 28, 2011 at 13:55

6 Answers 6


They can be quite different. Off the top of my head:

  • Intranet users can use certain information elements a lot - and will want to be able to 'sort' the interface so they can quickly get at the bits they use regularly

  • Intranets can be vast & also dumping grounds for data which people will add - but then never get around to removing when its out of date. So they need a 'data review' process.

  • You also need to make sure that visually users can identify that they are using the internal network and not get it muddled up with what non-company users can see.

  • An intranet also needs to be really easy for users to add data to (in a consistent and searchable fashion) - otherwise they'll fling information around by email / stick it on shared drives or in the worst situation, go off and try to buy other bits of software or sign up for services they've found on the internet.


In my experience in larger organizations, the absolute ideal user interface for your intranet would be this:

          What are you looking for?

          [search term            ] GO >>

The reasons for this are many:

  • most intranet use is hunting for one bit of information and then getting out
  • intranets tend to be highly fragmented spaces and departments and teams start staking out their own corners of it (even intranets with all the right intentions of being centrally managed devolve into this mess)
  • intranets tend to be a huge mishmash of platforms (sharepoint, someone's frontpage creation, all sorts of internal custom tools, file repositories, data warehouses, etc.) as well as file formats (HTML, DOC, XLS, PPT [ugh], VISIO, MS Project, etc. etc.)

I'd invest as much time and money as possible into finding or building an search engine that can handle all these variables and make things findable.

  • There are a number of 'corporate search' software products already available from companies such as Autonomy.
    – PhillipW
    Oct 28, 2011 at 11:17
  • Definitely. Autonomy seems to have a good technology...though personal experience with their system from a UX perspective some 10 years ago was a bit frightening. I despise SharePoint, however, perhaps a bit ironically, I do recommend Microsoft Office SharePoint Search Server, which is free and rather powerful for the price. Of course, probably the ideal option is the Google Search Appliance.
    – DA01
    Oct 28, 2011 at 14:33

I've been amazed to find that most of my intranet users are practically unaware that they're on a website or perhaps what that really means. My sample is of entirely non-technical users, unsurprisingly. In our case they accessed the application exclusively via a desktop icon we installed for them, so in a way it did function very much like a program.

As a result of this people start to believe the browser is a part of your interface; amusingly enough after installing Firefox on a client machine someone mentioned they were having trouble with this "Firefox thing (I) made".

I had one user not realize they had to type their password on a new machine because their browser always did it for them, he actually insisted that he didn't have to and was frustrated until I manually walked him through the process. Note what features your users use in the browser vs in the application. I personally decided to place print buttons inside the application because users were using the Internet Explorer print button, and did not know they could use ctrl+P to print. Once they started using Firefox several believed it was no longer possible to print because the button wasn't there! Asking "don't you use Ctrl+P" got blank stares.

In an Intranet application you're probably dealing with a very limited set of technologies and skillsets related to the World Wide Web; unfortunately the technology in intranet environments is often outdated and updates may even be disabled. As such most of our users were using Internet Explorer 7 and 8. IE7 has caused significant issues, and being aware of this has helped us
A: know what to design for and
B: know the limitations of most users, and how to fix them (upgrade/change browser) when necessary

An interesting situation I've noticed is most users seem to think the intranet app is something specific for them. Our company recently changed a major report format, and thus our Intranet app prints the report differently. One of the users didn't like it, and asked if "her" report would be changed back to the old format. I personally explained that it was a company format and that everyone was using it, there was no way for an individual change.

Users also have a heck of a time realizing what's a bug and what's intended if something's "always been that way". A user complained their comments were getting cut off, and wanted some indication telling her when she ran out of room; there was no comment limit nor had there ever been, it was simply a bug that had been in place for the lifetime of the system. As it was not reported it took three years to find and an hour to fix. You have to find out what your users are doing because they don't know what's wrong unless something changed. And if something did change, more often than not they think it's a bug unless you tell them.


One of the big UX differences is that a public website has to sell the company, because it is the public face of the organisation. This means that it is often bright, loads of images, it is a publicity tool.

And intranet is a tool for employees to use. You are not selling, so you don't need to focus so much on the look and style of the site in corporate terms. But people are liable to be using it far more, and required to use it, and so it needs to work well, cleanly and smoothly.

If you can control it, then make sure that the site works the same everywhere. Make sure things are easy to find and easy and obvious to use. Make sure that the fonts and background colours are relaxing on the eyes, but there is no need to have lots of images, flash videos, very cool interactions. This is not to say they are never needed - smooth interactions are good anywhere. In general, use nice and clean UI, not fanciness.


can I answer my own question?

• Pay special attention to the intranet homepage; it is essential to attracting users and communicating information

• We need to gain a detailed understanding of internal workflows and processes so that we can presenting standard intranet information, including policies, forms, and procedures, much more-so than a standard website. Detailed user narratives will have to be build that define personas and test cases for use later in the project.

• There must be effective communication through the intranet: news, print publications, and email

• One needs to consider rules for writing news items for the intranet and what news items are likely to be most useful to staff

• The intranet will present information about the organization, individuals, and teams; allow user to find people

• The intranet will allow staff to Discover what people do and where they report; will be an effective employee directory

• They need to consider what to include in employee profiles, how to present team and project information

• According to the available research Nielsen Norman Group Report Series Intranet Usability Guidelines intranet search is a widely used and incredibly important feature

• The intranet should structure data by task rather than department

• The intranet must manage content and support users in multiple locations and using multiple languages.

• How will they manage the intranet? There must be content management roles, forms and processes which in turns means educating, managing, coordinating and training content contributors.

• Templates and standards will create a consistent experience


An intranet is technically the same thing as a website, and there is no real reason for the user experience to be different. The differences you see between public and internal sites are largely due to the development process and teams involved rather than any conscious UX decision.

Internal apps can be greatly improved by using the techniques that are now common in public web apps, so if you really have the authority to build an intranet based on what the users care about, handle it the same way you would any web project.

Of course, "User centric" could just mean building an internal version of facebook that nobody will use - there's not much you can do to improve that situation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.