Co-designing the Shifts website

This week, we made the Shifts website available to all Food store colleagues.

The website means colleagues now have far more visibility over their work schedules and their days off. They can access Shifts from their personal devices too so they don’t have to be in work to look at their rota.

This is a big deal. It’s empowering. It’s a game-changer.

In September 2017, we started testing the Shifts site with colleagues from 10 stores. By November, 600 people across 120 stores were using it. That quick uptake was a sign we were getting things right. We hadn’t asked more people to test it – colleagues had shared the site with neighbouring stores because they saw value in the product we’d designed.

Experts. Lots of them

Experts from several areas came together, bringing their knowledge and expertise. Shifts was designed and built by:

  • Food colleagues at HQ 
  • Food store colleagues (informed the design through their feedback and how they interacted with the product)
  • Co-op Digital
  • UsTwo (completed alpha phase)
  • Equal Experts (built the site)

Shifts’ success is down to collaboration

It’s not an accident that (so far) Shifts has been a success. It’s a superb example of co-design and collaboration. This post picks out examples of when working together, listening, and considering quantitative and qualitative research meant we designed a much better product.  

Listening to colleagues

Ustwo ran the Shifts alpha phase. The prototypes we tested with store colleagues confirmed our assumptions – we were on the right track to designing something useful. But, it was the time Ustwo spent with colleagues that was most valuable because it helped us find lots of features colleagues needed that we didn’t anticipate. We found that a very common user need was having the visibility to see who was scheduled to work on the same shift. Their research in context helped us get to grips with the more human side of colleagues’ needs.

Looking at data

We looked at data to make improvements too. For example, the data showed that the vast majority of colleagues didn’t look at their past schedules so we adjusted the site to just show the past 12 weeks rather than 52.

When we spoke to colleagues we found there was confusion about the laws around break times so we included a feature on the site that set this out clearly. We’d put this in a prominent position alongside colleagues’ shifts, but the data showed that it’s not something people used repeatedly – they checked it once, learnt the rules and had no need for it again. So, we put it on a separate webpage so colleagues could reference it when they needed to, rather than seeing it every time they log in.  

Learning from past experience

Shifts was always going to be behind a log-in so we looked to the ‘My HR’ app that also has one. To log into My HR, colleagues need their colleague number and a password that was sent to their personal email account. However, we knew that wasn’t working well because many colleagues don’t have a personal email address. Managers also said it’s time consuming to collect those details.

We wanted to make Shifts as easy as possible to log into for the first time. So with My HR in mind, we introduced a simple login requiring the employee number (colleagues use this every day to clock-in so they’re familiar with it) and their mobile phone number. Using these details we authenticate and send a login token by SMS, so the process is still secure.

No training needed

Often when organisations introduce a product or service it’s necessary to spend time and money on training for whoever will be using it. This isn’t the case with Shifts. Because we’ve designed it alongside Food colleagues and have tested it with them, the language is familiar and written in user-centred, plain English and the design is intuitive.

Never finished, always improving

We designed in the open and estimate that around 600 colleagues had the chance to input into Shifts and decide the features. Although we feel confident that, with their help, we’ve built the right thing, it doesn’t mean we’ll stop listening to feedback now and iterating accordingly.

If you’re a store colleague, you can log into Shifts now. There is a link at the bottom of every page where you can leave feedback.

Chris Ward
Workstream lead

Before work on Shifts kicked off, Chris was an area manager in south-west London. He’d seen time-consuming processes and difficult-to-use systems first-hand. He moved to Manchester as a subject matter expert to help design Shifts.

How we’ve made release management quicker and simpler

Release management is about how we plan and schedule when we’re building software. Every digital team has its own release management process but sometimes it’s worth reassessing it to make sure it’s as slick and quick as it could be. That’s exactly what we did.

How things were

Our process on the Digital Operations team was complex and repetitive. It was very specific to the Information Technology Infrastructure Library (ITIL) framework which is used to align IT service management with business needs. Our process was also dependent on a single gatekeeper. It didn’t work for us.  

The process worked like this:

  1. A developer would email me a release note.
  2. I’d forward it to the environment owner.
  3. They’d give me permission over email to put the release into their environment.
  4. I’d email the developer to say this was approved and to advise when complete.

This process would then go on for each of the 3 environments (system integration testing or ‘SIT’, pre-production and production) so testing could be started. A typical release would result in around 30 to 40 emails. It meant we wasted a lot of time and the release cycle was slow.

The recording process wasn’t much slicker either. I had to update 3 spreadsheets, make a new folder for each release note and save each one to a central location. Then I sent an email every evening to document what releases we’d made that day.

Something had to change

Frustrations were running high because it was such a tedious, long-winded process. Developers were frustrated because of the amount of emails they had to send and environment owners were frustrated because of the amount of emails they were receiving. It wasn’t practical or sustainable.

Making things simpler and quicker

We agreed what the ideal release management process should look like. We wanted something less email-intensive, more intuitive, easier to manage, something that’s always up to date.

Photograph of the Trello board on a big screen in the office.

I thought a kanban-style approach using Trello and Google Forms might work well. We still had a requirement to keep the release note part of the process so I created a Google Form that asked similar (but more simply-worded) questions. We could then convert the answers from the Google Form into a PDF using Google plug-ins, email it to the Trello board so it would be automatically converted into a card and appear on the board. At this point we’d reduced the amount of emails by between 5 and 10.

Adding in audits

We ran this new process past environment owners who thought a series of checklists on the Trello cards would be useful. This way we could include evidence that testing had been done and that we’d released in the correct order through the environments. When the Change Advice Board (CAB) reviewed releases they had the evidence there already and this would save time.

Trello also lets you assign tasks to people and they’ll get a notification when something’s been completed. So developers could release without having to wait for an email because the testing team had given approval which triggered a notification for the developer. This saved another 5 to 10 emails.

Testing things out

At this point we held demo sessions before putting the Google Form live. After a week we evaluated where we were at. The feedback was positive: releases didn’t get stuck at any approval points, there were far fewer emails and there was a live version of the status and position of releases at all times. The whole thing was much easier and it was self-managing.

Going from good to great

We kept improving the process and after 6 months we’d changed the way we labelled releases as well as the automation of release checklists when a new release is added. I was now only spending around an hour a day making sure things were flowing correctly.

We’re now coming up to a year since we started doing things differently and the process is down to minutes per day. It’s now totally self-managed by the developer, testers and product managers which gives us more time to work on what we’re actually here for: solving bigger problems.

Steven Allcock
Digital service manager