An agile intranet

DH intranet homepage screenshot

We designed our intranet to be continuously improved, and over recent weeks have been doing just that. Since the intranet’s launch last year we have gathered data and done extensive research to deepen our insights into our users’ behaviour. This is enabling us to flex our product to meet our users’ changing needs – in line with digital best practice.

In our most recent development sprint, we focussed on the homepage. The intranet homepage is the first thing most people in the department see when they log on in the morning, so it’s not surprising that 99.9% of user journeys begin there. That’s not true of all websites – GOV.UK pages are often reached via a search engine – but our default makes the homepage a prime piece of digital real estate. It deserves excellent design and only the most important content or features.

From looking at site traffic we could see the content users visited most over the past year. For instance: guidance on performance management, expenses claims, booking video conferencing, and a few specific  forms. Over the last month or so, content about the DH2020 change programme has also been very popular.

This data informed our qualitative research. We interviewed twenty-one individuals, asking them about their use of the intranet. We also observed them using the homepage to try and perform particular tasks. As well as interviews, we ran card sorting exercises and a co-design workshop where users drew sketches of their ideal homepages, or voted on features they liked from other government intranets. The range of ideas generated ranged from the pragmatic to the extravagant. But the discussion was invaluable in helping our suppliers understand the needs of DH staff. Over two weeks our experts translated those insights into some of the changes you can now see:

  • Bringing in common design patterns by integrating the menu, search and login into the header to help users find them
  • Developing prominent areas for links to popular services and pages; these are customisable by our content team so can change as needs change
  • Introducing a campaign box to highlight the most important ‘need-to-know’ information of the moment
  • Increasing the number of news stories further down the page; as the large number of users felt the stories dropped off the homepage too quickly
  • Retaining a clean design that users responded to well, but binning the bits that users did not need or want anymore

Communicating via Slack across several UK locations, the team deployed the changes early last Tuesday morning. Thanks to the brilliant work of the developers we encountered almost no bugs, and by the time we got into the office some fantastic feedback had started to come in.

Launching is the start of a process, not the end. We’re moving straight into more user testing, including those using assistive technologies, to ensure our changes are performing as we want.

An ‘agile intranet’ is something the department should be proud of. Internal services and tools are rarely built in this way. It has only been possible for us to effect improvements to this product quickly, cheaply, and securely thanks to our predecessors. They left us a site built on open source software, to open standards, with no contract lock-in, and with the precedent set for relentless focus on user needs. Long may that continue.

Originally posted to Digital Health Blog.

How to do user research on a shoestring

User research is the bedrock of digital transformation, and without it we have no hope of developing great products and services. Ideally your team has a dedicated user researcher, you can access laboratory facilities when you want, and you have a whole range of tools and techniques at your disposal. When the Department of Health first redeveloped its intranet last year, the new site was built on extensive user research.

We are now undertaking further development to ensure the intranet continuously improves, but are more resource constrained than for last year’s overhaul. Over the last couple of weeks I have discovered that lack of budget needn’t be a blocker. Using so-called guerilla techniques, you can get invaluable insights on a shoestring budget.

We have been thinking about how to meet our primary goal for the intranet, that users can find everything they need and access the services they want. Unpacking this requires us to understand: what the most popular information or services are, how easy they are to find, and whether the content meets the specific need. Following a recommendation from a developer on our project I’ve been reading Undercover UX, a guide to user experience design on a budget. That, along with expert advice and help from the team, gave us enough to get started.

  1. Brainstorm. First we sat down as a team to write out as many needs as we could think of, thinking as broadly as possible. This exercise needn’t take long, and required no more than sticky notes, pens and a wall. As employees of the department, the team are all users too.
  2. Validate and prioritise. Next we cross-referenced our hypothesised needs against search data and site traffic. Some interesting patterns were revealed, for instance the way the term ‘hospitality’ drops out of search data as spending controls were brought in, or that many users use in-site search to try and find BBC News. Some of the needs were sufficiently well-understood to be specific, like finding the wifi password for the building, while others were vague and will require more work. For instance searches for ‘performance management’ are very frequent but do not reveal precisely what information is sought. You can view our list of around twenty top needs here. I’d be a little surprised if they were radically different to every other intranet in the world, but if you disagree let me know.
  3. Set up a “pop-up” user research lab. We then conducted a series of 1-1 interviews with users, while an observer took notes. To set up the lab, we found a space in the office, developed a script around a few key tasks that we wanted to observe the users performing, and recorded the sessions using Quicktime screen record which is installed as standard on a Mac. It’s the first time I’ve done this, and watching a user try to complete a task only to hear them exclaim of a page “I just have no idea what this is telling me” is both chastening and highly motivating.

Over the course of a morning we got conclusive evidence on content that was or wasn’t meeting needs, as well as insights into users’ search and navigation habits.

I realise the process described above is not perfect, but it is important not to let the perfect be the enemy of the good. When users are on your doorstep, there really is no excuse not to understand their needs.

Originally published on the Department of Health digital team’s blog.