Tag: product

Intranet iterations

We’ve been doing some more work on our intranet. Here’s a rundown of our latest release and some final thoughts on what I’ve learnt working on this product.

Why take a digital approach to an intranet?

I’ve said in previous posts that intranets can be the scorn of digital purists. “Why not just have a wiki and a blog – it’s totally free?” they cry. Well, maybe.

But as this is my last intranet sprint (sprintranet?) I wanted to make the case for taking a digital approach to this ever present departmental tool. I think there are 4 compelling reasons.

  1. Improved experience for users. The obvious one. Civil servants are users too, and saving them time and effort with products that work is better for them, and better for taxpayers.
  2. It’s a means of spreading digital culture and techniques widely across the department. Talking to lots of teams in the department about their intranet content or involving them in user research has enabled me to introduce principles of agile and user-centred design to lots of people who otherwise would never have encountered these techniques. A good thing in the wider scheme of digital transformation.
  3. Getting content design more widely understood. I’m increasingly convinced that content design training should join information security and unconscious bias as mandatory for policy civil servants. Until that happens, working with teams on their intranet content is a decent alternative.
  4. It’s a good training ground. A staff intranet is a reasonably low stakes environment, which makes it ideal for practising agile techniques, user testing and the like. Particularly as uses are on your door step. Four different fast streamers have now participated in running guerrilla testing or pop up labs in the department, and done brilliantly at it.

On to the highlights of our latest release. As ever, if anyone is interested in playing around with the intranet WordPress theme, it’s available on Github. All comments and thoughts welcomed.

Homepage

In our last intranet post we talked about the changes to the homepage design. The changes have attracted a lot of great comments. But more importantly our ongoing testing is showing users are completing popular tasks more easily.

Of course not everything is working perfectly, so we are continuing to tweak and improve. For instance we found users were not noticing when new content was being posted in the campaign box. So we introduced a ‘new’ banner to signal this event.

Screen shot of 'new' banner on intranet homepage

Information architecture

Our ongoing user research has repeatedly surfaced pain points for users navigating the site. Users did not always understand the main section headings, or what topics might be listed underneath.

To test further we ran several card sorting sessions to try and come up with better labels and a more intuitive architecture. Despite plenty of hard work, it turned out we couldn’t. Naming and sorting things into categories is just one of those timeless problems. We ended up agreeing that what we had was probably the least worst option.

To attack the problem from another angle we introduced some new functionality. We implemented the brilliantly named Accessible Mega Menu. This now provides a drop down of topics that appears underneath a section heading, to help users see what is available and help them answer their questions more quickly.

Screen shot of drop down menu on intranet homepage

Events

The department puts on a wide range of events.  By making use of theEventbrite API, our intranet administrators are able to create and manage events using all the functionality of Eventbrite. Once published, the event details are pulled automatically into the relevant intranet pages. Along with some design tweaks, we’ve made an already excellent events booking process even better.

Screen shot of events box on intranet events page

Our next sprint will be later in the year. Look out for further updates from a new product manager then.  And a final word of good luck and thanks to the brilliant team. My laptop will continue to wear our mission patch with pride.

This post was originally published on the Digital Health blog.

10 things policy can learn from product

Richmond House

Six months ago I made a career pivot from policy making to product management. The roles require a similar mix of empathy and politics, so I feel I’ve taken to it reasonably well. Alongside a deep understanding of Internet-enabled technologies, a notable difference is how much and how effectively product management makes use of specific tools and methodologies to solve problems.

So here are ten techniques I would bring into a policy team if I went back. If any of the terms don’t make sense, Ben Stevens from the Home Office has posted a handy glossary.

  1. Work in sprints. Choose a time period of 1 or 2 weeks to help give structure to the team’s work. Get everyone together at the start of the sprint and agree the things you are going to focus on completing in that time, remembering that new tasks will come in too. This is called sprint planning.
  2. Hold ‘stand-ups’ over the course of the sprint, and ‘retrospectives’, and ‘show and tells’ at the end of it. Don’t be spooked by the language. These are just meetings, so not exactly an alien concept to policy makers. There’s no need for me to repeat better guidance elsewhere on this, except to endorse how useful they are as an ensemble.
  3. Get a wall. Every team needs a wall. I managed a major house renovation last year and even had a wall (this is not a joke). At its simplest this is expressing a task on a Post-It note, fixing it to a nice flat surface that people can gather around, and moving the tasks through columns labelled ‘doing next’, ‘doing now’, and ‘done’. Do this, and then feel the energy and sense of achievement coursing through the team as they deposit card after card in the done column at each stand-up.
  4. Create genuinely multidisciplinary teams. I spent some time shadowing my mentor who works on NHS.UK Alpha a few weeks ago. It’s a full-blown agile team, replete with product manager, delivery manger, content writers, designers, and developers. Having such expertise around a table enabled them to do magical things, like designing the key features of a GP look-up service, in record time. My experience of policy is usually hierarchical group of something akin to project managers. Other experts tend to be in a box somewhere, wheeled out for special occasions. It also now seems amazing to me that design thinking in policy is still seen as the cutting edge while it’s de rigeur in digital.
  5. Make it someone’s explicit responsibility to knit the team. The mantra goes, “the unit of delivery is the team”, and commensurate effort is placed in getting that team working brilliantly together. My experience working in policy teams is that if they are working great, then great. But if they are not, the response is usually a shrug and sporadic suggestions for ‘more social events’. Digital methodology encourages constant communication between the team using stand-ups. It celebrates successes through show+tells, and does a thorough job of learning from failures through retrospectives. The result is a team completely aligned around an objective, with everyone feeling they are part of something important, and fantastic pace of delivery. Tasks fall to the team not individuals. This reduces risk of single point of failure.
  6. Separate responsibility for day-to-day delivery with big picture and vision. In digital there are overlapping and complementary roles called product manager and delivery manager. The former focusses on macro issues: vision, roadmap, stakeholder management. The other focusses on micro issues: unblocking the obstacles the team faces day-to-day, and doing the team coaching I describe above. This structure recognises something important about our minds being poor at doing two things at the same time. It’s very effective.
  7. Try out some new collaborative tools. Digital teams more naturally have their fingers on the pulse of internet-enabled tools to facilitate team communication, prioritisation, or collaboration. I know IT systems can create barriers to this; but in an age where everyone has a smart phone it’s not hard to find workarounds. If you had to pick any, for me it is Slack. There’s a bit of a backlash against Slack at the moment (Slacklash?), but frankly I’m still at the crest of the wave of appreciation that sees how much more efficient than email is at enabling team interaction.
  8. Prioritise properly. Product recognises you can’t do everything, so have a plethora of techniques for deciding what comes next. Do a few things well rather than lots of things mediocrely, and be rigorous in your approach to choosing which those things should be.
  9. Clap more. Digital teams religiously clap their teammate’s or others’ presentations. This is not only courteous, but sends the presenter away with those few extra endorphins that make it all seem worth it.
  10. Be agile. Note the small ‘a’. My simplest interpretation of this is understanding that for almost everything, your first answer could well be wrong. Doing something and then testing it is better than trying to get it perfect first time. As long as it is labelled as such, it is fine to say something is a prototype or early version and will be iterated, improved, or even binned.

None of these suggestions are especially complicated. But they can be tough to implement in teams unfamiliar with the language and culture. Digital teams should help with this where they can, as forming good habits should not solely be the preserve of digital. They should be for everyone.

I’d be delighted to give my novice advice to any policy makers, so do get in touch if it would help. Hat tips to Lisa, Matt, and Kylie for product coaching, andBenji for delivery management advice.

 

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.