In my mind, the biggest difference between testing an intranet and a public website are the users. You know exactly who will be using the intranet, because they have to. The roles and tasks are predefined.

What I'm not sure of is the appropriate sample size and where it should come from. On one hand it makes sense to test an intranet with people that have never seen it, fresh hires for example. On the other hand however, the people who have been using it for years are equally if not more important.

Would it be ideal to test using a few people from each department or role, plus a few new users? Are actual users better or worse to test with than representative users?

3 Answers 3


There is absolutely no difference in usability testing an intranet site from a public web site. The questions are the same and the conventions are exactly the same on public web sites and intranet. The big difference is the target audience, which on an intranet are this group of people, instead of 30 year old males or women wanting to buy red shoes. The target audience is this company and these are your users.

That’s great news, since you will have the ability to test your intranet on the actual users who will work with the application. Task completions work the same way, and there are (probably) web applications, such as a word processor and a calculation program to address as well.

I think your idea is well thought through. Having different users from different departments is essential. A school teacher have different needs than an accountant or a news editor. Having as different roles from different departments makes perfect sense.

But when you design an intranet, don’t let the “out-of-the-box” design fool you. The SharePoint 2010 breadcrumb icon is really bad (a folder). Use a standard breadcrumb and you’ll do just fine.

enter image description here


Usually I agree with Benny, but this time I don't. Knowing your users personally makes a fundamental difference. Of course, you have all the tools you have for public websites (logs, etc), and you have to use most of them. But the most important is:

W A T C H   Y O U R   U S E R S

Watch them while they're working with the system. Watch newbies as they get stuck. Watch seniors as they look into their notes (most of them maintain a "personal user manual" for rarely used features). Ask for these notes.

If asked, tell them that you're not interested in whether they're lazy and watch Facebook, and won't tell anyone, you are their friend. Your sole job is to make their daily life as pleasant as possible, and all you doing is trying to understand what is their daily life exactly.

Make the prototypes run on their own machines, at their own desks. This way the tools are in their environment, the final environment.

Make users an integral part of the process. Be less formal towards them while still maintaining the formal quality testing documents.

For prototypes, show it in the kitchen (if it's on paper or a mobile app), ask for their opinion.

My desk was near to the entrance. So whenever I wanted to show a prototype, I only had to wait for noon, and ask people that when they come back, step by, I want to show them something.

Nothing formal required. Of course, I was still filling the usual formal forms, but I tried to make the conversation as informal as possible.

The keyword is co-design.

I still maintain, that internal UX is the real UX, as that's where you actually know enough about the users to actually design an experience.

  • I agree with everything that was said here, but the question was about usability testing--not general user research. Informal feedback and diary studies are great, but there is still a place for a thorough usability test to uncover deep issues.
    – Andrew
    Dec 17, 2012 at 15:24
  • @Andrew: I don't agree in general that formal usability testing in formal environments brings better results. I do agree that formal methods are important, as a checklist on what should be looked for. Yet I also believe a formal setting has a research bias: you have to watch your users in an as informal environment as possible. Early stress tests with blood pressure/pulse meters were unreliable, as it made people uncomfortable. So I opt for a more informal, friendly "interface" towards the user when doing the testing, rather than making sure everything is lab-clean - reality isn't.
    – Aadaam
    Dec 17, 2012 at 19:26
  • The question was about "best way to approach intranet usability testing" and my answer was that the best approach is an informal approach in this case. This is an opinion, based on personal experience and professional agreement, shared between the users I've worked with, the client of that particular project, and some UXers I've spoken about the issue and had similar projects already - it's not a fact however, you're correct
    – Aadaam
    Dec 17, 2012 at 19:40
  • This is just a matter of semantics. To me, and many seasoned UX professionals, "usability testing" only refers to the specific method with a test protocol and tasks. "Informal usability testing" does not mean you show the prototype in the kitchen and ask for feedback; instead, it is when the moderator is allowed to prompt and go off-script. I do think informal feedback is very important in this scenario, but it isn't usability testing.
    – Andrew
    Dec 18, 2012 at 14:55

In my experience, the best way to build out an intranet is to start simple. Start with the #1 thing your employees need.

  • If it's an open forum or social newsfeed, start there.
  • If it's help finding all those pesky forms, start there.
  • If it's a listing of all your employees emails and phone #s, start there.
  • You get it... the list goes on...

Once you've 1000% nailed that, and it's working well, and growing... move onto the #2 thing your employees need. No sooner. This will keep you focused, and help your user base become familiar with your new service as it grows.

There's nothing worse than dropping a new intranet on your company and hearing the wails down the hall as people are confused, 'where did everything go?!' Don't replace your old one, build a new one that is better and people want to go to.

I've published a slideshare on how to stay connected with your users as well as a hands-on strategy for user-based design you can start applying today.

And if you want one great book to inspire your thinking on how to build a modern intranet, it's Dave Gray's 'The Connected Company.'

I hope that helps!

The Featuritis Curve: User Happiness as compared to Number of Features

  • Your answer didn't address testing at all, which is all my question was about. Nice graph though :)
    – bernk
    Oct 3, 2012 at 14:04
  • If you looked at the documents I referenced, the whole focus is on understanding your users to make the best choices on development. I assume that's what you mean by 'testing.' Aadaam, who also answered, is on the same page. If all you want to do is have people click on buttons you built, and make sure they worked, then you are asking your users to do the wrong thing. That's the job of the development team, to validate their developed features work. The hard part of 'testing' is knowing what to build in the first place...
    – ATSiem
    Oct 4, 2012 at 15:02
  • These are not my users, nor am I building or designing anything. In fact, I don't even work at the company where the intranet is being used. I work as an Interaction Designer for an agency that has been hired to help this software company improve their intranet. My job is to evaluate the current intranet, find problems, and present suggestions of how to fix those problems. To do this I plan on conducting usability tests with participants who actually use the intranet on a daily basis, as well as evaluate the intranet against some heuristics.
    – bernk
    Oct 4, 2012 at 18:15
  • …I'm not sure me doing an expert review would have any real value since I'm not an expert in their intranet or what they use it for. I could for sure identify a couple of obvious errors, but I guess those will come to light in the other two methods I'm planning on using.
    – bernk
    Oct 4, 2012 at 18:17
  • 1
    If all your are doing is user sensing and reporting on the problems, I would say 5 people is too small. I did a redesign for an intranet once, which also included 10 weeks of concurrent development. We interviewed 40 people over that time period - a few for eack weekly each iteration. And yes, having many diverse people is great, but also having three of one specific user type helps you confirm which issues are biggest for who. Hope that helps! Good luck!
    – ATSiem
    Oct 5, 2012 at 19:36

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.