We’ve added user research guides to the design system

We recently added 4 user research guides to our Co-op design system. The guides cover:

  • how to plan and prepare for research as a team
  • how to choose the most appropriate research method, and how to use it
  • how to analyse your findings, turn them into something actionable and how to share with the rest of the team
  • a list of useful research tools

We’re committed to user-centred design. We start small, we test for user value and we work iteratively – research and reacting to feedback is vitally important to us.

But it’s not easy to do good research and by ‘good’ we mean using the appropriate method and ensuring the way we do it is planned, thorough and unbiased.

You need skilled researchers.

Helping teams help themselves

We have a superb small team of researchers at Co-op Digital. We have varying background, skills and strengths which means asking for advice on how to tackle something is always interesting and useful. But we can’t cover all our projects, at all product phases, all the time. There aren’t enough of us.

So in a few cases, we set the direction and encourage teams to do their own research, with us there as support.

Sharing the knowledge

The idea came while I was writing a research strategy for a team working on a particular scope of work. I realised the strategy could be adapted into more of a ‘how to do research at the Co-op’ guide. For years, in an unofficial, internal-channels-only type way, several researchers had been writing guides on things like ‘how to recruit users / gather informed consent / write a survey’. It made sense to pull this useful work together and make it open and available in our design system.

Presenting guidance in this way means that instead of individual researchers writing a strategy for a team now and then, we can give more general advice.We want to make sure people are doing good, useful research in the right way and we can now add value to any digital team by giving them a ‘best practice’ resource.

We’re working on it

As always, the plan is to iterate and add more guidance as we go. We’ve been looking towards the GDS service manual as an excellent, detailed resource for planning research.

As we come across a method that we don’t have a guide for, we’ll write one up. For example, the next time one of our researchers needs to conduct a diary study they’ll write that up.

We know we need to improve how we help people choose the appropriate method so that people don’t just fall back on conducting usability testing in a lab or face-to-face interviews. As Vicki Riley says in her post, matching our research approach to the project is really important.

We’d like your feedback on it too so if you have any, leave a comment.

Simon Hurst
Lead user researcher

From digital design manual to design system

In January 2017 we released our digital design manual. Now, 18 months later, the design manual has evolved into a design system.

Although it’s been live for months, it’s still (and always will be) a work in progress. We’re sharing it now in line with one of our design principles: ‘we design in the open’.

You can see the Co-op Digital design system at coop.co.uk/designsystem

Evolution of the design manual

The aim of the design manual was to help teams release things faster so they could focus on user needs rather than on making basic design decisions. We iterated and added new pages as and when there was a need, for example, we added guidance on forms, guidance on tables and our secondary colour palette.

But a year after its release, we were at a point where more of our digital services were going live, so we revisited the design manual and asked if it could be more useful.

What we learnt from our users

We asked our design, content design and user research community how well they felt the guidance in the design manual was serving its purpose. Feedback was mixed but most people felt that it didn’t quite cover enough.

A workshop made it clear that users wanted:

  • example-driven patterns
  • guidance on when to use specific design and content patterns
  • examples of ‘experimental’ patterns
  • all guidance in one place

Afterwards, we dedicated time to making some major changes to the content as well as the navigation and layout.

Design system – nice for what?

We found lots of excellent examples of design systems in our research but good, solid design systems are good and solid because they’re unique to the organisation or business they belong to – they meet the needs of designers, content designers and researchers who work there.

The Co-op Digital design system includes our:

  • pattern library
  • content style guide
  • guidance on our design thinking
  • design, user research and content design principles
  • tools (front-end and prototyping kits)
  • resources (Sketch files and brand assets)

Most importantly it’s a living document. Like all good design systems, ours will never really be ‘finished’ but it’ll evolve as our teams and services do. Over the past 6 months we’ve established processes that allow our team members to contribute to the system.

We audited our existing design work and looked for similarities and opportunities to create familiarity. We’ve also spent a lot of time building the foundations for a stronger and more collaborative team through workshops, design crits and making sure we design in the open.

Familiarity over consistency

The Co-op is an organisation with very distinct businesses which all need to communicate with Co-op members, customers and users in an appropriate and relevant way. For example, the way we communicate with a customer in a food store is likely to be very different to how we speak to a customer in a funeral home.

So it’s likely that our services might feel different. And that’s ok, as long they feel familiar.

A design system lets us create this familiarity. It should lead to a much more unified experience when they interact with different Co-op services.

Pattern library

We’ve started creating a library of design patterns – this is the most significant addition to our previous guidance. It doesn’t replace our design guidelines, it just pulls out the useful stuff we learnt designers look for when they’re designing a service. 

Each pattern will have:

  • an example, ie, a visual example of the pattern
  • an associated user need
  • design guidance, ie, how you use it
  • accessibility guidance

Our colour palette pattern is a good example.

The library will be the de facto standard for how we display certain types of information.

Anyone at Co-op can contribute by submitting their pattern to the design community. They can do this by filling in a form justifying why users outside their service might benefit from this pattern or, why what they have created is an improvement on a current one.

Evolution of the design system

We want to continuously improve the guidance designers are looking for. To help us do this we’ll speak to more of the external teams that work with us and invite our colleagues in the Brand and Marketing teams to contribute their own guidance. We’ll also put the system to the test with teams as they build more Co-op services.

Watch this space.

Jack Sheppard
Matt Tyas

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

Introducing our user research principles

UR_Principle_6-small

Our user research community of practice has been thinking about how we should approach our work. We decided to produce a set of principles that we believe underpin our purpose and our ways of working.

‘Principles’ are general to the practice of user research, yet specific to those creating them. We want them to work for us in our context, here at the Co-op. They’re specific to us: part of an organisation going through digital transformation, one with stakeholders; business needs; many digital products and services as well as a range of colleague, member and customer users. The principles may not be as applicable where you work if you have an established culture of agile and product thinking.

We want to hear what you think

Various versions have been stuck up on the wall for a while now and colleagues have given us their feedback. We’re now keen to get feedback from the wider community, too.

That includes you.

Leave a comment below, @CoopDigital on Twitter or email Head of User Research James Boardwell to let us know if you think:

  • we’ve missed anything out, or, included something that shouldn’t be there
  • something could be clearer
  • some of these principles aren’t strictly principles

We’d also like to know how valuable working with principles has been for you. Do share any examples you use.

We’re particularly interested in hearing from people who work with disadvantaged or vulnerable users, and / or with data and ethics.

Here’s the latest version.

Focus on what users do, not what they say they’d do

Observing users’ behaviour is the best indicator of what they will do in the future, and the gateway to understanding needs and motivations.

Do a little, often

Frequent research helps teams iterate on a product and validate product decisions more often, which helps promote a user-centred culture.

Give teams the evidence to make better decisions

We research and test the team’s assumptions so that decisions are based on evidence, not guess work.

Involve everyone in research

It promotes empathy and helps teams and stakeholders understand users needs.

Promote accessibility for all

We champion building products and services that are usable across all accessibility needs.

Represent users faithfully

We speak truth to power and if users’ needs are not being met, we say so. This keeps the product teams and the organisation honest.

Undertake the best research we can in any given situation

Sometimes we can’t do user research as we would like. In this instance doing some is better than not doing any.

Respect the privacy and integrity of the user

Our ability to perform our role depends on the trust we have with participants.

 

You can download our user research principles. But keep in mind they may change after feedback.

We hope our principles become ingrained our delivery teams as well as act as gentle reminders for user researchers.

User research community 
Co-op Digital

Designing the research studio at Federation House

In February, we announced that we’re building a user research lab in The Federation. We’ve now finished designing the space, confirmed our technical and furnishing suppliers, and we’re about to start building.

This post is about what we learnt about the needs of our users, and how our learnings informed the Federation Research Studio design.

Speaking to users

The studio will be available to Co-op teams including Digital, Brand and Marketing; Federation tenants and eventually, to external customers too. We spoke to a range of these people to find out about their current lab experiences and needs. We’ve also taken into account lessons learned from previous lab builds and we’ve asked for feedback from across industry too.

Two examples are:

Image of Kate's tweet that asks: Quick poll: in user research labs, what kind of sofa do you prefer? Results of the poll say 19% prefer regular 2-3 seat sofa, 56% prefer corner sofas, 25% say it doesn't make a difference

 

Identifying user needs

In the design, we considered the needs of participants, researchers and observers. Most of these needs weren’t out of the ordinary and match those documented in this post about how to build a great user research lab.

However, we also found a few needs not listed that are important to Co-op and other potential users too. These are:


1.Keeping data safe

User research labs have video and audio equipment to record users’ answers or interactions with what we’re testing. The recordings mean the responses can be shared with the rest of the team and viewed at a later date. In May, the General Data Protection Regulation (GDPR) – a regulation that’s designed to improve privacy around citizen’s data – comes into force, so making sure we keep recordings safe and secure will be a legal obligation.

We’re planning on integrating the lab’s audio visual (A/V) recorder with a media asset management solution. This will allow us to organise and securely store A/V content and, importantly, control and track who’s using it and how. Initially, the solution we choose may be simple, and we’ll iterate on it as we learn how the lab is used. We’ll share more about this in a future post.

2.A remote viewing capability

All good products and services are informed by research and making live user research easily accessible is important. Co-op is a national organisation and colleagues and stakeholders are scattered across the country, so there’s a real need for the lab to include equipment that allows for remote viewing. Having these capabilities will also help solve the ‘problem’ (a very good one to have) of an oversubscribed viewing room.

3.A flexible, multi-purpose space

Co-op teams, like Brand, often run sessions such as focus groups that are more space-needy than the one-on-one research sessions Co-op Digital researchers tend to do.

We need to use technology to make the most of the space we’ve got, so we’ll install cameras and microphones in both the viewing room and the user lounge. This way, the viewing room can be used for research activities that need more space (the tables can be folded way for even more space), and the research can either be viewed from the user lounge or from a remote meeting room. This also means that both rooms could simultaneously be used for research, with teams viewing from a meeting room, even in another building.

4.Suitable for tasks other than research

The Federation tenants expressed the need for a space to produce high-quality videos and podcasts. The lab will be a professionally soundproofed space with excellent A/V capabilities, so it’s not unimaginable that it could be used for this too.

Considering the interiors

Labs aren’t all about the technology. Getting the interior right is important too. Ideally, we want participants, user researchers and observers to feel relaxed and comfortable and the look and feel of the space is a big part of this.

The lab’s interiors will be plain and unbranded. This is to avoid distracting participants, and to ensure external brands can use the space without feeling defined by it. It’s also important that the space is neutral so that people taking part in internal research, ie, Co-op colleagues, don’t feel that they’re being tested by their employer, something that’s come up in previous research sessions.

A comfortable viewing room

Viewing rooms are often smaller and much less loved than user lounges. The more frequently team members and stakeholders watch research live, the better. Participants are generally in and out of the lab within 45 minutes, whereas observers can be in the lab for anything from 3-8 hours at a stretch. For this reason, we’re focusing on making the viewing room as comfortable as possible with dimmable warm-white lights, comfortable chairs, dark grey walls to reduce eye strain, and a large whiteboard wall for analysis and collaboration. It will be a working space.

We’ll use grey matt finishes on all flat surfaces to enhance contrast and avoid glare which will help make sure that the video image quality is the best it can be.

A lab made with users in mind

The building work will start soon and we’re confident we’ve designed the right thing for our various types of user. We’ll share more on the technology we’re using soon.

Kate Towsey
User research operations

Why we run tests and trials

At the beginning of the year I worked on a project with 3 of our Food stores. We were looking at using a third party to replace our current home delivery service. I’m a user researcher so I spoke to colleagues and customers about their experiences with the product we were trying out.

One day, I received an email from one of the store managers asking me to visit his store. He said they’d been having technical difficulties and they’d like some support.

But my job isn’t to provide technical support – it’s to understand why someone needs it.

It dawned on me that this store manager thought the point of putting a new product in his store for a short time was to see how well the team could use it – as if we were examining the team’s ability to fit in around this new thing, rather than seeing how well the new thing met colleague and customer needs. His email suggested he thought trials are a top-down, ‘you-must-use-this-thing’ situation, not something collaborative or something that his team could and should influence.

Setting things straight

Neither tests nor trials are about seeing whether the people using the new thing have the skills or expertise to use it. They’re about finding out whether the new thing is good enough and meets the needs of the people who’ll use it. Both help us make sure that the thing we’re building, or buying in the case of trials, will benefit the business and meet user needs.

When we test

If we’re designing something to solve a problem for colleagues or customers, for example a website to help Food store colleagues find out how to do something in their store quickly and easily, it’s essential we speak to those people and see them use the thing we’re designing as soon as possible. It helps us make sure we build the right thing.

We start with research so that we understand the problem or colleague or customer need; we make assumptions about how we could fix the problem or answer the need, and we build the simplest thing we can. Then we get it in front of users – the people we’re building it for. We make improvements based on their feedback and get a new version back in front them again for more feedback. And so on.

We focus tests on either a specific set of features or specific points of interactions in a service. By testing different things continuously, we begin to understand which features work and which don’t. And when we start to get things right, we invite more people to use it.

When we use trials

Sometimes there’s a product that fits our business needs already on the market so there’s not always a significant benefit in developing our own. Instead, we ask a small number of colleagues and/or customers to try this product so we can see how it fits within the service Co-op wants to provide. If it’s a good fit, we’ll make it available to more colleagues and/ or customers.

A participant’s role is so important

My experience is that many participants don’t understand the purpose of tests and trials. I fear that if they are told by someone at head office to use a thing for x-amount of time, their feedback might not be completely honest. I think we can work harder to help users throughout the organisation understand why we test and trial and the importance of their feedback.

Starting here…

Honest feedback is useful. Sugar-coated feedback isn’t

If your Co-op workplace is chosen to be part of a test or trial, it’s because we want to learn from you, our users. Building or finding the right thing is a conversation. It’s 2-way. Good design is collaborative meaning that you, our users, shape what we build. Everyone – managers, team leaders, assistants – can, and should, influence this.  

All feedback is valuable, even if the feedback is “this new thing you’ve asked us to use makes my work life way more difficult. And it always breaks”. For the Digital team to do our jobs properly we need to be aware of the problems so we can go back and build or buy something that you’ll actually find useful.

Tips for digital teams testing or running trials

Communicate clearly and regularly with the users you’re working with. Be clear about:

  • the purpose of tests and trials in general (maybe link to this post)
  • what you’re testing or trialling with them
  • why you’re testing or trialling ie, the difference this new product could make to the bigger picture
  • how important honest feedback is and the role it’ll play in shaping a product or service
  • that there are no right and wrong answers
  • the anonymity users can expect in any evidence we share – we don’t report back to management about specific users

Better communication will mean we’re all on the same page. And that’ll mean we’ll build better services.

Let us know how we can run tests and trials better in the comments.

Gillian MacDonald
User researcher

We’re building a user research lab

Co-op Digital is building an in-house user research lab on the lower ground floor of The Federation. It will be available to all Co-op teams, the Federation community and, eventually, the wider world.

We’re calling it Fed Lab.

What’s a user research lab?

A user research lab is a physical space. It’s usually 2 rooms: one room that looks like a lounge but with cameras and microphones installed, and another that looks like a regular meeting room but with a very large TV. The ‘lounge’ is for researchers and participants to do research tasks, like co-designing something or doing a task on a website. And the ‘meeting room’, called a viewing room, is where the team sit and watch the research happening live.

Labs help whole teams see first-hand how their designs are working or not working. This way, a team can learn together and work on changing designs and interactions there and then. This fast response to live user research is what makes a lab such an important tool in agile delivery.

Why we’re building a lab now

Co-op Digital’s remit is to create new digital products, services and platforms; pioneer new ways to cooperate online; and help our existing businesses make the most of digital. To do this, we put users and their needs first, and help teams across the Co-op do the same.

Until now, we’ve been using external labs for lab-based user and market research, but we know from past experience that having a dedicated in-house research space significantly ups the ante on how much time teams and stakeholders spend with users.

And we believe the more time we spend with users, the better.

In the long run, the lab will help us offer teams across the Co-op a complete in-house research service. As a result, we’ll be able to build consistency in research across the business, maintain knowledge and build on it in-house, and be more financially efficient and even profitable.

But it’s not just about us. The Federation, is a fast-growing community of like-minded digital businesses and innovators. Fed Lab will give these organisations access to the tools they need to learn more about their users too.

Where we’re up to

We’ve completed the discovery and design phase of the lab, we’ve chosen the technology, and we expect to have the lab up and running in the summer. We’re pioneering a new solution, so everything needs more care and time.  

In building the lab, we’re planning on using cutting-edge, military-grade technology that will not only offer a top-end experience for people in (and out of) the lab, but also support us in maintaining our data privacy standards and help us conform to GDPR.

As the project takes shape, we’ll share much more about the technology and the design. To keep up to date with our progress, subscribe to the Co-op Digital blog. For more information, get in touch with Kate Towsey.

Kate Towsey
User research operations

Matching our research approach to the project

We’ve been drafting our user research principles recently and one idea to come out of the sessions was that:

User researchers shouldn’t fall back on a single research method just because we know it.

It got me thinking about my latest project at Co-op Digital and how interviewing people in a lab may have been easier for us but our insights wouldn’t have been anywhere near as valuable.

My point is: it’s easy to stick with a research method because it’s familiar or we feel confident using it, but different projects demand different approaches and user researchers must think carefully about choosing the most suitable one.

Matching the research approach to the project

I’ve been working on a ‘later life planning’ team, looking at how we can help people plan for the future.

We wanted to have conversations with people around:

  • what planning for the future means in practice
  • their hopes for the future
  • any plans they have in place

But talking about wills, funerals, loss and what might happen to us in the future can be scary and emotional – so much so that it’s a conversation lots of people avoid having. I quickly realised that our research approach needed to be carefully and sensitively planned.

We use research labs regularly and they can be brilliant. They help the whole team witness the research first-hand and the controlled environment allows the researcher to focus on the interview rather than on logistics.

But labs can be quite clinical.

The white walls and huge two-way mirror don’t foster a comfortable, relaxed environment. I wanted the people we spoke to to be comfortable. This is something that needed to be more on their terms.

Researching in context

Photograph of hands cupping a mug at a dining table. Glasses in shot as well as a plate of chocolate biscuits.Apart from putting them at ease, the decision to visit people in their homes came from the desire to understand a wider context. What environment are people in when they have these conversations and make these decisions?

And home visits were great. Talking to someone surrounded by photos of their grandchildren, or with their pets bouncing around, helped us to understand what’s really important to them. By allowing us to see a little bit of how they live, our research participants gave us insights that we might not have got if we’d spoken over the phone or they’d talked to us in a lab.

For example, we saw:

  1. People struggling to find certain documents, despite them telling us that everything was in one place. This indicates that they might not have their plans as organised as they’d made out. We’re less likely to have found this out over the phone or in a lab.
  2. People’s expressions and body language while they had candid conversations with loved ones. One valuable insight was seeing the sense of urgency on a wife’s face when she spoke about needing to replace her husband’s expired life assurance plan. Her expression gave us an idea of what an important and worrying issue this was for her. Their body language show us how much importance each of them placed on different parts of their existing plan.  

Seeing things first-hand was a good reminder that people’s lives are messy. Anything we design or build needs to consider this.

Challenges with timing and practicalities

It took a long time to plan and prepare for the home visits. The logistics of travelling, getting lost, finding somewhere to park and finding the right spot to put the GoPro so we could record the interview was sometimes tricky. And by the time we’d introduced ourselves, talked through consent, set up the GoPro, things felt quite rushed. Next time, I’ll allocate time for these things or chat over the phone before the interview to establish a relationship and cover the basics in advance.

It’s tricky to involve the whole team

I’ve found it’s easier to get the whole team involved when we’re speaking to people in the lab – it’s one place, one day. But we carried out home visits over 2 weeks making it more difficult to pin everyone down.

We discussed who we wanted to speak to and what we’d like to find out as a team beforehand. This then fed into the plan and discussion guide. Product manager Sophia Ridge and designer Matt Tyas were able to come to the various interviews but making sure the whole team heard the voice of the interviewee and got the same insight was difficult.

We all came together to watch the home visit videos and I asked everyone to take notes as they would in a lab setting. I’d hoped we’d sort the findings and uncover themes and insights together. But 2 videos in, people were pulled onto other work. Next time, I’ll take the team out of our working space and ask them to leave their laptops behind.

Research community, how do you do it?

We’d be interested to hear how and why you’ve chosen to step outside the lab for different projects, and whether you think you got more useful insight from it. Leave a comment below.

Vicki Riley
User researcher

Vicki Riley on user research at Co-op Digital

We’re recruiting user researchers.

If you want to help digital teams build the right thing, and if learning about how people behave and why sounds interesting, you might be a good fit. Have a look our job description for more details.

Our user research team come from really varied backgrounds. Here’s Vicki’s story.

(Transcript) Vicki Riley: I’ve been a user researcher for just coming up to a year now, I’ve been at the Co-op for 2 years. Originally I worked on the analytics and optimisation team. That involved looking at the the data so Google Analytics to find out what people were doing on our websites. But being a user research now I can really delve into why people are behaving in a certain way and shape the products that we’re building based on that.

User research is about understanding the behaviour of people. So rather than asking people what they would do we would prefer to observe them. So with colleagues that could involve shadowing in-store, spend a day in the life of a colleague who works in one of our food stores to really get to the bottom of what they’re trying to do, what their pain points are and shape what we’re building based on what we’re seeing rather than just what we’re hearing.

A huge part of user research is kind of getting out of the building, going out to the places that our users are working or spending time. There are a lot of assumptions in Angel Square or in any business there are assumptions and without speaking to the people who use your services or use your products you’ll never really find out what’s happening, you’ll never really get to the bottom of it.

I love working with designers and interaction designers, content designers. They’re really involved in the research and they bring a different perspective to things. They have different backgrounds, different experiences, different knowledge so it
really helps to have a diverse group of people doing the research analysing the
research.

I’m learning something new pretty much every week because I’m working on different teams and moving around a lot learning from people who’ve done user research but 10, 20 years so for my personal development it’s been brilliant this last year I’ve learned more than I have in my entire career.

I’ve wanted to work at the Co-op for a long time ever since I’ve finished University. They’re a company that really makes a difference in the community and I think user research has an opportunity to shape that, to shape what we do in the future.

Vicki Riley
User researcher

 

Simon Hurst: life as a user researcher at Co-op Digital

(Transcript) Simon Hurst: I’m Simon Hurst, I’m a user researcher here at the Co-op working on Membership.

So, Membership is key to the Co-op, it’s a lot what the Co-op is. So my role entails sort of challenging assumptions that the business might have about customers or about members. So it’s understanding how people want to engage with the Co-op in the 21st century. I’m a fairly experienced user researcher now so I’ve been through digital transformation in government. I was originally first worked on the first Department for Work and Pensions service that went live.

The ability to go and do that all over again with Co-op Digital and to help a lot of
people who were coming to user research quite new and to help them along. So I think one of the best parts of my job is mentoring people as well, so I’m sort of mentoring someone at the minute and I’ve just trained someone as a user research.

So being able to share sort of things I’ve learned as user researcher with other people and equally we’ve got a good mix of people from different digital backgrounds. So even amongst the community of user researchers, there’s people with different skill sets to me I can learn from as well. So it’s just a really good mix. And stuff we’re trying to do is genuinely trying to improve people’s lives and help people.

The things I’m looking forward to right now are really starting to influence more and more how much user research is listened to, so really getting it properly embedded now. So we’ve got the roots there we now need to build on that and so it’s making sort of links in the wider Co-op to sort of share user research findings as opposed to sort of people directly on the product teams. And trying to find other user researchers to come and join us, who can join in with that and helping to develop user researchers here.

Co-op was the only other job I’ve ever applied for apart from government in 20 years, since I left college, so I have no plans on going anywhere so it’s it’s really nailing it here I think is what I want to do.

Simon Hurst
User researcher

Find out about opportunities to work with us.