System status and vanity intranet pages

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.

Intranet redesign, Phase 4: visual design, HTML and CMS build

News delivery design

With several stakeholders interested in news delivery across the intranet, this was an important part of the redesign.

In the existing intranet, a news story would appear on the homepage with a URL from the latest news section and then drop into an archive, with a different URL. So the same story had 2 different URLs in its lifetime travelling from homepage to archive. A nightmare for analytics and evaluation and back-linking. The news archive itself was just a bulleted list of text headlines, grouped by month, buried in a structure that was difficult to navigate and, to my mind, did not encourage anyone to browse through back-issues.

I wanted to turn this on its head and bring the news stories alive. I wanted stories to link to each other forming a thread. I wanted to eliminate the idea of an *archive* which reeks of a dark, locked away place, underground, filled with cobwebs. I saw news being displayed as a stream of thumbnails. And wouldn’t it be nice if staff could *Like* stories?
News

Devolved news publishing

Also on the cards was a plan to devolve news story publishing to the internal editorial team. Up until this point, the central intranet team handled all intranet content, coding up and publishing manually in Dreamweaver. To get the news stories flowing through the new intranet via the editorial team, we needed a CMS (content management system). And because news would appear on the intranet homepage, it meant that the CMS would have to publish the intranet homepage. Scary, because we’d always had manual control of the homepage.

Technical development starts

Armed with my wireframes and a visual design prototype (built with Fireworks – great for WEB graphics) it was time for the core team to come together ready for the build. Up until this point I had been working very closely with the intranet development manager. Nobody had seen any visual design work or prototypes. This was the point when I presented all my findings to the team and we got our heads together working on the interface.

We had two developers who would build the HTML and CSS template for all sections of the intranet. Then two CMS developers to take the template and build the homepage and news delivery system within the CMS. And I stress again, we were working with a webserver that just supported flat HTML and Javascript on IE6+ browsers.

Team meetings were more scrum than SCRUM and I was probably seen as a tiresome pain in the neck during development. Constantly tweeking parts of the interface. Trying to defend usability design choices. Causing hell for the CMS developers whose inbuilt navigation system would not bend to my contextual designs and pushing them to the limits of programming creativity. Trying to turn their mindsets to new ways of thinking. I still remember roaring at the team during the news section development “THERE IS NO ARCHIVE!” and fighting for pixelspace on the width of the search box. Such is the life of the user experience designer.

Compromises, battles won and lost, we came up with the following main design elements.

Page layout, consistent design & colour coding

We decided that the header bar should stay the same throughout the intranet. This contained the logo, strapline and search box (including people search). Plus a global navigation bar containing the top-tasks and A-Z lookup pages. I was quietly pleased that it would leave no possibility of having any spam banner ads forced upon us from overly keen stakeholders.

Homepage main menu. Simples!
Homepage main menu. Simples!

The left-hand menu on the homepage displayed the top 4 sections.

I added an A-Z box to the homepage to give quick access to any letter plus a scrollable billboard space for internal advertising. The billboard gave the user 10 seconds to do what they came to do from the homepage and then started slowly scrolling the adverts for those who hung around. We managed to get RSS feeds from our public site and the BBC into the homepage and the only bit of personalisation on the intranet; a graphical bookmark link back to a choice of local intranets (implemented with cookies).

We changed the default typeface, increased the font size and line-spacing and improved text flow on the page. We used a three-column approach, left-hand menu, body content, right-hand for document downloads, related pages and external sites, adverts and contact information.

News stories

On individual news story pages the developers came up trumps allowing us to display popup images, scrolling photo galleries and video. A big plus for engagement. And we managed to get voting on stories into the mix through a convoluted use of jQuery, cookies and Google Analytics to store the votes. We added *next* and *prev* on each story to encourage paging back and forth between stories. Back issues were still organised by month but we now had a visual display of stories using thumbnails. And there was no mention of archive 🙂

User-centric dates

Instead of using a typical datestamp on the footer of each page, I took the decision to move to user-centric dates in the style of Facebook. Yes I did sit and watch in wonder as a freshly published page changed its status on the footer bar in real-time from Published just now, to a few minutes ago to 10 minutes ago. Much more human to see, than to read a date and have to remember what day it is now and work out how long ago it was. Little shortcuts in the brain’s workings help the user experience.

Working interface

Here are some example thumbnail images of each section template, showing the homepage, a help page and then each section landing page paired with a themed detail page. Not counting news & features, each section landing page acted as a partial sitemap giving quick access to popular content within sub-sections.

MoJ intranet colours

Accessibility testing

It was at this stage when the first drafts of the site had been built that I tested the intranet template on staff using assistive technology. I sat with people using JAWS and SuperNova screenreaders and Dragon voice recognition. Always a good experience watching (and hearing) the intranet being used from this side of the fence. And great when all the hidden code in the back of the pages works. However, I sat with one blind lady and I was pretty gob-smacked to find out that she was not aware of access keys and how to jump around the site. She’d been relying on her own method of jumping to the H1 tag on a page but was unaware of all the other shortcuts. It was also interesting to sit with another lady using a headset to easily browse the intranet through spoken commands.

After building the templates and CMS system we were then ready to haul over the content, which I’ll cover in my next post.

In this series

  1. Research, surveys and brief
  2. Information architecture and content audit
  3. Wireframe designs and user testing
  4. Visual design, HTML and CMS build
  5. Migration, content freeze/dual publishing
  6. Communications, launch and evaluation

Mentioned sites