Building trust in the Co-op design system through weekly hacks

The Co-op design system includes design files – and the coded versions of those files – that help us build Co-op’s digital services quickly and to a good standard.
 

It exists so we can create familiarity across Co‑op products and services, from arranging a funeral to looking up membership offers. Familiarity means that interactions work in the same way and each service feels like it belongs to the Co-op. However, because of our wide range of audiences and user needs they don’t have to be exactly the same. 

Our earlier blog post, Developing visual design across Co-op products and servicesgives a good overview of why this is important. 

How it’s been working so far

For the most part, the design system has done a job good at helping us create familiarity. Every Co-op digital product and service either directly uses the design system’s code, or in the case of our apps its design language. We encourage designers to design for the user needs associated with the specific project they’re working on, and then if we think that part of the design would be useful in another product (such as the format we display a product in), then we’ll add it to the design system.

Designers take ownership of a design pattern. They find out if that pattern is used anywhere else and therefore if there’s a good case to design and build a single version to add to the design system.  

But we don’t have a dedicated design system team

The design system doesn’t have a product team that constantly works on it. It’s a side project that (like all side projects before it) can move slowly, especially against everyone else’s project work. 

Project work quite rightly pushed the boundaries of the design system and in some cases found problems in the fundamental styles that needed to be fixed.  

We found the design system was struggling to keep up. 

Design system debt

Designers were losing trust in the design system for 2 reasons: 

  1. The code was up to date but project teams didn’t want to update as it was a big job to do the update and test everything. Because of this they were writing custom code to try to keep up. 
  2. Design libraries were getting out of sync and people began to create their own versions of the base files.  

But even though our artefacts were getting messy – our products retained a decent level of consistency. We’re lucky at Co-op Digital because we have a collaborative culture so we talk to each other a lot, but we knew that all the extra collaboration, custom code and question asking could be avoided. 

We needed a better way of managing our code

There wasn’t much wrong with the baseline design system – what we call the foundations. It was how we create and maintain and release our code that was the problem. 

The front-end community of practice came up with a solution.

Firstly, we reorganised the code. We’ve split everything into separate files that designers from different projects can just update ‘buttons’ or ‘typography’. We’ve also moved those files into the design system so we only have one source of truth. 

A designer or front-end engineer can now edit a design system component in that single source of truth. Then using a tool called lerna.js this is published as a separate package to NPM.

This means although we have one place to work on and maintain our design system – it’s easy for projects using the system to just use what they need. Some projects only use foundations and some like Digital offers only use a small subset of the foundations and have written custom code to push the boundaries of design toward something more playful. This feels like the perfect balance. The right solution for users – but only the code they need is downloaded to their device.

We’ve introduced design system hacks 

Every week, we bring together a group of designers, content designers and front-end engineers to work through a design pattern: from creating the specification and documentation. This manifests as the finished Sketch library symbol. We build the pattern into the system’s codebase and release it. 

photograph of a design system hack

This is good because we’re: 

  • sharing knowledge on how to contribute 
  • all contributing and collaborating 
  • all learning about each other’s disciplines 
  • keeping the design system up to date  

It also means that we carve out time to actually do the work. In the past this wasn’t happening because when you go back to the day to day pressures of your project – the design system is easy to push to one side. 

The Co-op design system will never be ‘finished’ – it’ll continue to be led by the projects across the organisation. We’ll just be regularly dedicating time for its maintenance from now on.

Matt Tyas
Principal designer

Co-operate: why we prioritised ‘What’s happening’

Co-op is a commercial business and our profits go back into our communities. Our mission is ‘Stronger Co-op, stronger communities’. Earlier this year we wrote a post introducing Co-operate, an online platform aimed at bringing communities closer together. Co-operate will host a ‘suite’ of connected products that make it easier for organisers and volunteers to make things happen in their local community.

What’s happening‘ – a product that lists events and activities that benefit Stretford – is the first product in the suite that we’ve built. This post is about how and why we prioritised this one.

Screen Shot 2019-10-31 at 09.45.26

Understanding the problems

At the start of the year, me and user researcher Simon Hurst gathered, reviewed, grouped and analysed the previous research from agencies, our own Digital Product Research team and other Co-op teams. 

It was clear that if someone wants to make something happen in their community, they need to overcome at least one – often many – of these problems:

  1. Fund raising. 
  2. Recruiting volunteers.
  3. Promotion and raising awareness. 
  4. Finding a location or venue. 
  5. Finding, getting or buying equipment.
  6. Communicating with and co-ordinating volunteers or attendees.

Usually, a digital delivery team would look at all of these problems and use prioritisation techniques to figure out where they could deliver the most value, most easily, before working their way down a list of stories. 

But we didn’t. 

We know there are good digital and non-digital services that adequately solve some of these problems. For example, organisers use Facebook and physical message boards to promote events, and they communicate with their volunteers through Whatsapp groups. But those services aren’t connected, which means users are having to navigate multiple services to make their community event happen.

We knew that if we only tackled one of those problems, our product wouldn’t offer communities anything they couldn’t get from better established ones – we’d actually become part of the problem.

Our over-arching hypothesis

We formed an over-arching hypothesis that has helped frame our strategy for the first 12 to 18 months:

A variety of unconnected digital tools and services aimed at helping people make things happen in their local communities already exist. We believe that offering a range of connected products will make it easier for people to organise and participate in things that benefit their community. We’ll know this is true if people use 2 or more Co-operate products.

Why an events listing is our first Co-operate product

Despite the fact that another place to list events didn’t address the most urgent user need, we prioritised work on Co-operate’s events listing product What’s happening for several reasons:

1.Broad appeal means more value added

What’s happening brings a range of events and activities into one place and we knew that most members of the community would find something of interest to them – it could be a book club or health walk, a martial arts class or knitting group. Starting with What’s happening felt sensible – we knew it would create a buzz because it’s useful to so many organisers and potential attendees. 

screen grab of the stretford what's happening page. shows 6 events.

2.Good for galvanising a new team (and for satisfying stakeholders)

There had been 18 months of stop/start research into communities and deliberation about whether to continue before our current team became involved with the project. Because the Co-op is synonymous with communities, our stakeholders were investing a lot of trust in us to deliver. 

Whilst our natural instinct as a product team is to see user problems for ourselves, it felt wasteful to start again and leap back into another discovery. In the weeks it would have taken for us to complete another discovery, we pulled together as a team and designed prototypes based on what we’d picked up from the research done before. The fact we hadn’t been involved in the initial research perhaps helped us move more quickly because we were less precious about it – we were just desperate to get something into users’ hands and see where we could add value. 

It worked out well for us because we learnt a lot, quickly; the users in Stretford, and the stakeholders. 

3.Technically, it’s relatively simple

From an engineering point of view, this isn’t a challenging product which meant we could design and build something rapidly, get it into people’s hands in Stretford, listen, observe and make improvements frequently and quickly.

4.Build it once, reuse it loads

What’s happening is essentially a searchable, filterable list – a format that we think could ease some of the other problems we’ve seen too. For example, the build could help make it easier to find community spaces in your area; equipment you can borrow; community groups to join or volunteering opportunities. Building this now means it’s likely to speed up other products we build because we’ll reuse and repurpose it and hook in different content.

Thinking ahead and prioritising accordingly

Balancing and satisfying user needs and commercial needs is our top priority in Co-op Digital. But in Co-operate’s case, it was more efficient for us to lay some groundwork first. Choosing to focus on What’s happening as the first product meant we could move quickly and boost team and stakeholder morale, and thinking ahead about what would be sensible and beneficial to us in the future influenced what we built first. Every project is different and has a different backstory, but these were the right product decisions for this product. 

What’s happening with What’s happening

At the moment What’s happening covers 4 communities (Bollington, Sale, Urmston and Stretford) but we’ll soon cover the whole of Trafford. We’re experimenting with ways to measure its impact – for example, is there an increase in participant numbers at the events we feature? This is the common challenge of tracking people as they move from the digital to the physical world. But we like a challenge.

We’re continuously iterating the product in response to user feedback. If you have some for us, use the ‘share your feedback’ link at the bottom of each community page in What’s happening.

Ben Rieveley
Product lead

Service mapping to make friends and influence stakeholders

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

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

Here’s why.

You build a shared understanding

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

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

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

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

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

It’s a democratic way to prioritise problems

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

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

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

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

Service mapping helps you tell the team’s story

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

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

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

It highlights the challenging conversations so you can have them early

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

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

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

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

Service mapping to show the money

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

It encourages conversation and collaboration

We’ve found service maps help to:

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

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

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

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

Developing visual design across Co-op products and services

The Co-op Digital Design team has recently started to work on products and services that give us the opportunity to develop our visual design. This post is about why that’s important for Co-op as an organisation, and what we’ve done so far.   

Familiarity across functional and visual design

Screen Shot 2019-06-16 at 11.05.40

The image shows the difference between functional and visual design. Guardian – our service which helps Co-op Funeralcare colleagues arrange funerals – falls very much under ‘practical need’, whereas the design for our digital offers for members appeals to people’s emotions.

Up until now, the aim of most of our work has been to give time back to colleagues so they can spend more time with customers and less time on admin. How do I, Guardian and Shifts are all examples of our functional, colleague-facing design work.

As we’ve progressed with that, we’ve created components and guidelines and we’ve begun documenting them in our design system. Although it’s still work in progress, teams throughout the Co-op now refer to and use the design system and as a result, we’re creating a much more unified experience when people interact with Co-op services in our different business areas.

However, more recently the Design team’s work has involved designing customer-facing products and services. When it comes to products and services like a convenience food store, customers have a choice about which one to use, and this is why engaging with them on a more emotional level is essential.

We’re now looking to create familiarity in a visual sense too.

‘Good’ visual design is hard to define

Appealing to a customer’s ‘emotional motivations’ means we want our designs to be pleasing to them aesthetically. But figuring out why something is pleasing is hard because ‘good’ is subjective.

Although there isn’t a formula for success, good visual design considers:  

  • imagery – using good quality imagery in the right place, at the right time gives hints, cues and can stimulate interest
  • typography – the number of type sizes and the contrast between them helps readability and reduces visual noise
  • colour – using it well emphasises content and helps create pace and visual interest
  • composition – where each element is placed and the space around it creates rhythm and hierarchies, and using plenty of white space improves readability
  • shape and pattern – can group or emphasise content, or add personality to layouts

Good design depends very much on context too. At the Co-op, with many different business areas to consider, creating familiarity so customers know what to expect is ‘good’ visual design. It makes our designs more accessible on a cognitive level and makes using our products and services enjoyable rather than disconnected and jarring.

Developing our visual design – our progress so far

We started by holding a workshop for Co-op Digital designers.

We stuck some of the visual design for the projects we’re working on up on the wall, plus the ideas put forward by Lucky Generals – the agency Co-op is working with. Seeing similarities and differences between everything in paper form was a starting point to discuss what works and what needs more work.

We sketched out and mocked up ideas related to anything we’d seen up on the wall – at this stage ideas didn’t have to relate to a specific product or service. 

photograph of the sketches from the first workshop with designers across Co-op Digital

Then we dot voted on which concepts we wanted to develop further.

The photo below show our visual exploration up on walls. The ideas are organised chronologically to show our progression.

3_walls

Involving stakeholders

At this point we had designs that were working well visually. They were bold and simple without being simplistic. When we had a collection of ideas we felt – after a little more development – had the potential to be rolled out, we invited stakeholders from Co-op Food, Insurance and Brand to come and see them.

We weren’t asking for new ideas, we were asking for feedback on the ones we’d curated. We asked for comments on post its.

photograph of colleagues from food, insurance and brand were asked to comment on the visual design exploration work

Applying new visual design elements to old work and new

Since then, designers across many projects and in many parts of the business have been starting to tweak – and in some cases overhaul – the visual design. Some of the examples below like the Co-op Health page and digital offers are live but others are mock ups.

Coop.co.uk homepage

The image below shows a possible new design of the coop.co.uk homepage. We’ve used cropped ‘squircles’ (square circles ;-p) to highlight and group content. (By Tony Carberry, Michael Chadwick, Gail Mellows, Sam Sheriston, Matt Tyas and Katherine Wastell). 

image shows possible new design of the coop.co.uk home page uses cropped 'squircles to highlight and group content.

Co-operate

The image below shows our visual exploration for the Co-operate platform which includes experimenting with hand drawn marks. (By Katrina Currie and Katherine Wastell).

screen shot of Visual exploration for the Co-operate platform includes experimenting with the use of hand drawn marks

Digital offers for members

The image below shows the new visual design for the offers service that went live 28 May. The service lets members choose and manage selected food offers digitally. Kyle Fyffe, Asher Khan and Louise Nicholas used colour playfully and when a member picks an offer, the interaction is animated.

7_offers

Co-op Health

The image below shows a live page on coop.co.uk which supports the Co-op Health app. The visual design balances functional design (download the app) and visual marketing-based content. Cropped squircles and part of the app badge form the background that content is layered on. (By Tom Adams, Michael Chadwick, Gail Mellows and Joanne Schofield).

8_health

‘It’s what we do’ page

The image below shows a new design for the ‘It’s what we do’ area on coop.co.uk which isn’t live yet. (By Tony Carberry, Michael Chadwick, Gail Mellows, Sam Sheriston, Matt Tyas and Katherine Wastell). 

9_whatwedo

Sustainability page

The image below shows a new design for one of the environment pages on coop.co.uk which isn’t live yet. (By Tony Carberry, Michael Chadwick, Gail Mellows, Sam Sheriston, Matt Tyas and Katherine Wastell). 

10_sustainability

Applying familiar design

We’ve made a really strong start but it’ll take time to understand how the visual design is working for our users in live products and services. Just as we do with our functional design, we’ll iterate and build on our direction. Once we know what works well, we’ll document it in our design system.

Gail Mellows
Lead visual designer

What we learnt from Jared Spool

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

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

We learnt a lot from him.

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

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

Experience design: all the moments, all the gaps

My big take away from the talk was this quote:

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

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

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

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

Lucy Tallon, principal designer

Demonstrating difficulty is worthwhile

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

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

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

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

Nate Langley, principal designer

Context is where design happens

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

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

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

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

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

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

Joanne Schofield, lead content designer

From ‘unconsciously incompetent’ to ‘unconsciously competent’

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

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

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

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

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

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

James Rice, lead designer

Changing the behaviour of others… with our thoughts

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

Screenshot_20190531_104922_com.instagram.android

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

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

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

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

Katherine Wastell, Head of Design

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

Co-op health: running a design sprint across disciplines

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

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

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

Trying out a 5-day design sprint

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

Design sprint: booking medical appointments

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

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

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

Day 1: Defining the challenge

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

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

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

Day 2: Sketching ideas

photo of team sketching on day 2

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

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

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

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

Day 3: Choosing and idea and storyboarding

photo of storyboards - lots of post it notes

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

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

Settling on one idea

photo of the chosen idea's storyboard

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

Day 4: Prototyping

photograph of 4 of the team prototyping

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

These images show how reminders might work in the app.

screenshot of the reminder in the app prototype

Day 5: Getting feedback from users

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

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

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

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

What’s next

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

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

Lucy Tallon
User researcher

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

Using ‘sacrificial concepts’ to explore the direction of a product

Yesterday, the design team held a show and tell to discuss 2 questions:

  1. What is design?
  2. Why should you care?

Everyone was welcome but if you couldn’t make it, we’re writing up some of the examples from different areas of design that we talked about. We’ll post them on the blog this week. They’ll be aimed at Co-op colleagues whose expertise are in something other than a digital discipline.

First up: product exploration in the digital offers team.

Exploring the desirability, feasibility and viability of digital offers for members

In September last year we posted an update about our work around digital offers. In summary, we want to create personalised, paper-free offers for Co-op members. We think it will save money for them and create value for the Co-op.

Start somewhere: the format we tried first

We allowed a trial group of 6000 members to choose and use digital offers. Every Monday for 6 weeks, each of these members received 8 personalised offers based on their transaction history. Using our website or app, they could choose to add 2 of those 8 offers to their membership card so that when they swiped their membership card at the till, the offers were applied to their shopping.

At this point, we’d established that giving members digital offers in this way was technically possible which was great news. However, we didn’t know whether giving members a choice of 2 offers from 8, once a week, on a Monday was best for them and/ or good for the business. Would choosing 1 offer from 4 be better for them? For us? How about new offers every 2 weeks? How could we give members an enjoyable experience that would keep members using offers?

Ultimately, we wanted to increase their visits to Co-op food stores and nudge them to consider products that they might normally purchase from another retailer.

Our next piece of work was to find out how we might do this.

Exploring potential product directions through ‘sacrificial concepts’

We looked at the different ways we could give members personalised offers that could cultivate continued, enjoyable use.

‘Sacrificial concepts’, a method developed by design company IDEO, helped us gain insight into customers’ beliefs and behaviour. Here’s an example of a handful of sacrificial concepts that we put in front of a small group of members we visited in their own homes.

slide shows a range of sketches or what we refer to as 'sacrificial concepts'

They’re sketches of ideas.

They’re not presented in the context of a computer or device screen as we might do with designs that already have a substantial amount of research behind them. They’re just ideas, they’re abstract and open to interpretation because we put them in front of potential users to provoke conversation.

The sketches above helped us elicit honest feedback about offers, shopping and their interactions with the Co-op.

Cheap and quick feedback through sacrificial concepts

We wanted to quickly and cheaply test a few ideas with potential users.

Screen Shot 2019-03-12 at 15.39.43

Existing research suggests uncertainty and mystery motivates people. Would revealing an offer affect a member’s perception of it?

The feedback we heard gave us confidence that there was something appealing about this mechanic: it seemed to peak people’s curiosity. They found it exciting.

We know that people are influenced by social groups and communities. How would voting and social participation affect their interaction with the product?

Screen Shot 2019-03-12 at 15.40.02

The feedback we heard here was that this idea simply didn’t fit with how members plan their shopping. They didn’t plan their meals far enough ahead to know what they would want a week later.

We were also wanted to find out whether the way we presented the information about how much money members saved by using offers might affect their enjoyment. We explored whether there were any opportunities in terms of how we could show members the value of their offers.

Screen Shot 2019-03-12 at 15.40.13

The feedback we heard from some people was that they were more interested in savings in the context of their bank, not a specific retailer. But it was interesting to see how members reacted to us reframing the amount saved, so we learnt that there may be potential in this idea but it shouldn’t be the first thing we build.

What the sacrificial concepts told us

We took everything from the concept cards that we felt had potential and incorporated them into a prototype to put in front of members. This time, our designs had the research from the sacrificial concepts behind them but at this point, nothing was built in code. We used the prototype to get more feedback so we can iterate and improve for our members.

We’ve now identified 3 potential features for Co-op members digital offers. We’ll test them with larger volumes of users in May this year and we’ll listen to their feedback and make small improvements regularly.

The benefits of this technique

We started off with a lot of ideas and directions and through talking to potential users we’ve be able to quickly and cheaply ‘sacrifice’ the concepts that our research identified as having little potential. We’re left with the things we have a good idea will meet the needs of our members or at the very least are appealing to them.

If everyone shares an understanding of the benefits of being design-led, it’ll be easier for experts from around the business to work together to deliver value to Co-op customers, colleagues and the Co-op as a business. If you didn’t make the show and tell but would like to find out more, email Katherine Wastell, Head of Design.

Louise Nicholas, lead product designer
Joel Godfrey, product manager