The Digital Service community: here to help you do awesome things

This post is about the Digital Service community – what we do, why we do it, and at which points it’s important for Co-op Digital teams to get in touch with us. Michaela wrote a post that aimed to do a similar thing in May 2017 but so much has happened in the last 9 months, never mind the last 3 years.

Firstly, instead of sitting within the Membership team like we used to, the 10 of us are now spread out and embedded across different product teams. We know multidisciplinary teams are higher-performing and a lot of that comes down to there being representatives from different areas of expertise present to advise at each stage. We realised that if we want teams to consider the things that our community champions, it’s better if we’re more visible throughout a product or service lifecycle.

So, our name has changed too to reflect our new set up: we used to be the Digital Service team and now we’re the Digital Service community.

headshots of the digital services team

When Co-op Digital teams should get in touch

Here are some of the main things we help teams with. Email gdl_digitalserviceteam@coop.co.uk

Speak to one of us:

Before your service goes into beta

The earlier you speak to us, the better. We will help you:

  • put the correct support in place, for example, the service might need support from our 24/7 operations team
  • develop a process so that everyone on the team knows what to do if something goes wrong
  • understand how to identify, record and mitigate risks

Before you make changes to a system

If you want to make changes to a system or you want to push something to live, get in touch so we can make sure change happens in the right way. For example, we coordinate changes across Co-op Digital to make sure your proposed changes won’t clash with another. We’ll consider risk details – but we’re here to enable change, not block it.

If there’s a major incident

If there’s a major incident, like a site going down, we will bring the right people together  – often in virtual ‘war rooms’ – so we can discuss the incident and restore the service. We also send out regular communications to the relevant stakeholders to update them on progress. Our aim is to minimise disruption to our colleagues and customers.

After an incident

When we’ve dealt with the incident together, the Digital Service community will facilitate a post-incident review session with product teams. The aim is to understand what went wrong, how we can mitigate the problem in the future and where we can improve. Each incident is an opportunity to learn more and be better.

Work we’re proud of

We’ve been involved in many projects, where we’ve added value. Here are a few we’re particularly proud of.

Re-platforming the Funeralcare website

We supported the transition from Episerver to the coop.co.uk platform, whilst embedding practices such as incident, problem and change management. We ran a 3-month training plan to help our Funeralcare colleagues, to support our product in an agile way.

Moving Shifts over to ‘maintenance only’

Development on the Shifts app has ended so we worked with the Retail and product teams to change how support works. This support now comes from an operations team rather than the product team but we’ve still had to make sure unresolved issues are managed effectively by the Ecommerce product team. It’s been a success so we’re using this support model as a template for new services within Retail.

Optimising ‘one web’ coop.co.uk 

We reviewed coop.co.uk and identified opportunities to make improvements. Since then we’ve built service models, defined an engagement model for how teams raise incidents, enhanced 24/7 support and created risk frameworks, impact matrixes and service catalogues.

Supporting Co-operate

Co-operate support is now live, we set out processes and best practices so product and service teams can follow a defined support model, which covers monitoring, alerting and reporting.

Saving time and money through Tech Ops

Our tech operations specialists have been working with our suppliers and third parties, to optimise our cloud costs. Providing efficiencies within infrastructure has resulted in savings.

Our culture: here to help, not hinder

The Digital Service community is here to support Co-op Digital teams to build robust services, efficiently. We’re not about blame culture or heavy-handed governance, we’re about being there – involved – from the start.

The bottom line is: we are here to enable you to do some awesome things!

Georgie Jacobs
Digital service analyst

How to run a design sprint remotely

I’m on the Operational Innovation team which supports store colleagues and empowers them to spend more of their time and energy on customers and members rather than on admin and paperwork. Unsurprisingly, lockdown has affected a lot of work for our teamWe had to pause some trialsand of course we couldn’t do face-to-face user researchBecause we haven’t been able to get what we’d been working on into our users’ hands to validate our assumptions, we’ve had to delay making some decisions. 

Making the most of things with a design sprint 

Thpause on our regular work meant we had an opportunity: suddenly, the team had enough time in their diaries for a design sprint. 

A design sprint usually lasts 5 full working days and involves a small team. The team works together to understand a problem and design a solution. It’s challenging, because each part of the sprint is time-boxed and lasts one day only. The intensity means the pace is super quick but generally, teams keep focus, build momentum and sustain incredible productivity over the short time.  

Design sprints can be really inspiring but our question was, how can we do this well, remotely, with the added anxieties of lockdown? 

We adapted the format 

We knew the usual 5 full days would be impossible. Staring at our screens for 8 hours a day isn’t realistic or fairespecially when some people are caring for elders or children, or they’re keeping things ticking over on other projects. So, we broke the work up into 10 lots of 2-hour chunks and spread these out over 7 daysEven though we all agreed to try a design sprint and make it our biggest work-related focus, we also refused to let it become completely exhausting.  

The activities and stages during the sprint followed the methodology developed at Google. Our sessions focused on: 

  1. Understanding the problem and mapping the user journey. 
  2. Interviews with subject matter experts. 
  3. Sketching ideas using the Crazy 8s technique. 
  4. Critiquing ideas. 
  5. Storyboarding one cohesive idea. 
  6. Feedback from subject matter experts. 
  7. Start prototyping. 
  8. Review and finish prototyping. 
  9. Testing with users. 
  10. Synthesising research. 

Format: things to note 

We had one or 2 sessions each day, depending on what else we had on. On the days with 2 sessions, we scheduled in a 2hour lunch break which felt needed 

Prototyping took around 6 hours (2x 3 hour sessions) rather than the 4 hours we had planned and was pretty tiring, so I’d recommend splitting up the 2 prototyping sessions and spreading them over 2 days 

Organising and setting up the remote research took a couple of hours outside of the group sessions, so if you’re a facilitator or researcher, schedule in the extra time.  

It would have been good to spread the research interviews out over a long morning so we could reflect on our observations together. As it was, it felt like we were cramming all the interviews into that 2hour session 

Preparation and facilitation  

Once the team had given the go-ahead for the sprint, put together a plan that laid out the activities, the timings and the tools needed for each session. I had Annette Joseph and Emily Cowell as co-facilitators who gathered the problem statements and relevant materials beforehand, invited subject matter experts to the relevant sessions, and helped me find users to research with – I couldn’t have done it without them.  

Agree roles and responsibilities from the startAs well as facilitators, it will speed things up if you involve at least one subject matter expert, as well as designers to lead the prototyping and user research. A mixture of skills and experience is really beneficial to a sprint. 

Structure sessions so everybody gets to share. And related: decide how you’re going to interact. For example, will you all respond to open questions, or have cameras on? 

Agree what you’re trying to learn with the prototype and decide the scope of the sprint. It’s easy to be overly ambitious but a design sprint is such a short space of time.  

In our team, a couple of people hadn’t worked in this way before so at the start of each session it was essential to outline how it was going to work, how to use the tools and most importantly, the desired outcome of the next couple of hours. 

I made the basic mistake of not checking what browser user research participants were using which resulted in technical difficulties and a last-minute change of plan. 

Get the whole group to take part in synthesis – so everyone sees all the notes and engages with the learnings. 

Online versus in real life 

Plenty has already been written about the difficulty of facilitating sessions when you can’t read the room. I learned to avoid ‘open discussion’ style sessions, in favour of more structure. I asked participants to take turns to share by reading out the notes they were adding to the whiteboard. 

I also felt that despite getting loads of valuable insights from the research, the team lacked that amazing buzz we usually have when we’ve just observed research in person, and we can’t stop talking about it. Maybe allowing time for team reflection after each interview could go some way to replicating that feeling. 

Online tools 

Digital teams are used to working remotely and although some are more favourable than others, there’s usually a piece of software to help with remote collaboration. Lockdown has probably caused us to experiment with more of it, but use something you’re familiar with so you know it does what you need it to do for sprint sessions.   

Here’s what we used: 

Miro – an online whiteboard 
In the absence of physical whiteboards and sharpies, the team used Miro to write and group post-its simultaneously. There’s also almost infinite space (unlike on our office walls), so we could keep all our notes and maps in one place, everyone could see everything at once because we weren’t in each other’s way, and there was no illegible handwriting. 

Figma – for prototyping  
We normally use Figma so there wasn’t much difference here. 

Microsoft Teams – for video calls and scheduling.  
Again, our usual.  

User Zoom – for user research  
User Zoom is a remote research tool that shows the prototype on the user’s screen and allows us to watch them using it via video. Very different from face-to-face research, and prototype on a device.  

I’d do it again 

Overall, the sprint went well – we went from no knowledge to a validated prototype in 10 sessions, and it didn’t feel like we’d compromised in our learnings or output.  

It was a tiring 2 weeks, but we‘re proud of what we achieved. A remote design sprint is not without its challenges, but I’d be happy to run one again.  

Rachel Hand 
User researcher 

How the Shifts team is responding to emerging user needs

Two years ago we launched Shifts – a web app that allows Co-op Food store colleagues to view their work schedules and information about their pay and holiday entitlement. We’ve been developing it ever since, but the past few weeks have been especially challenging because we’ve been responding quickly to meet emerging needs of our store colleagues – they are our front-line key workers.

5,000 extra store colleagues

On 19 March, we used Shifts to send out a message asking Food store colleagues to ‘refer a friend’ to come and work in their store. It was a call for people to help serve their communities by taking on work in stores to meet the higher demand for groceries, and to cover for colleagues who were self-isolating. By the end of March, Co-op stores around the UK had welcomed thousands of new stand-in colleagues. The Shifts web app has played a huge role in the induction process for new joiners.

The aim of Shifts has always been to empower colleagues and give them the information they need at a time and in a place that suits them. But a convenient, remote way of receiving information has become more important than ever.

Here are some of the changes we’ve made to Shifts to try to meet emerging needs of existing and new colleagues.

Communicating updates and guidance

Shifts uses Intercom to send messages to colleagues about new features, and colleagues have been able to contact us through it too. It’s been useful in the past, but it’s taken on more importance in recent weeks.

We’ve been working closely with teams in the retail support centre to update colleagues about personal protective equipment, information they need as key workers and what they needed to know regarding school closures.

Screenshot 2020-04-15 at 12.59.10

We also sent them a thank you message from Jo Whitfield, Chief Executive of Co-op Food.

Data shows that some of the messages were seen by over 43,000 store colleagues which we do not believe would have been the case if it wasn’t for Shifts being accessible for all colleagues on their personal devices.

Showing overtime at a different store

We recently added the capability to highlight when someone is working overtime at a store they don’t usually work at. Now, we can include them – and flag that this isn’t their ‘home’ store – on the same screen as everyone else who’s working a certain shift.

image (4)

We’d been finding it challenging to display this information, but at a time when many new crisis colleagues are helping in different stores it became more important to fix it. We prioritised work on this and now it’s resolved, we know it’ll be a much better experience for managers.

Matching up colleagues with shifts and stores

We know the demand for colleagues fluctuates between stores – some have been struggling to have enough colleagues in each day, whereas others have too many. And because a significant number of colleagues may show virus symptoms at the same time, stores could easily be left without their regular workforce while it self-isolates. To help with this, we’re currently working on functionality to allow managers to advertise available overtime shifts in their store to colleagues in nearby stores. This will allow colleagues to work where they’re most needed, and in places that are convenient for them.

Coming soon: showing available shifts

This month we’ll be releasing our ‘Available shifts’ feature which will let managers advertise overtime shifts and which roles they’d like to find cover for – this is open to colleagues who usually work in their store or ones who work in other stores in the area. Until now, managers have been using notice boards, WhatsApp groups or text messages to arrange cover which – according to research – can take longer than it should. The workaround can sometimes cause confusion too so the new feature should simplify and speed up the process. We hope it’ll be one less thing for colleagues to think about.

As always, we’re starting small. We’re testing this new feature with colleagues in around 10 stores and will roll out.

Doing our bit

Here in the Co-op Digital team we’re not on the front line. We’re not key workers.

But our colleagues in stores are.

There’s been a real eagerness in the Digital team to do whatever we can to support our hero colleagues, make their lives a little easier and lessen their cognitive load.

We’re fixated more than ever on adding value right now. Everyone wants to be useful in a crisis.

Caroline Hatwell, software engineer
Matthew Edwards, content designer

How we launched ‘Co-operate: get or offer support’ in 9 days

Last week we launched ‘Co-operate: get or offer support during coronavirus’, 9 days after the UK Government announced lockdown.

We knew that lockdown would have one of 2 effects on people:

  1. I need help.
  2. I want to use my time and skills to help people.

Screen Shot 2020-04-07 at 12.08.25

Our ‘get and offer support’ service connects someone who needs support with organisations, groups and schemes that can help.

This post is about what has made it possible for us to change direction and respond to emerging user needs quickly.

 Co-operate has always been about community

Co-operate, an online platform that helps bring communities together, launched last May. We wanted to make it easier for people to come together and change their communities for the better.

Co-operate allows you to:

  • see what’s happening – find local events and activities that benefit you and your community (fewer are going ahead during lockdown, of course)
  • find volunteers – if you’re an organiser and would like to find people to help to run a community event, activity or group
  • add an event – list a community activity or event
  • see ‘How to’ guides – for advice, tools and templates to help you make good things happen in your community
  • read inspiring stories – good things that had happened as a result of people coming together in their communities

We wanted to help people come together to make good things happen in their community.

We were growing region by region as we learned what worked for each community – we were live in Leeds, Bollington, Trafford. Next up was Camden.

But the lockdown meant communities were no longer able to come together in person.  The clean-up initiatives and walking groups we were encouraging, now couldn’t happen.

So the way Co-operate brought people together needed to change.

The need for community and co-operation is stronger now than ever

Our priorities quickly shifted to meet the emerging needs of our communities.

We wrote guides to:

We contacted the organisers who had events on Co-operate to offer to help move them online.

Supporting online communities over geographical ones (for now)

Focusing on online activities caused us to think about what we meant by community – it was no longer just geographical. Activities and events could be viewed by anyone with internet access. Co-operate was now catering to a national, rather than a regional audience.

Despite the many and varied changes we were adapting to, it was overwhelmingly clear that the main aspiration of Co-operate remained: people want to support each other and do good.

So, our priority became finding a way to allow people across the UK to ‘get or offer support’ in their community.

There are a lot of initiatives being formed, and online activities and events being set up at the moment. We want to help people make sense of everything that’s available and direct them to the most relevant place to get or offer support.

The service went live on Co-operate on Wednesday 1 April. As of today (7 April) so far we’ve had:

  • 343 people asking for support
  • 3,217 people offering support

We wanted people to be able to use this service as soon as possible. We’ve worked hard, been confused, and had a lot of Zoom calls to try and get this up and running.

Here are some things that have helped.

Collaborating through a crisis

We work in a multi-disciplinary team. That means we have the skills within the team to get a digital service up and running.  But this service has relied on the expertise of so many more. We’ve been working with organisers in communities and Member Pioneers, as well as colleagues in marketing, legal, risk, membership and customer relationship management.

We have regular calls, daily check ins, fortnightly show and tells and work together in shared documents.

And we work in an agile way. That means we start small, test it, get feedback and improve it. Working in this way means it’s been easier to adapt to changes quickly – we’re not tied into pre-internet-era ‘big IT’-style technology.

It’s not always been easy adapting to other team’s priorities, and sometimes the level and range of input has felt overwhelming, but getting expertise from so many areas and professions means we’re:

  • working transparently and collaboratively to get things right (or as right as we can) from the start
  • reducing duplication of work across Co-op
  • delivering a service faster
  • creating a service that works for more people

Using a tried and tested design system

We’ve written, designed and released the service within 9 days.

We wouldn’t have been able to do this so rapidly without the established design patterns, components and content style guide within Co-op’s design system.

Our team includes people who are new to Co-op, freelance designers working for Co-op and UsTwo, a design agency working with Co-operate. The design system has allowed people with little or no experience of designing with the Co-op brand to:

  • write in Co-op’s tone and style – a style that’s clear, inclusive and respectful
  • create designs that are visually consistent with other Co-op services – making it easier for people to recognise it as a Co-op service and trust it

It’s meant we can move fast without sacrificing design quality.

Ryan Hussey, Interaction Designer on Co-operate said: “I’ve found the design system has made mine and Rob Swift’s designs a lot more consistent. It’s made throwing new landing pages, like the ‘How to…’, a lot quicker to design and standardised the build for the software engineers.”

Learning that ‘enough’ is better than perfect

We’ve been designing how to ‘get and offer support’ at the same time as working out the operation and processes that will hold it together.  There’s understandably been a lot of discussion, changes of direction and boundary-moving while we’ve been working this out.

This means that content and designs have been changed or thrown away as we gain more certainty about the service. We’ve iterated and adapted as more information becomes available. And we’ll continue to do this.

The ever-changing nature of what we’re doing means it’s impossible to create a perfect service. We have to create, build and release quickly if this is going to be useful for people.  There’s no time to obsess.

Instead we’ve learnt that ‘good enough’ is more useful than ‘perfect’. Our priority was to get value into the hands – and homes – of our users as soon as possible. We started small and we’re learning and iterating fast. The service will change, adapt and grow over time as we understand more about how it can be useful to people.

If you’ve signed up to ‘get or offer support’ we’d love to get your feedback. This will help us make it better for the people who need it most.

Thank you

Thank you to everyone at Co-op who has helped make this service real, and to everyone who has offered support.

Coming together to make good things happen is more important than ever. As Adam Warburton, Head of Digital Products, said:

“Now is the moment that community is in the consciousness of everyone in the country. Now could be the start of a new community movement.”

We hope so.

The Co-operate team

Service mapping to make friends and influence stakeholders

This post is adapted from a talk Louise and Katherine recently gave at Mind the Product and NUX Liverpool. 

The act of service mapping with your product team and stakeholders improves relationships and helps everyone to work collaboratively.

Here’s why.

You build a shared understanding

Ideally, service mapping should be done with the whole team. That means digital experts from each discipline, subject matter experts, marketing people, policy and legal advisors and anyone else who has expertise relevant to designing, building, explaining, selling or governing the product or service. 

Having everyone in the room at the same time means we all hear the same information at the same point which contributes to inclusivity. It helps avoid any part of the organisation feeling that the things that are important to them have been overlooked because they’re there to represent their area. It also promotes a more holistic approach to service design because it reduces the chances of working in silos.  

After a service mapping workshop, we aim to have a clearer understanding of:

  • the role of each person in the room, their concerns, their priorities and their pain points
  • the scale of the service 
  • how parts of the service fit together, for example, where a colleague’s journey intercepts a customer’s 

For the workshop to be successful however, everyone must keep in mind the reason they’ve been invited to take part: to share their specialist knowledge. Each person must remember that specialist language and acronyms are often inaccessible and they’ll become barriers to understanding for many.

It’s a democratic way to prioritise problems

Service maps offer a visual way to identify pain points. Done well, they can flag all problems regardless of the specific user journey or whichever discipline’s responsibility they fall under.

photograph of the digital team and stakeholders looking at a service map

Service maps make the areas that need attention indisputable because they help show us where the problems are – they’re often flagged by clusters of post-its notes. Each expert is likely to have biases around which of the problems to prioritise, so just making each and every one visible means we’re less likely to overlook something we’re personally less concerned about. Not only does service mapping help protect the direction of the product, in terms of building relationships with stakeholders, it’s beneficial because it feels like a more democratic way of prioritising what to work on next. 

We can also look to the future more easily with a service map – it helps us anticipate and understand the consequences of the decisions we’re making. For example, if we make a decision early on in the service, will it have an impact later in the experience? A service map will help you to see this, and allow you to make better informed decisions.

Service mapping helps you tell the team’s story

A concept, idea or assumption is hard to visualise, so mapping it out and having a physical thing to point to helps make something nebulous more tangible. Service mapping has been a helpful way for the Co-op Digital team to tell our story to the wider team. It’s been a practical activity where we’ve talked stakeholders through the way we work and reassure them that there are often more questions than answers (especially in a discovery) and that’s ok – in fact, it’s expected. Showing this at the beginning of a project sets the tone for the way of working for the rest. 

Working closely and intensely together in a workshop has helped build trust within the wider team. Each discipline is valued and respected, and listening to each person’s contributions helps build empathy. Everyone should be encouraged to contribute and bring all their knowledge into one place to create a chronological journey. The aim is always to create something that’s easy to understand – something that someone from outside the project would be able to look at and understand the direction of the product.

We’ve also found service mapping good to demonstrate the opposite: helping show that there is no problem to solve, or that a concept is not feasible, viable or desirable. 

It highlights the challenging conversations so you can have them early

We know that progress on the product can be slow or even derailed if: 

  • decisions keep being pushed back or just aren’t made
  • we don’t talk about the difficult things as soon as they come up
  • research findings aren’t considered at each step of design 

 To help us to remove these potential blockers, we include them in service maps so we can highlight them to our wider team. We know stakeholders are often time-poor and detached from the product so an overview rather than detail is what’s useful to them. We’ve found that many of ours really appreciate a service map they only need to glance at to feel informed so we’ve taken this into account. 

We’re also conscious that we need to make it easy for stakeholders to give useful feedback. In businesses generally there’s often a pressure on colleagues to say something because they’re expected to – even if it’s not particularly helpful. By having the whole service visually laid out in black and white, it’s easier for everyone to understand and therefore give useful feedback.

Service mapping to show the money

It’s important not to lose sight of the fact that Co-op services are not only there to meet customer or colleague needs, they must also meet business needs and many stakeholders place more importance on this factor. With this in mind, we need to be aware of the business models and commercials when we create the map and we’ve been including things like efficiencies and incur costs in our maps. Including these aspects means we’re being inclusive with the wider team.

It encourages conversation and collaboration

We’ve found service maps help to:

  • get your team working together with a focus
  • bring clarity in times of change
  • make decisions obvious
  • make knowledge accessible
  • help stakeholders care about the right thing

The sheer physical scale of a service map is the simplest benefit. It’s big, visual and imposing.  Put your service map up in your stakeholders’ workspace, people will naturally stop and look at it. When they do, ask them to contribute. Often, we need to get people’s attention to encourage collaboration.

That said, it’s act of making the service map with your team, collaborators and stakeholders that’s more important than the service map itself.

Louise Nicholas, Lead product designer
Katherine Wastell, Head of Design

Introducing local.co.uk – Co-op’s new marketplace

We’ve recently launched local.co.uk – a marketplace that connects independent businesses to customers across the UK. We’re doing this because we want to give small businesses a fairer way to trade and help make communities across the UK stronger.

We built the service in 13 weeks and we’re proud of what we’ve achieved. But we know it’s far from perfect – there are parts of the service that could be smoother and features that we want to improve and introduce.

We launched it when we did so that we could learn quickly from real users and make the service valuable for them.

We’ve done a lot and learnt a lot.

This video shows how we created local.co.uk (2 minutes 26 seconds) 

How 3 researchers used the ‘jobs to be done’ framework

Earlier this year, strategist and researcher Stephanie Troeth and Adam Warburton, Co-op’s Head of Product, gave some of the Co-op Digital team Jobs to be Done (JTBD) training. Since then, our digital teams have tried out this way of working.

A quick introduction

JTBD is a framework for understanding the outcomes users are trying to achieve – this could be a job, a task or more widely their goals in life.

It’s been particularly popular in commercial organisations because it helps us understand where users underserved needs are and, therefore, where the opportunity for the business is in the market. More traditional user needs frameworks don’t say much about the market, and as the Co-op is an organisation looking to make a surplus to put back into member initiatives and community work, we thought it could be useful.  

In this post, 3 of our user researchers talk about their experiences using JTBD.

Vicki Riley, Ventures team

Functional, social and emotional motivations

We’re working towards developing, testing and improving an online platform that connects customers with products from independent sellers, providing benefit to their local community. It’s my job to understand the needs of customers and sellers so we can provide mutual benefit to both.

We used the JTBD framework to find out customers’ underlying motivations and desired outcomes for buying from small independent businesses. We also wanted to understand the competitor landscape from a customer point of view, and identify areas of opportunity, where customers are underserved in an area that’s important to them.

We started with interviews to identify functional, social and emotional jobs, and then created a survey to validate or disprove, then prioritise in terms of importance.

We found that JTBD has worked well while we’ve been facing a new challenge and figuring out a value proposition. This might be because it allows for wider thinking and delving deeper into motivations or desired outcomes, and takes the insights out of the current solution and up to a broader level that could be applicable across different categories.

It’s also been really useful when we speak to stakeholders. Categorising what people are trying to get done into functional, social and emotional needs helped senior stakeholders understand what’s important to people and also identify our value proposition. It became clear our proposition – the area where we were able to leverage some competitive advantage – was going to be more emotional, than functional or social.

It was the unintended consequences that people talked passionately about, for example, the conversations that buying from small independents allowed them to have with friends and the way it made them feel when someone complimented the thing they’d bought. JTBD allowed us to put our focus on these emotional and social elements when developing the service.

Simon Hurst, Healthcare and wellbeing team

A survey to identify underserved needs in the market

We wanted to understand where there were potential underserved needs so we could potentially build a service around them. To try and identify a gap in the market, we ran a survey to assess which jobs around getting access to healthcare we’d identified in interviews were more significant, and which of those users were unhappy with the current way of doing it.

It looked like this:

Screen Shot 2018-07-12 at 16.03.14

Our product manager Derek Harvie wanted to do the survey so we could back up our qualitative insights with some quantitative data. Seeing the data gave both the team and the stakeholders more confidence – data is, of course, very important to new businesses which is what the Healthcare team is aiming to be.

The results of the survey allowed us to map jobs according to whether people were underserved or not – and from that helped to determine the product strategy. This abstract graph is what we worked from:

Screen Shot 2018-07-12 at 16.04.31
The survey worked well. It’s given us additional confidence in our qualitative research. Whilst I can write a decent survey, I sometimes struggle to analyse raw quantitative data, so having Michael Davies, a data scientist at Co-op who could help us with that, was invaluable.  

However, writing a survey for JTBD is challenging. It necessitates a substantial use of matrix style questions. This results in the survey having lots of very formulaic questions, and runs counter to good survey design (something we’ve learnt a lot about through Caroline Jarrett).  

Also, recruiting people for surveys is expensive. Current quotes to go out to non Co-op members is between £3 to £5 per participant. We need to find a way to get these surveys out more quickly and cheaply.

Naomi Turner, Communities team

The switch interview

I’ve been researching how and why people participate in communities. It quickly became apparent that there are lots of tasks involved even when community organisers wanted to do something relatively simple, for example, arranging a meet up. We were interested in:

  1. How people performed these tasks, eg, with a Trello board/ringing round/emailing community members.  
  2. What they were ultimately trying to achieve, eg, a community dog walking day.

Looking at these things together would help us see if there were underserved needs we could potentially build a service around.

I interviewed 3 types of community member:

  1. New volunteers.
  2. Volunteers who had stepped up to an organisational role.
  3. Volunteers who had recently stepped away from an organisational role.

We asked each of them to recall, in detail, when they have switched from using one solution, to using a different solution (for example, moving to Google Docs to record member details from Microsoft Excel). This technique is called a ‘switch’ interviews – it aims to help us understand more about what pushes someone to change their behaviour, and what the pulls of a proposition might be.

Screen Shot 2018-07-12 at 16.05.48
Image: Intercom

Once we had a broad idea of the kinds of generic ‘jobs’ that people were trying to do, for example, how they manage recruitment or finances, who opens up the hall they use – setting up a process routine which meant they as organiser could step back on some tasks), we could break these down further and see broad patterns of activity (the tasks they perform for example?) across people’s experiences, and why.

It was challenging to apply the functional framework to varied and emotive reasons for participating in groups to achieve an outcome. It was also hard to understand what outcome they wanted from their participation in the group.  Creating the most helpful level of abstraction is key to needs being useful to designers to work with, and something we got better at knowing. We went in too low level initially and had things like ‘handling cash’ when it was the higher level that was more useful to design solutions for, in this case ‘managing finances’.

Where we’ll go from here

Overall, we’ve found that JTBD is a useful way of working. However, we think teams would get most of of it if they look at it as part of a toolset rather than as a framework, and tweak their use of it depending on their specific situation.

Vicki Riley
Simon Hurst
Naomi Turner

Help us make our mental health meet-ups better

This week is Mental Health Awareness Week. During last year’s, Tom Walker wrote a post about why and how he set up Co-op Digital’s mental health meet-ups. A year on, Tom’s left but our fortnightly gatherings remain.

Now feels like a good time to kick off a conversation about what we can do to make sure they’re as helpful as they can be.

We’re looking for your suggestions.  

The idea’s still the same

Simon Hurst and I run the meet-ups now. It’s important to make it clear that, like Tom, we’re not doctors either. We’re not qualified to diagnose a mental illness and we’re certainly not qualified to prescribe remedies.

But the meet-ups are a place where colleagues can speak freely, in confidence, and know that they’re among empathetic people. A year on, this stuff is still the same.

Meet-ups are still open to everyone, they’re still informal. There’s still no minutes, no register, no pressure.

But the numbers have dropped

Recently, we’ve noticed that fewer people are coming to meet-ups. Of course, that could be seen as a really good thing – people don’t feel that they need the meet-up anymore because they’re feeling happier and healthier.

As much as we’d love to believe that, we don’t think that’s the case.

Time to make changes

The lunchtime meet-ups did a job. They got people within Co-op talking about mental health, often publicly, often openly. They helped reassure people they didn’t need to feel ashamed and that they weren’t alone.

It’s clear from speaking to people that even though there appears to be less demand for a mental health meet-up every other week, the idea of it existing, the idea of it being there if it’s needed, is comforting.

However, it’s time to adapt to meet people’s needs. We asked people who attend for their thoughts.

We learnt that:

  • some people find getting out of the office, in the fresh air, over lunchtime helps them most and, ironically, the meet-up was messing with that
  • everyone’s busy and taking time out in the middle of the day isn’t always easy

In response to that, here’s what we’re thinking of trying:

  1. Arranging walks – mental health meet-ups where we can walk and talk and take people out of the office.
  2. Drop-in slots – spreading out the times when we could meet up so there’s no set time and support’s there as and when it’s needed.
  3. Changing the day of the meet-ups.

Let us know what you think in the comments. Your feedback matters.

Mental health first aid training

We recently invited Mental Health First Aid England (MHFA) into Co-op Digital and a handful of colleagues took part in a mental health ‘first aid’ training course. The idea is that we can look after team mental health and morale better if we have ‘first aiders’ who recognise early on when team members are struggling.  

In theory, agile teams are fairly healthy. Relatively speaking. Agile ceremonies like daily stand-ups and fortnightly retros act as check-ins with the team – they’re places to bring up struggles, blockers and concerns.

But the take-away point from the training was that we all need to learn how to listen. In Digital, our job is to solve problems. Because of this, it’s easy to throw ‘answers’ out to colleagues who are struggling. The training taught us how effective just listening, without proposing solutions, can be.

Help and be helped

Co-op Group offers advice on setting up a mental health support group. There’s also an Employee assistance programme.

And there’s us, in Digital. You can request to join our dedicated and private mental health Slack channel.

We’ll continue to be here, in whatever format works for our colleagues and friends. Your feedback will shape this. We hope to hear from you soon.

Becky Arrowsmith
Engineer

Making the move to user research

User research helps make products and services that work for the people who use them. It takes loads of different forms including lab sessions and interviews, onsite visits and analysing data but, regardless of its form, it must be present throughout the design process. And even after the thing is live.  

Moving into a user research role

I’ve worked at the Co-op for just under 2 years. I originally joined the Analytics and Optimisation team, but for the last 10 months I’ve been a user researcher at Co-op Digital.

User research really appealed to me because it’s about listening to users as well as looking at data. My old role was heavy on the quantitative side of things: I evaluated data collected from user journeys and improved the experience for users. Good user researchers consider both quantitative and qualitative research so I’ve been working on my qualitative research skills. Now I feel even better equipped to help teams design the right thing.

User research at Co-op Digital

I applied for a user research role after seeing the work that our now Head of User Research James Boardwell and the team were doing with wills. The multidisciplinary team was working in an agile way to build a digital service to make it simpler and quicker for Co-op customers to get a will.

I saw how both data and qualitative research fed into the design process. User research formed the basis for discussions and the team could test ideas, put them in front of people and iterate them quickly. The whole team came to user research sessions so that everyone saw first-hand how users behaved when we put prototypes in front of them and asked questions. The team analysed the themes that came out of the sessions together which meant that everyone had a similar idea about where the design was heading.

Everything moved so quickly and decisions were based on things that the team had seen or heard. At each show and tell the team knew so much more than the week before – they’d added another piece to the jigsaw. They’d started small and built the right thing, quickly. I loved watching their progress.

My first taste of user research

Supporting James was my first experience as a user researcher. I joined the Wills team during a sprint focused on increasing the number of people making it to the confirmation page. I already had good experience in this from my previous role but here I also got to see James talking to people, showing them the prototype and doing qualitative research in lab sessions.

The data I’d collected told us what was happening with real people using the website, and James’ conversations with people told us why it was happening. The data showed that the exit rate from the ‘Your details’ page was disproportionately high. Qualitative research told us that people felt uncomfortable giving their personal details before knowing exactly what the service offered. Changing the order of the pages, so, giving the user more upfront information, resulted in more people completing the form.

The 2 kinds of insight complemented each other. You can read more about this in James’ post, User research and sample sizes.

Learning how user research works in a product team

I spent 6 months working with the Membership team too. User research gives us the chance to test things to make sure we’re doing the right thing for users. This way, any decisions we make are better informed.

Working on Membership opened my eyes to other ways of doing research too. It’s not just about interviews. We:

  • used qualitative website feedback and quantitative analytics to compare what users told us with what they actually do
  • visited stores to find out what our members and customers talk to colleagues about
  • spoke directly to members

It’s about analysing all available resources.

Leading my first project

Photograph of a user research session. Shows 10 members of the Electrical discovery team talking about and analysing what they've seen in the user research lab.

For the last 2 months I’ve been leading the user research on a discovery in our Electrical business. This project has helped me learn a lot about how user research informs service design through techniques like customer journey mapping and service blueprints. Service design is a fairly new way of thinking at Co-op Digital so leading this project was sometimes challenging, but we’ve got a strong user research community at Co-op Digital and support and advice was always available if I needed it.

Hard work, but worth it

I think the biggest challenge for a user researcher is using all of their observations and data to find the need, and working with the team to translate these into things we can work on.

User research encourages teams to take a more balanced approach to design. It changes the way teams work and brings the business and digital sides of things together. It’s a way to stop people jumping to conclusions about what’s ‘right’ because we’re using evidence to make decisions. And ultimately, that’s going to work better.

If learning about how people behave and why sounds interesting and you want to help teams build the right thing, quickly and cost-effectively, get in touch with James Boardwell or leave a comment on the blog.

Vicki Riley
User researcher

Immediate changes in Membership reporting lines

As we develop our membership services proposition across the Group, and now we’ve welcomed Roberto Hortal into the Group as Director of Membership Products and Services, Nathan Warner will step into the role of Interim Head of Membership Proposition, reporting to Roberto.

Working closely with the members leaders groups, Nathan and Roberto will be responsible for developing our member proposition and will immediately focus on our operations and financial plan for 2017, concentrating on membership service delivery and implementation.

Rufus has a huge responsibility in the next few months: to represent our Membership proposition externally to our Council and FRTS. Along with owning and delivering our Community strategy including Co-op Campaigns, Partnerships and Ethical Trading positions and internal and external communications.

Roberto, Nathan and Rufus continue to work as part of the central Digital team.

Mike Bracken
Chief Digital Officer