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