Month: November 2015

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.

Continually improving our intranet

No digital product is ever perfect or finished. Even a site that is 90% cheaper than its predecessor, and boasts a user satisfaction reaching post-launch heights of 80%. My challenge as the new product manager for the Department of Health’s intranet is to build on that daunting baseline, and carry on the great work of my predecessor, Kylie Mulholland. Revisiting the lessons learned from the intranet’s first development seemed a good place to start.

Over the summer we ran a discovery phase to understand how people were responding to the new site. We found that overall, users much preferred the new product to what came before. However, they would still like to find things more easily through either search or navigation, particularly the things that help them do their job. These findings were borne out by analytics data: video conferencing arrangements consistently appear among the site’s top search queries. The discovery also revealed unmet needs on the editorial side, where content owners and editors wanted a more streamlined publication process.

Last week we brought together  a multidisciplinary agile team to begin a new period of development. We work in several organisations and multiple locations; Whitehall, Old Street, and as far as Atlanta, Georgia, so online tools like Slack, Basecamp, and Talky are helping to keep us connected with each other and our users.

Stubborn on vision; flexible on details

Our first step was to draft a set of high level goals for this phase of development, which support our overall vision of making the DH intranet the best in government. As ever, we welcome feedback.

  1. Users can find everything they need and access the services they want
  2. The intranet is accurate and trusted
  3. The intranet is easy and quick to update
  4. The intranet encourages user engagement
  5. The intranet meets the Digital by Default Service Standard

Borrowing a method from the Government Digital Service, we then built a prototype roadmap. This exercise forced us to think about what we would have to learn or prove if we wanted to achieve our goals. For instance, to show that “users can find everything they need”, we need to first find out what users are looking for, and then show, using data, that our improvements actually do help users find those things more easily.

We also identified and prioritised the big themes emerging from the discovery and mapped them against a rough timeline of development sprints. These included search and navigation, events, content management, and sign-in.

Finally, we used the roadmap to map out: our users, the wider ‘system of systems’ that support the intranet, our most important stakeholders, our assumptions, and any dependencies. This helped surface challenging questions early on. Our prototype roadmap is on display in Richmond House and will help us communicate to stakeholders what we are doing, why, and broadly when.

Our first sprint

Before we get going on new features, the team are first reviewing and cleaning the code base, fixing bugs along the way, and by the end of the week we’ll have it back in GitHub.  Making things open makes them better and from next week any organisation can take our code and ideas and start to build their own intranet sites, according to their own users’ needs.

I’ve learned a lot in my first weeks in product management. It has not taken long to experience the tension between user needs (what evidence suggests end users of the product want to see) and business needs (what other stakeholders would like their users to see). This forces you to ask some pretty fundamental and philosophical questions about the real purpose of the ‘thing’. I’ve also learnt that getting the right policy, process, and governance around the product may be at least as important as the product itself. Finally, I’ve sensed that many digital folk think that intranets are the devil’s work! It’s our job to prove them wrong.

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