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

Lesson learnt: test in context as soon as possible

I’m holding my hands up and admitting my team recently made a mistake. We’re guilty of using high-tech laptops to build software intended to run on far less powerful devices.

Testing in context is something all digital teams should do automatically. But while chatting to a couple of other software engineers, I learnt that forgetting to do this is a common developer sin. Or at least, it’s more common than it should be.

I hope that by writing this post it’ll help keep it in the forefront of people’s minds.

What we were working on

I’m part of the Membership team. Recently, we wanted to find out if members would find it useful to check their rewards balance at the start of a shopping trip, so we’ve been building a prototype that members can use in stores.

Where we fell down

The prototype we were building was difficult to run on the device we’d be testing it on, ie, the small Android tablets in stores. The tablets weren’t chosen for their performance, they were chosen so we can keep the cost down while we’re still experimenting. To make the prototype run faster, we’d been using the browser on my laptop while we we doing the development work and showing demos to the team. In other words, we’d prioritised speed over accuracy.

A few days after spinning up the prototype, we tried it on one of the tablets. It didn’t work in the same way. We’d wanted to get it into the hands of real users as soon as possible so we could check our assumptions and find out how well it met user needs so by this point we’d booked in some user testing in store. Unfortunately, we couldn’t fix it in time.

Not a disaster, just a delay

Working in an agile way allows us to overlook relatively small things and make little mistakes like this. The beauty of agile means we’re never going to spend an outrageous amount of time or money correcting mega problems. For our team, we had to delay the user testing which was frustrating (we should’ve known better), but it wasn’t a disaster.

Easy to fix

We spent a day accounting for the differences between the Android tablet and the browser on my machine. We used a service called ngrok.io so the tablet could use the website running on my laptop and we could develop against the low-powered device. This way we could test over a representative 3G network. It’s what we should have done all along.

But easy to avoid too

As I said, testing prototypes in context or in an environment as close to reality as possible is basic but sometimes, for whatever reason, there’ll be occasions when we trip up.

To avoid this:

  • keep in mind the device, or types of devices, your users will be using your product or service on, both before and after you begin building (this is the big one, obviously)
  • involve your quality assurance testers (QAs) as early and as frequently as possible
  • run the software on realistic devices as early and as often as possible…
  • …but never assume that emulating a device in a browser will be exactly the same as it would on a device

We’ve learnt our lesson. Let this be a reminder to you!

Paul D’Ambra
Software engineer

How to run a design crit and why they’re important

One of our design principles is ‘design in the open’. This means we choose to be collaborative, we show our early design work and invite feedback. Holding design critiques, or ‘crits’, is a useful way to do this.

Done well, they:

  • improve our designs
  • improve collaboration between designers and between disciplines
  • offer a different perspective
  • boost morale and strengthen communities of practice
  • show the decisions behind the design

I recently asked on Twitter if a post on ‘how to run crits and how to get the most out of them’ would be useful. People said yes.

So here it is.

What’s the point?

The purpose of a design crit is to give a designer feedback, to evaluate an idea and identify possible changes or different approaches. It’s not to figure out a solution there and then.

Crits can focus on (but definitely aren’t limited to) things like:

  • interaction of specific page elements
  • a specific user flow
  • the emotion a visual style portrays
  • competitor services

Who to invite

Having the right people there is essential. The temptation might be to fill the room with designers but inviting people from different disciplines will make sure you hear a range of perspectives. In most cases it’s good to start with content designers and user researchers because their work is so intrinsically linked with design.

But they’re not the only ones who really understand how design works. I’d be hesitant to blanket call out other disciplines, instead I’d say it’s up to the person whose work is being critiqued to use their judgement and invite individuals they think would offer valuable input into the specific thing they’re sharing.

A golden rule is to invite the maximum number of people you’d be comfortable hosting a dinner party for – a group big enough to encourage discussion but not so big things are unmanageable.

It’s best when the crit is led by the designer who did the work so they can explain the decisions they made around their design. It also means they’re there to receive feedback first-hand rather than hear chinese whispers. However, if that designer isn’t comfortable leading the session, someone else can facilitate and steer discussions while the designer makes notes on the feedback.  

When to run a crit

Run them often at the start of a project then less frequently as the project goes on. Early crits will most likely focus on top-level ideas. When you’re further along in a project, it’s useful to hold crits to look at particular issues with a view to making specific decisions.

They’re also beneficial before project milestones, for example, before it’s too late to iterate features, flows or ideas.

Actually running a crit

  1. Start the session by identifying the aim(s) of the discussion. For example, we want to:
    • improve the registration flow
    • understand if the design is easy to follow
    • assess whether the design meets the project goals
  2. Point out any constraints, blockers and considerations. For example:
    • any content that can’t be changed – this might be due to legal or policy restraints, or deadlines
    • anything that’s already been built and will take more work to change
  3. Show the design. At this point it’s useful to:
    • explain reasoning or constraints of that specific thing. For example, your navigation choice might need to be consistent with someone else’s work or all the content has been agreed and signed off
    • show alternative designs if you have any
  4. Facilitate discussion by:
    • encouraging the group to share 1 or 2 pieces of feedback. Give the option to do this on post-its for anyone not comfortable giving verbal feedback
    • prompting the quieter people so that nobody dominates the discussion
  5. Collect feedback in a format you can share. This could be Trello.
  6. Share feedback and next steps to the wider group while allowing people to give more – not everyone will be comfortable in the session.

One rule: be kind

Sharing work and opening it up to criticism can be a terrifying prospect. Here are a few ways we can make it less daunting and much more productive for everyone.

When sharing your work you must remember the golden rule: you are not your design.

When critiquing work remember to:

Listen. Then speak thoughtfully.

Crits should be a safe space for everyone to share their thoughts. Listen carefully. If you want to respond, consider whether your thoughts are relevant or whether they’ll progress the discussion.

Ask questions

Rather than stating “X is bad” or “Y doesn’t make sense”, ask questions about the reason behind a design decision. Yes, “what’s the reason for…” is kinder than “that’s rubbish”, but it’s also more useful for the session – if you were wondering about something, chances are the rest of the group are too.

State what’s fact, opinion or assumptions

Everything you say in a crit is your point of view but it’s worth clarifying if something is your personal preference or opinion, or whether it’s backed up by research. “My assumption is that…” is just as valuable in a crit than “user research shows that…”. Both are better than “that should be green/bigger/bolder.”

How do you do it?

Designing collaboratively and in the open is important and design crits help us do that. There’s no set method but this is one that has worked for me and teams I’ve worked with.

Do you place importance on critiques and design reviews in your organisation? How do they work? All crit-related tips and tricks are welcome in the comments.

Jack Sheppard
Lead interaction designer

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

A discovery into digital Membership offers

Last year we tested out an app for members. The app we built allowed members to:

  • scan their ‘digitised’ membership card
  • check their reward balance on demand
  • choose a local cause for their 1% reward to go to

Listening to members

The feedback we got showed that people like the idea of having something on their phone rather than carrying a card around with them. However, lots of our stores don’t have tills that could scan the app.

We also realised that the features we’d included in the alpha weren’t compelling enough to launch as it was. However, feedback told us that personalised offers are something members really care about, and we felt we could improve them if we digitised them. At the moment, members receive their personalised offers on paper from the till, just before their receipt is printed. This means that to take advantage of money off they have to take, keep, bring back, and then remember to use the paper coupon next time they shop with us.

How can we help members benefit?

We wanted to find out if it’s possible to give members choice and control over the offers they get – this might be through an app or on the Membership website. We thought about how we could show members a pool of offers and then load the ones that appeal to them onto their physical membership card so they could redeem them at any Co-op store.

We worked with the Personalisation team in Food who look at members’ buying habits and match offers to members. Together, we’ve done a discovery to find out what’s possible with digital offers.

Asking questions

We looked at:

  • what our competitors are doing and where we think we can do better
  • if we made offers digital, how many offers would we give
  • how frequently the offers would change
  • if there’s a type of offer that works best in a digital format
  • who’d run the upkeep

Working quickly

Then we built a quick proof of concept, for what we’re calling a functional test. The page showed a group of offers and allowed members to choose 4 to load onto their membership card and redeem on the tills in the test lab in our head office.

It looked like this:

Screen shot of the page we mocked up. It shows a group of offers and allows members to choose 4 to load onto their membership card

This let us prove quickly and cheaply that we can build this for all members, on a website or through an app. The Membership team had already done a lot of research into digital offers in the past, so we were confident that this was something that our members would want and understand.

From a technical point of view, it’s looking promising

With a bit of tweaking, we expect the system that powers coupons at tills will also work with digital offers. It’ll be relatively straightforward to build the parts that the member interacts with, and it should be possible without needing to update our tills.

Testing our commercial assumptions

The more complicated part is figuring out which offers would be popular in a digital format. At the moment, we give paper coupons for things like dairy, bread and meat but we think that if we had the capability to switch offers in and out, offers on these things may get repetitive. So we’d look at giving offers on some smaller groups of products.

We’ll keep working in partnership with the Food team on this, but it might take a bit more time to make good commercial decisions.

What’s next?

We want to test this out with real members to prove if there’s a real appetite to use and keep using digital personalised offers.

To help us measure how many people want it, and help us build a pool of members to go to when we’re ready to test, we put a banner on the Membership website last week. So far, 21% of members who’ve seen it have indicated they’d like to help.

All being well, we’ll launch the first public trial on the Membership website and in an app this summer.

Joel Godfrey
Product manager

Pressing for progress at Co-op Digital

Yesterday was International Women’s Day. Throughout the day we shared stories on Twitter about some of the people at Co-op Digital who help us be our best selves. These people inspire, empower, encourage and elevate those around them. They help level the playing field so we hear a diverse range of voices.

 

Co-op Digital champions diversity full stop. We mention gender diversity specifically in this post because it’s International Women’s Day.

The importance of privacy and safety on social media

On Monday, the Social team held an event for 100 young people who attend Co-op Academies in Greater Manchester. The students were 14 to 16 years old and they’ll soon be leaving school and thinking about what’s next. The aim of the talk was to raise awareness about:

  • social media privacy
  • online safety
  • social media and your career
  • presenting yourself online

Here’s what happened.

Privacy and safety

The focus of my talk was on privacy and safety on social media networks. I warned that if we’re not careful, the range of data we disclose across various social platforms could easily be pieced together and someone with malicious intent they could steal your identity.

The takeaway points were:

  1. Make sure you know who can see your social media interactions. Some networks, like Twitter, are ‘open’ and they’re designed for networking and engaging with people you don’t necessarily know. Facebook and Snapchat are ‘closed’ and reserved for engaging with people you know personally.
  2. Create strong passwords for all your accounts and set up 2-factor authentication on your recovery email accounts. MUO gives decent guidance on this.
  3. Don’t share photos with anyone you don’t trust. Although Snapchat photos appear to ‘disappear’ they can be screen-grabbed and saved. They also exist for a time in Snapchat’s servers and they can be retrieved by the police.

Ian in front of young people with microphone presenting.

Social media and your career

Matt Eyre helps recruit people into Co-op Digital. He shared his tips on how to use social media to find your first, or your next, job. His advice is to:

  1. Have different accounts for personal and professional purposes.
  2. Check your privacy settings on all accounts.
  3. Keep your professional profiles up-to-date.
  4. Be proactive if you’re interested in working at a particular place. Get in touch with them.

Photograph of Matt Eyre reading from prompt sheet in front of students.

How you present yourself online

Choosing how we present ourselves by controlling what we share is really important. It’s about creating an image of ourselves to people we might not have met which can be useful when we’re looking for new jobs. Catherine Storey is our Social media content planning manager at Co-op Digital. She landed her last few jobs, including this one, through her careful management of personal social media accounts.

Here are her tips:

  1. Check who can see which parts of your profile on every social media account you have. It’s ok to show you have a social life, but make sure you know who can see it and the impression you might leave them with.
  2. Your Twitter handle is searchable and it says a lot about you. It’s an online representation of you, your ‘digital name’ if you like. Where possible, your digital name should be the same across each social network which helps build your online identity.
  3. Choose what you engage with carefully. When you tweet; update your status; post a photo; send a video, you expect people to see these things and it’s easy to be mindful of your output. However, when you ‘like’ a tweet, a photo or a status or leave a comment, your engagement is more passive and it’s easier to overlook the fact that these things can reflect on you too.

Photograph of Cat Storey presenting in from of students.

Aaron’s story

To finish, Aaron Omotosho talked about his (paid) work experience at Co-op Digital. Aaron spoke about the time he spent with product and service teams within Co-op Digital and his time after this completing a coding course at Northcoders. We also heard from Jonny Rathbone from Northcoders who spoke encouragingly about the opportunities out there for young people in the digital sector.

photograph of Aaron presenting in front of students.

We hope to hold more events like this in the future. It’s all part of our work to encourage a thriving tech sector in the north-west.

Ian Ferguson
Community manager