What we learnt from Jared Spool

On Tuesday eve, much of the design community from Co-op Digital and the wider north west attended User Research North’s event to hear Jared Spool’s talk.

Over the years, Jared’s influence and presence in the design world has been widely felt and acknowledged. He co-founded Center Centre, a school to train user experience designers and ultimately, Jared helps designers help their organisations deliver well-designed products and services. You can read more about his work here.  

We learnt a lot from him.

In this post, a handful of Co-op Digital colleagues reflect on what they learnt on Tuesday and how:

  • their new knowledge will help them with their current Co-op work
  • knowing this earlier would have helped with past work

Experience design: all the moments, all the gaps

My big take away from the talk was this quote:

When we think in terms of experience, we’re thinking of the entire flow: all of the gaps, all of the moments. That’s what we mean by experience design.

In Co-op Health, we’re providing a service for people who want to order their repeat prescription through our app. This is the front stage – the part the end user sees.

But the back stage of the service needs to be considered to fulfil that entire flow so every moment is accounted for. For example, when you order a prescription, this needs to talk to the NHS and the GP surgery. The prescription order then needs to be made and checked by a pharmacist before it’s picked up by the Royal Mail and delivered. All of those aspects of the service will impact the experience and service we’re providing for people.

Jared’s talk made me think even harder about the importance of collaboration, inclusivity and co-creation across teams and external organisation – it’s a good place to start to ensure the overall service is the best it can be with ‘moments of delight’ Jared mentioned.

Lucy Tallon, principal designer

Demonstrating difficulty is worthwhile

I loved this analogy from Jared. I’ll paraphrase:

A tightrope walker’s act is to walk up and down a rope in a circus. Realistically, keeping their balance and walking the length of the rope is easy for them – they can do it without any trouble. But, if their act appeared to be super easy, the audience is less likely to appreciate the tightrope walker’s skill because the difficulty in doing such a thing isn’t being amplified. The ‘act’ of ponderous steps and motioning a wobble every now and then, which in turn prompts a drum roll every time they do so, is meant to produce suspense and show how hard the task is.

We can learn from this circus act. We too can show the challenges of a design process.

What we do is hard, but to people whose expertise aren’t in design, most websites and apps seem easy. Working in the open; being transparent about how we make decisions and why we’ve made them; ensuring that we have a diverse set of people in the room helps everyone understand the process. Blog posts, week notes, putting our work on the wall, inviting feedback, seeking out stakeholders who haven’t been involved in the design and taking them on research are all things that help. The talk highlighted the importance of continuing to do these things.

Nate Langley, principal designer

Context is where design happens

Jared spoke about the importance of context when solving design decisions.

He showed examples where designers had made improvements to designs from other organisations that they had found particularly poor.

But, although the designs used user-centred design techniques and looked more appealing, they were not feasible in the context in which the organisations operated. The hardware the organisations used, the interconnectivity of their systems, the constraints of their tools and processes, rendered the suggested ‘improvements’ to designs almost impossible (and would cost far too much). As Jared said in a related blog post:

“Often when we see usability problems in designs, it’s because the design team didn’t know something about the context that they should have. Teams with a strong awareness of the different contexts that will crop up are more likely to produce designs that will consistently delight users.”

I’m working on the new Co-op Health app. The majority of the team are new to working within health. And, because we connect to NHS systems, there are a number of constraints that are out of our control.

Jared’s talk reminded me how valuable it is to get as many people involved in the research and design process as possible. Doing this not only allows us to understand the technical constraints and challenges that our designs must operate within, but diverse perspectives help us design for the different personal contexts of our users too. By understanding the challenges that we and our users are facing, we’re able to design solutions that meet both our operational goals and the needs of our users.

Joanne Schofield, lead content designer

From ‘unconsciously incompetent’ to ‘unconsciously competent’

I’m working on a Co-op Food project with people from across the organisation whose expertise are in many different disciplines.

Jared explained that everyone needs to be involved in the design process in order to deliver a successful service. He said that everyone is a designer – we’re just at different stages of the 4 stages of design understanding.

4 post it notes showing the progression of design understanding. far left - far right reads: unconscious incompetence, conscious incompetence, conscious competence, unconscious competence

Jared talked about how organisations sometimes use strategies or ‘plays’ (an American football analogy) to help teams improve their awareness.

It’s our job as designers to help people who don’t identify as designers move from being ‘unconsciously incompetent’ at design to being ‘consciously incompetent’. This highlighted the importance of exposing the wider team to journey maps; the concept of story mapping and involving them in user research so they see how people are using a service first-hand.

From now on, I’m going to start identifying activities in our playbook that Digital team members can use when we need to help colleagues jump between stages. Some ‘plays’ may not be effective, but that’s OK, we can try another until we’re all playing as one team in perfect formation.

James Rice, lead designer

Changing the behaviour of others… with our thoughts

Jared talked about an experiment where a group of rats were labelled as ‘smart’ or ‘dull’ and what people were told about the rats affected the result of the experiment. Sounds like nonsense, but I’ve seen this happen.

Screenshot_20190531_104922_com.instagram.android

This is down to something called the ‘expectancy bias’. Your expectations of people or a team will affect how they perform. If you go in believing someone is not a designer, and therefore not capable of creating good design, they won’t.

“Expectations can change outcomes,” Jared said. “Our expectations can change our team’s outcomes.”

I’ve noticed that when I go into something assuming the worst, whether it’s a stakeholder who I presume has bad intentions, or a team I think aren’t capable of making a good product, I tend to prove myself right. Now I try very hard to assume the best possible thing of people and, even if they have different motivations to me, they believe they’re doing the right thing.

I once worked on a product with a very inexperienced design team, and quickly got very concerned we couldn’t deliver the design. When I forced myself to think positively, I saw a significant change in the quality and output of our work, and we delivered.

Katherine Wastell, Head of Design

We’re always interested in hearing about great speakers and significant talks that have changed your way of thinking and working. Comment below.

Co-operate: an online platform to bring communities together

We recently launched Co-operate, an online platform aimed at bringing communities closer together.

So far, our research has told us we should be designing something that makes it easier for people to:

  • start local groups and find others to team up with
  • find a community space
  • club together financially to reach a goal
  • come together and campaign for something they’re passionate about

As always, we’ve started small. We’ve restricted Co-operate to one area for now: Stretford in Manchester.

This post talks about the research that’s shaped the product, what we’ve done so far, and why Co-operate is so very ‘Co-op’.

Community is part of what all co-operatives stand for

The Co-op shares many values with other co-operatives including ‘self-help’ (members joining together and making a difference) and ‘self-responsibility’ (every member supporting their co-op’s activities and using its products and services and encouraging others to support it too).

‘Concern for the community’ is one of the Co-op principles. One of the ways we demonstrate this is by giving 1% of what members spend on Co-op branded products to a local community cause of their choice. Since we launched the new Co-op Membership in 2016, £31.7 million has been invested in around 4,000 community projects thanks to members’ 1%. This has supported a range of community groups including adult literacy classes, youth clubs and schemes that bring isolated older people together close to where they live.

Our new Co-operate platform is an extension of these values and principles. It aims to help communities to make changes autonomously through co-operation – it’s a natural fit for the Co-op.

Clarifying the problem

Last year Co-op started to look into communities. The previous exploration and tests showed us that the combination of people and technology can make it easier for people to co-operate. Over the years, we’ve interviewed volunteers, charity workers, social entrepreneurs and community leaders to find out what’s stopping local communities from coming together to make themselves stronger.

Their research reaffirmed our assumption and we’ve recently been able to clarify the problem: People find it hard to connect and make things happen in their local community.

Poster that says: People find it hard to connect and make things happen in their local community.

From this, we set our vision: Build the one place to go to make things happen in local communities.

poster that says: Build the one place to go to make things happen in local communities.

Ambitious, bold and exciting.

Starting small and locally

As with all digital products we knew that we would need to start small, test, learn and iterate. We decided to do a series of hyper-local trials across Greater Manchester and build collaboratively with users in those areas.

We started in Stretford by assembling a small, multi-disciplinary team and behaving like a start-up. We wanted to build a lean version of the service so we could learn quickly, without wasted effort. By manually adding content ourselves rather than building an expensive content management system, we know what is useful.

Listening to users

We’ve been talking to community organisers in Stretford – the heroes who have managed to start groups that benefit the local area. They’ve told us about the challenges they’ve had to overcome and the ones they’re still struggling with. Most told us:

  • promoting events time-consuming
  • finding more volunteers is hard
  • co-ordinating volunteers is difficult
  • getting access to funding is complicated
  • connecting with other organisers doesn’t happen often

A lot of this is consistent with the research that was done last year. But we are now in direct contact with these people, and see them as an extension of our team. They are the subject matter experts – they’re living and breathing life in a community every day and pushing to improve things for many.

First feature: a ‘digital noticeboard’

As a result of listening and observing, we’ve built a product that pulls together local events and activities that benefit the local area in some way. It’s a kind of digital noticeboard for Stretford called ‘What’s happening’.

Photograph of Co-operate's What's happening in Stretford

We’ve set up a simple, flexible architecture using our Heroku prototype platform along with Contentful, Algolia and Gatsby.js. This lets us quickly try things whilst at the same time being secure and performant.

To get to this point we:

  1. Took photos of all the noticeboards in the area.
  2. Analysed the information and grouped it into categories.
  3. Set up our content management interface and added in the information.
  4. Tested it with users (Stretfordians).
  5. Improved the UX and re-wrote some of the content to make it clearer for users.

You can see this at co-op.co.uk/co-operate.

Next time, we’ll share why we started with a ‘What’s Happening’ product and the next product that we are starting to develop.

If you want to get in touch, email us at co-operate@coopdigital.co.uk

We’re particularly interested in understanding what you’d need to know before you would commit time to helping out in your local area.

Ben Rieveley
Product manager

Co-op health: running a design sprint across disciplines

Last week we launched an app that helps people view, order and manage their NHS repeat prescription from their phone. We want to make prescription ordering easy and convenient for people by providing self-service, simple collection and delivery options, and transparency throughout the process.

The app is very much a first version that we’ll continue to test with users and iterate on.

However, we think this is a good opportunity to talk about the work we did on a feature that we hope to add to the app soon.

Trying out a 5-day design sprint

As with many big, traditional organisations it can sometimes be difficult to move at pace within the Co-op. Design sprints can be useful to answer critical business questions quickly so we thought we’d give it a go. We got a group of designers, researchers, engineers, pharmacists, product managers as well as subject matter experts together for 5 consecutive days to build a realistic prototype. Having the relevant people in the room who could make decisions on behalf of their area of expertise was essential.

Design sprint: booking medical appointments

During the design sprint we were looking at how people book an appointment with a medical professional.

Together, we spent a day on each of the following tasks:

  1. Defining the challenge.
  2. Sketching ideas that might help us solve the challenge.
  3. Choosing an idea to take forward, then storyboarding it.
  4. Designing a prototype of the chosen idea.
  5. Putting the prototype in front of users and listening to feedback.

Day 1: Defining the challenge

The first day allowed us to reframe the problem we were trying to solve. So, our week-long sprint goal was to build a simple, intuitive app for booking appointments for anyone registered with a GP in England. With this in mind we created ‘how might we’ questions, and turned problems into opportunities by asking questions such as:

  • How might we help people get the help they need, more quickly, so they can lead happier and healthier lives?
  • How might we be open and transparent about the process of booking appointments?
  • How might we update people about their appointment?

Working in this way encouraged everyone involved to see the bigger picture. It helped us think about our end goal and why we want to achieve it. Zooming out like this also helped keep us on track for the rest of the sprint when there’s a focus on detail.

Day 2: Sketching ideas

photo of team sketching on day 2

When it came to sketching out ideas for possible solutions to the ‘how might we’ questions, we used the ‘4-part sketch method’. It guides team members through note-taking and generating 8 rough ideas through to a ‘solution sketch’ – something slightly more carefully thought-out. Importantly, it asks that people work alone at this stage.

We found this really beneficial because when you’re working with people you don’t necessarily often work with, it can be intimidating. Working alone and then sharing ideas anonymously avoided extraverts and ‘leaders’ grabbing the most air time and encouraged more confident participation from quieter team members because they knew their ideas would later be seen and heard.  

The solution sketches included chatbots; statistics dashboards and smart reminders as well as the use of video to explain complex processes and ideas that use artificial intelligence.

The next step was to choose which of these ideas we’d take forward into the rest of the sprint.

Day 3: Choosing and idea and storyboarding

photo of storyboards - lots of post it notes

On decision day, we put the solution sketches on the wall for everyone to see. The ideas were so wide-ranging which shows the importance of including colleagues from different business areas. It highlighted that we all have different priorities, but explaining our sketch solutions helped everyone understand where those priorities come from.

Using stickers, we flagged anything that aligned to our sprint goal which made it easier to see where or if we could merge different ideas. We then did a ‘speed critique’ which involved an impartial person talking through an idea that wasn’t theirs – it helped make sure everyone’s ideas were viewed equally.

Settling on one idea

photo of the chosen idea's storyboard

After a vote, the team decided to combine ideas around organising different types of appointments, smart reminders and linking repeat prescriptions and appointments. This is what we’d take forward to prototype, but first we created a storyboard –  a visual map of the user journey.

Day 4: Prototyping

photograph of 4 of the team prototyping

The next day we brought the storyboard idea to life by creating a working prototype. Working in this way allowed us to quickly create something which we could place in front of users the following day to get their feedback.

These images show how reminders might work in the app.

screenshot of the reminder in the app prototype

Day 5: Getting feedback from users

photo of user research participant's hand and mobile phone using the app prototype

On the final day of the sprint we put the prototype in front of potential users. We held 5 sessions in the Federation user research lab, and we visited 1 participant who had accessibility issues in their home.

Here are some of the things we learnt from the research:

  1. People don’t just manage their own health, they book appointments for children, parents or grandparents too.
  2. A big pain point in the process of making an appointment is waiting (particularly waiting on the phone for half an hour) Any way we can reduce the time spent on managing / booking the better.
  3. People often have a preference about things like whether they see a male or female doctor, or their appointment time (for example, on their lunch break). Allowing people choice is important.
  4. People were very positive about appointment reminders. They felt they helped them manage their health better.
  5. Our service needs to be reliable with no technical issues. If there are issues a person is less likely to use a service like ours again and revert back to non-digital methods.

What’s next

We’ll be feeding what we’ve learnt back into the design process and improving the prototype. Now the app is live we’re also gathering customer feedback & seeing what the pain points are we need to work on next.

And we’ll continue to work closely with stakeholders because their expertise have been invaluable.

Lucy Tallon
User researcher

You can read more about the Co-op health’s proposed work.

Why Co-op Digital writes a newsletter

The Co-op Digital newsletter recently turned 3 years old. This week we’re writing newsletter number 139.

80_116_61_64b_small

The newsletter is a weekly email that looks at what’s happening in the internet/digital world and how it’s relevant to the Co-op, to retail businesses, and most importantly to people, communities and society. You can:

“Poke the organisation”

In 2016, Co-op Digital was in its infancy and Deputy Group CEO Pippa Wicks and Russell Davies, then the Digital Strategy Director, asked me to put together a weekly newsletter. Pippa’s simple brief was to “poke the organisation!” Their plan was that it should challenge the Co-op Group to think about how ‘digital’ changes retail and how retail could use digital. The newsletter summarised what was happening on the internet, and explained how other retailers were using technology.

It also helped set a tone for Co-op Digital because it demonstrated to senior leaders, the wider Co-op, and to the rest of the world that we were watching the internet and that we understood it. All of this was important because the Co-op Group was in a period of reinvention after some difficult years.

Content and tone

Many of the early stories were “Amazon is cominggg!”, or this is what Tesco’s doing with AI, here’s a funeral startup, or an AI is surprisingly good at chess. We were explaining what was happening on the internet, and what some of the new technology weirdness promised.

We write it in fairly plain language, and in a way that readers don’t need to click the links unless they want to read about a story in more detail. Sometimes there are jokes. “They’re trying to make me ICO to rehab” was a story about hospitals helping cryptocurrency addicts (and yes let’s acknowledge here that explaining a poor joke makes it even weaker). But the humour can make the words more engaging and accessible, and can let us talk about things that aren’t the Co-op’s ‘official position’.

The importance of images

Each newsletter is published with an image which is there to catch the eye when the reader is scrolling through their Twitter timeline. Some studies say tweets with image links result in up to 200% more engagement so we always include one. Sometimes the image is just decorative, sometimes it relates to the newsletter’s content.

48_65_94_132_small

How it’s made, and how it’s read

The newsletter is made by a team. Stories are found and then debated by Co-op colleagues in the #newsletter Slack channel – big salute to Richard Sullivan, Jack Fletcher, Linda Humphries, Gail Lyon and others who’ve found and written about many excellent stories. Suggestions also come from readers to me on Twitter.

It’s published as a public-facing email newsletter, and as an internal email, and to the web. Mailchimp (which handles the public email bit) reckons it has an open rate of 50%, compared to an industry average of 11% for other retail organisations.

Plus it’s been well-received internally too…

Screen Shot 2019-05-10 at 11.08.27

Evolving with the organisation

The newsletter has evolved, mostly in response to feedback from readers, but also to the Co-op’s maturing digital capability. We don’t need to explain ‘digital’ in the same way these days because many teams and departments at the Co-op have transformed the business over the last 3 years. Where the Co-op was once an organisation of tradition, now it is also an organisation of the internet. This evolution has given the newsletter space to look at wider concerns, like privacy, ethics, climate change, and occasionally even Brexit.

External intelligence

It’s still valuable to keep track of what other organisations are trying and to think about whether what they’re doing could mean something new for us, our members, our colleagues, or for co-operativism. So the newsletter is both external intelligence for the Group and an informal channel to communicate with the public and members.

We’ve learned that newsletters are good at showing our thinking in public, exploring new ideas and clarifying them, speculating wildly about what’s next, and occasionally ‘poking the organisation’.

Still the same

There are still “Amazon is coming!” stories, and there are frequent “this seems like a problem for big tech companies” stories. Occasionally we add small bits of fiction if we think they might be a good way to explore an idea.

However the jokes are still terrible. “Do you want frAIes with that?” needs not an explanation (machine learning at McDonald’s) but apologies forever, sorry.

You can help

You can help make the newsletter better. Sign up to get the newsletter by email and participate by sending us ideas, questions, thoughts. And better puns.

Rod McLaren
Newsletter writer

Data ethics canvas: helping us make good data decisions from the start

Being ‘trusted with data’ is something we talk about a lot at the Co-op and part of the Data team’s role is to make sure that every team is thinking about data responsibly. To help, we provide guidance and practical support to colleagues across the business.

Last June we started introducing our Digital teams to the Open Data Institute’s (ODI) Data ethics canvas. The ‘canvas’ is a template. It’s designed to help teams anticipate potential ethical issues associated with data they’re using, or coming into contact with, right from the beginning of a project.

A year on, the canvas has been gladly received and well-used, and now we’re rolling it out further.

Here’s a call to anyone making data decisions to use the Data ethics canvas.

The benefits and why they matter

The canvas allows teams to design with data in mind, making sure we maximise its value and understand associated risks. Tackling data-related questions early, with support from our expert teams at the Co-op can help minimise or even avoid any rework or surprise challenges or unintended consequences. Dedicating time to map out and consider the possible consequences of their data decisions has helped teams move forward quickly and autonomously and feel confident that they’re doing the right thing for our members, colleagues and communities.

Data ethics are here to stay

A clear message is emerging from regulatory bodies: the ethical use of data is a growing priority, and rightly so. The ODI has referred to ‘trust as the new currency’ and responsible technology think tank Doteveryone has launched their ‘Consequence scanning’ event to help tech companies replace the ‘move fast and break things’ culture with a more considered approach.

Using the data ethics canvas for the first time

If you’re working on a new project, product or service, we recommend running a workshop to consider the decisions you’ll need to make about the data you’ll come into contact with.

The sooner in the process you do this, the better.

image (9)

To get the most out of your workshop you should:

1. Scope and prepare it beforehand. You can do this with fewer people but try to include the project expert, the product manager and a delivery manager who can later facilitate the workshop. You’ll need to get a shared understanding of the importance of the canvas, pin down the benefits of working through it in the context of your specific project and decide what you want to get from the workshop.

2. Invite your digital product or service team as well as data experts to the workshop itself. You’ll need to around 90 minutes of their time. The data representatives could be from data management, data protection and information security depending on the project so email co-opdatamanagement@coop.co.uk to find out whose expertise would be best suited.

3. Print out the canvas and the topic headers (you can download them). The bigger you print, the more space you have to write which makes things feel more inclusive. 

4. Enlist scribes from the delivery team. Make it clear that everyone can and should contribute but delivery managers usually feel comfortable being on their feet, taking a lead when it comes to capturing thoughts, encouraging participation and collaboration and generally making workshops more dynamic.

5. Together, work through the 15 topics.

Topics and discussion points  

The canvas has more detailed discussion prompts but here’s an overview of the questions it asks the team to think about.

  1. Data sources (Where does it come from?)
  2. Limitations with the data (Is the data poor quality or does it have a known bais?)
  3. Sharing this data (Who are we sharing it with? Why? How?)
  4. Laws, policies and classification (Are we in line with GDPR; the Data Protection Act 2018; Co-op Information Classification and Handling Policy; is the information confidential?)
  5. Rights over data sources (Do we have permission to do what we’re planning to do with it?)
  6. Existing ethical framework (Does it align with the Co-op ethical values?)
  7. Purpose for using this data (Is there a good, mutually beneficial reason for collecting or using the data? Does collecting the data make things better for members, or, can we gain insights into products from it?)
  8. Communicating your purpose (When we ask for data, are we explaining why, in the most appropriate way?)
  9. Positive effects (How can we increase the positive impact of the project and how can we measure it?)
  10. Negative effects (Are there any points where there’s potential for a data breach?)
  11. Minimising negative impact (Where can we reduce harm and how can we measure the impact?)
  12. Engaging with people (Describe how people can engage with you and your project, are the people affected able to appeal or request changes to the product or service)
  13. Risks and issues (Where are the financial and reputational risks?)
  14. Reviews and iterations (When should we revisit the canvas?)
  15. What happens next (Who’s doing what and where should they go for support if it’s needed?)

Checking in and following up

As with all workshops, you’re likely to have a list of actions. Check in with the team on their progress against them. Schedule in another workshop when a product or service enters a new delivery phase.

Wider data support for Co-op colleagues

The Data ethics canvas is an introduction to thinking about data, and there’s more information on our intranet and Confluence pages. Our ‘Privacy by design’ playbook gives teams design considerations at the next level of detail.

You can find more support on running the workshops in our Data ethics canvas guide. Or you can email co-opdatamanagement@coop.co.uk for further support.

Find out more

You can read our commitment to data ethics in the Co-op Way Report 2018, and we’ve recently published our internal data ethics policy. We’ll be sharing our latest news and progress on data ethics to other ODI partners and members at an ODI Fridays lunchtime lecture on 10 May 2019.

Dale Upton
Data education and awareness manager

18 months on: our Digital Technology Operations team

It’s been just over 18 months since we first spoke about our Digital Technology Operations team so it’s time we reflected on how we’ve been helping product teams to deliver, what we’ve learnt and what’s next.

Developing our role as a ‘landlord’

In our first post we explained that our team looks after 3 things:

  1. Service management.
  2. Platform infrastructure.
  3. IT security.

Another way to think of our role is as a property landlord.

The various delivery teams are independent from us in the sense that they look after the direction and design of their digital product or service – in other words, how each household is run isn’t our concern. However, all Co-op products and services have some things in common which make up a shared digital platform. This includes firewalls, a logging and alerting platform and core templates used to build out our infrastructure. This is the part that our team is responsible for. We’ve set the ground rules and make sure all new products and services follow them (like good tenants). It helps teams keep their products and services safe and operational.

How we’ve helped

1.Putting checks in place

We’ve set up a ‘service readiness’ check that new products and features go through before we call them ‘live’. A recent example is when we launched Coop.co.uk on new infrastructure. The check includes making sure:

  • security testing is complete
  • the relevant operational teams know what’s changed
  • the relevant people know what to do if something goes wrong

2.Helping teams manage cost

We now provide a cost management tool for our delivery teams to help them manage their cloud infrastructure cost. Each team has a dashboard that shows their current spend and their forecasted spend. Having visibility over this gives them autonomy over how they manage their budget and lessens the likelihood that they’ll overspend.

Image of the cost management dashboard. It shows a 6 month forecast, a past 6 month spend and the actual spend.

Having a cost dashboard helped the Membership team to see that infrastructure logging was costing more than expected one month. When they investigated they found that the logging was sending data every second rather than every minute. Real-time cost reporting helped them spot the increase quickly so they could fix the configuration and incur only a few days of an increased cost.

3.Improving reliability

Over the last 18 months we haven’t changed the tools such as logging, monitoring and alerting systems, but we have worked hard to make them more reliable. For example, we’ve worked with our monitoring tool supplier to tweak how we configured it. Now it can handle more data easily.

We’ve also put efficient processes in place when there’s a problem. Teams can see the details on a status page and we alert the relevant people to fix the problem through our ‘major incident’ process.

4.Getting buy in from teams

We ask that delivery teams make sure they secure their infrastructure following our guidelines; carry out regular security and disaster recovery testing, and build products and services in line with our approved tech stack.

It’d be easy to say we just provide the tools for them to do this. But in the last 18 months we’ve done much more than that: we’ve successfully explained the importance of good technical standards to teams. We have their trust and their buy in and as a result there’s commonality and consistency between all Co-op products and services.

What’s next

Over the next 12 months we’ll be working with the rest of Co-op IT to shape some of our existing IT management processes, like disaster recovery, to make them work for the new challenges that cloud infrastructure brings. And as our digital teams start to use new technologies like containers and serverless, we’re looking at how our tools and processes can be adapted to support these as well.

Over the next few blog posts we’ll talk in more depth about how we do monitoring, how we manage our services becoming unavailable and how we onboard a new service.

Michaela Kurkiewicz
Head of Digital Technology Operations

Lessons learnt by a non-digital colleague: the benefits of agile ways of working

Last month we introduced ‘Visit’ to 55 Co-op Food stores. Visit allows store visitors to efficiently, and independently, check in and check out on store tablets or customer till screens.

We began designing Visit in October 2018. Below is a photo of me setting up an early alpha test in store.

Photograph of Nick, middle-aged man wearing a smart coat and shirt holding a paper sign saying 'Visits' above a tablet with the Visit product on there.

Visit is in beta right now meaning that our research and testing are ongoing and we’re making small improvements regularly. We’re hopeful that we can roll it out to all Food stores by autumn and that it will save time and solve efficiency problems.

But this post isn’t really about how we went about researching and prototyping a new product. It’s about the processes and practices associated with agile – a way of working that was unfamiliar to me and many of my immediate colleagues. It’s about the benefits of working in this way and why non-digital teams should be collaborative, open-minded and committed to learning about, and designing for, their user.

The problem: a long, old process

I work in the Risk team. Visits to a store are frequent and essential, and as part of my role I saw a lot of inefficiency when it came to signing in store visitors. The process would often be:

  • ask a colleague at the till for the visitor book and a pen
  • fill in your details
  • listen to the colleague to explain the store fire process
  • wait for a manager to take you to the back office
  • sign on to the PC
  • read the asbestos report
  • sign a paper acknowledgement of the report in the health and safety folder

It shouldn’t have so many steps in the process. It shouldn’t take this long. It shouldn’t involve so many people.

Our Field risk team regularly visit stores to train management on health and safety controls. As a result of the complicated, long-winded visitor flow, this was one of the least followed processes. There was also a lack of visibility around who has visited, so on occasions third parties have claimed to have visited a site but there is no evidence they have been.

I wasn’t the only one who wanted to improve this process.

Learning new skills and different ways of working

At this point, my knowledge of digital design was limited. I knew that digital product Shifts was co-designed for Co-op Food colleagues, and that other pieces of the Leading the way work relied on expertise from Digital, Food colleagues at support centre as well as Food colleagues in stores. I was aware that this coming together of specialists had been successful within the Co-op before.

I signed up for the Digital masterclass, a half-day training session that helps colleagues whose skills are outside digital understand how the Co-op Digital team works (more information at the end of the post). Richard Sullivan who ran the training introduced me to the benefits of agile ways of working.

Getting support

I’d identified the problem around checking visitors in and out but to fix it I needed expertise from the engineers from Retail IT as well as the Digital team including delivery managers Lee Connnolly and user researcher Rachel Hand.

Together, we started to learn more about the problem.

Putting theory into practice and learning more

Working on this project in an agile way, in a multidisciplinary team was very different to how traditional teams would tackle it. That includes the Risk team I’ve been part of. It was a sharp learning curve.

Here are 3 reasons why:

1.Testing over requirements

I’d been used to handing over a list of requirements to a technology team and asking them to find or create a piece of software that might fix a problem. For Visit, we put paper prototypes in front of store colleagues as soon as we knew enough about the problem. Their feedback helped shape the design meaning the product was tailored to their specific needs rather than it being an off-the-shelf solution.

2.Questions over assumptions

I approached the problem (the process of checking visitors in and out is inefficient), with a solution (so we’ll put software on store tablets to make it better). It seemed such an obvious solution to me (and in the end this is in fact our solution) but the Digital team showed me the dangers of assuming rather than questioning. We did an ‘assumption mapping’ session which helped us see if or where we were making assumptions about the desirability, feasibility of the product. Identifying assumptions reduces risk.

Photograph of a whiteboard with many yellow post it notes of notes arranged across a grid. This is an example of assumption mapping. 

3.Build in team time

I’d never worked in a team where we’d schedule regular time to reflect on our progress and our team health. This is what retrospectives are for. Until now, praise and problems were private – not something a team could be part of together. I didn’t realise how essential I’d begun to consider retros until we had to cancel one.

Progress through collaboration and thinking differently

Despite this being my very first digital product, I feel I can say with confidence that when Visits rolls out to all Food stores later this year, it will solve problems and meet our store colleagues’ needs. This is because the product is design-led. We were never tied to a solution, we changed our minds as we learnt more and our understanding of what store colleagues need improves.  

If you recognise opportunities for operational improvement, no matter which team you’re in, you can speak to Chris Ward, Product manager for Operational Innovation Store. You can also email Richard Sullivan to arrange a place on the Digital masterclass.  

Nick Bullough
Product owner