We recently worked with the Department of Health and Social Care (DHSC) to redesign their intranet homepage to make it work better for users across the department – around 3,000 people per month – and to increase flexibility for the admin users of the site. It launched last week.
We worked with the team at DHSC over the course of 2 sprints to iterate and develop the new homepage. We learnt a few things along the way, which I thought it would be useful to share.
Something I have to remind myself on a weekly, if not daily, basis when working in delivery, is that things change.
During our first sprint planning session with the department, we had some ideas about the changes we could make to improve the overall functionality of the intranet and how we could use previous learnings to help us decide what to do.
We focused our attention initially on the existing research outputs produced by digital design and technology agency, Studio 24. Over the course of our 4 weeks together, we weren’t afraid to reprioritise based on what we were discovering whilst working through our backlog and added in new stories to reflect what was important for users.
We had originally decided on a confined piece of work for our second sprint. However, we quickly realised this wouldn’t be possible just yet and moved on to how we could use our time together to increase functionality and conduct further user research.
Communication is key
When multiple organisations work together on short pieces of work, it can be challenging to create a ‘one team’ environment that works for everyone involved. You need to be able to adapt at pace and think in a team mindset.
At the end of our first sprint, and having been working together as a team for 2 weeks, we held a retrospective to talk about what had gone well and what we could have done better.
We had laid a good foundation for how we would work as a team over the course of our first 2 weeks, but there were areas we wanted to improve on as a collective, so we could ensure continuous delivery.
We came up with some actions following the retrospective – these were to deploy to production more often and ask more questions so that we could make decisions faster. This enabled us to deliver more frequently, but still maintain a high quality of work.
Another action from our retrospective was to start conducting usability testing to ensure we were still meeting users’ needs.
Testing with users validates our assumptions
Drawing from your own experiences to make assumptions about a service is something we all do, but we know the services we work on need to be more diverse than that.
We conducted usability testing sessions during our second sprint to validate our assumptions around the new functionalities of the homepage and ensure users remained at the heart of the updated service.
We found that users thought the new homepage was clear and current. We had made the right decisions based on analytics about which services users needed access to the most. We also learned about how DHSC users of the site would like to be notified about new information that is important to them, and their wider teams, to ensure business continuity.
Deploying little and often helps people use better services faster
We spent some time thinking about at what stage of a sprint we should deploy new features to a live site.
A lot of effort goes into creating a new service, as well as testing it to ensure the service is up to standard. Occasionally, products are shipped publicly while they’re still in beta. It’s good practice to do this when a service already exists and is actively engaged with by users.
By pushing the new functionalities straight to the live site, users can experience these changes as early as possible. We advocate pushing new functions to live as they become available so users have a better experience of the service sooner rather than later.
We’re looking forward to working with our DHSC colleagues in future to make further improvements to their intranet.