Some testing is better than none
Ideally, all intranet design projects should adopt a design approach which consults with users throughout the process, from identifying needs to input and evaluation of structure and design.
This is not always possible. Time and cost limitations occasionally result in corners being cut with testing often being the victim, because it is thought to take too long, or because the project team believe their experience enables them to create a design without testing.
But without input from the target audience, it’s likely the site will lose some users. Squeezing in some basic testing can make the difference between success and failure.
Why engage users early?
Ideally, users are engaged early in the development to ensure:
- user needs are met rather than what the project team thinks they need
- the time and cost of reworking an already designed site is minimised
- the site is both useful and usable
Is it too late to test?
In the absence of full testing, getting users involved even in a limited amount of testing can highlight issues prior to launch.
Intranet staff can conduct short tests of under 20 minutes. Catch people at their desks, in the lunch line or take them out for a morning coffee.
Who to test with
Start the process by identifying the main audience for the content. Think about who ‘should’ be using the site or application and what tasks they will be performing while there. Commonly the answer is ‘all staff’ or ‘everyone’. However, in reality, this is rarely the case.
Once the target audience is established, think about recruiting users to test with.
What to test
Use scenarios to focus on key tasks users are performing. A scenario is a short story describing a task that staff attempt on the site. It may be something that staff undertake frequently or something more involved.
- Mark is going on leave. Find someone in personnel to speak to about leave entitlements.
- Nicole is travelling interstate for a conference. Find information on booking travel, cab charge vouchers, hotels and meal allowances.
Scenarios need to be realistic and represent core tasks that users undertake. Without a good understanding of what staff need to do on the site, the team cannot deliver what users need. In this case, user and stakeholder interviews should be conducted.
How to test
Using either paper mock-ups of the design or the built site, run through 10-20 scenarios with each user, noting the behaviours. Look for repeated behaviour — if a problem occurs for one user it may not be worth following up, but if 3 or 4 users have the same problem, it is worth investigating further.
It is a good idea to note down the path taken by the user, especially when it is not the ‘correct’ path.
What to do with the results
The most important step in this whole process is identifying the issues, evaluating the risk prior to launch and where possible fixing the problem.
Any changes should be evaluated before release, as they could have an unexpected effect on other parts of the intranet or may make the existing problem worse.
Ideally, you would test changes using the scenario method previously explained.
The process outlined above does not replace proper testing but is better than doing nothing. It will identify the surprises before launch rather than later when the ramifications could be worse.