One of my favourite metrics when measuring improvement on the intranet is the number of calls to the helpdesk. It’s a sure sign of success when you’ve done a few changes to an area of the intranet and the number of helpdesk calls goes down.
Conversely, you know that something is wrong when the number of helpdesk calls goes up.
We were recently approached by our IT department to talk about creating a system status page on the intranet with the goal of reducing calls to the helpdesk due to people being unaware that the problem has already been reported.
When you call our helpdesk, there is often a recorded message before you get through to the lovely list of numbers that you need to press to actually talk to somebody. The recorded message is there to let you know that some problems have already been reported and not to bother reporting them again.
So I was pleased to see this move to help users by moving the recorded announcements to an intranet page. I did my usual research to get a background feel of the situation and it turns out there are about 230 applications that would be included in the mix. I also noted that on an average day there are about 3 to 5 applications down out of the 230.
I have to work with developers within the digital team to create a solution for getting these status updates onto the intranet. So I’m listening to the needs of the IT department who will have to manually publish updates, thinking about the intranet and system users and also thinking how we are going to implement this using our flat publishing intranet CMS.
The IT team had already done some of their own designs as to how they thought this should work on the intranet. The designs looked like a flight control room with a whole page of categorised boxes containing red and green dots and a big banner with our IT helpdesk provider’s logo at the top. No navigation, no intranet template and presumable 230 of the apps somehow appearing all at once on the page.
So I started again and came up with some fleshed out wireframes, fitting into the intranet navigation structure and design style, showing just a list of current problems in the body content section of the template. No red or green dots, just a list of what is down today. Clicking an application would expand to show the detailed problem information.
But this didn’t go down well with IT. They wanted to demonstrate how well they were doing by showing all the green dots too. My mockup showed just 5 systems down. Simple and usable. They wanted to make users go through a list of 230 items to find which systems are up or down.
So I ask myself. Will I really go and check an intranet page before using an application? The list of 230 apps includes email, intranet and all the things I use daily. It also includes some of the bigger systems such as our HR self-service application which fortunately I rarely have to use.
Do I need to know which systems are working? Will I check the system status intranet page before trying to access a system? Before I try to use my email? It’s not like the tube where if I check to see that a line is up and running then I know not to make other plans for travelling. And even when they say that there is a good service on all lines, I don’t believe them or I know that it doesn’t stop something going wrong between now and when I get to the station or halfway through my journey. But at work I’m sat at my desk with a computer. If I want to use an application on my desktop I’ll go ahead and try to use it. I won’t go to a page on the intranet just to check that it is working first. But that’s just me. The IT team came up with a use case that people needed to check system status beforehand because some systems were slow to boot up and login to. Really? Ever thought of making your systems work better? Again and again I see this patch-up mentality where rather than fixing a problem people try to compensate by uploading videos or complex pages of explanations.
IT systems are one of those service functions that people shouldn’t have to jump with joy about when they actually work. People only notice when something goes wrong. Like so much of my usability work, the success is measured by how much people don’t notice the technology or the application and can just complete the task in hand that enables them to get on with their job.
So the latest state of play is that they now want to display just 30 of the top applications using red, amber and green traffic lights. I argue that this just complicates things further because now even if I do bother to go to the page to check if my system is up, what if it’s not one of the top 30 and doesn’t appear on the list. Is my system up or down? I don’t know, so I’m going to call the helpdesk. Aside from the obvious accessibility issues with using traffic light colours to portray meaning, what does amber mean? The application that I want to use only half works?
I’m really interested to hear how others feel about this. Is there a case for exception-reporting and only showing what doesn’t work. Are there examples of traffic light systems working and do staff really go and check something works before using it or only after trying to use it?
I’m also feeling the self-promotion and vanity publishing issue again on the intranet. As the culture is changing in my workplace and I see more and more staff feeling that they have to justify their existence by claiming credit for every bit of work they can and promoting what they do, we are getting more and more requests for vanity-waffle pages on the intranet, spouting “what we do” verbiage but which contain no task-related or usable content. There is a threat on the intranet with a move from “how can I serve the users” to “how can I protect and promote myself and my department.” And the trouble is that this mindset is coming down from up above for the same reasons.
As with what is happening with central government websites, it’s not important that I know what department to go to in order to complete a task on the intranet. I just want to get the task done. And while I recognise that staff do need to know the greater structure and goals of the organisation, which we do include on the intranet, we don’t need to know the ins and outs of each and every one of the teams and departments which change, rename and transform so often that you couldn’t keep up with them if you tried. And if they had anything important to offer staff it would already be in the guidance section of the intranet.
It will be interesting to follow how this issue pans out. But I guess that the ultimate test is whether those helpdesk calls go down and whether staff give us good feedback.