usability testing

What we considered before researching with people who are visually impaired

Co-op1 Comment

Co-op Insurance talked about usability testing with people who are visually impaired last week on the Digital blog.   

Improving and influencing better accessibility where we can is important. This post describes how we prepared for the sessions. We hope it encourages more product teams to test with people with a range of access needs.  

1. Charities can help you recruit

We’d found it challenging and time-consuming to find participants who are visually impaired through recruitment agencies so UX designer Paul Braddock made direct contact with the Royal National Institute of Blind People (RNIB). Although it took a while to get approval for our post which asked for participants on the RNIB’s social media page, the number of respondents was worth it. Charities and specialist organisations that have a vested interest in – and access to – a group of people you’re trying to find seem to be very willing to collaborate.  

 2. Ask participants to bring their own device 

Observing someone using your product or service on their own device gives a more accurate indication of how they would interact with it outside a research session.  

When we asked our participants to bring their own tech, we learnt a lot about the additional software they used too. For example, one participant brought their laptop and showed us Dolphin Supernova – a magnifier and screen reader they use to zoom in on a page, read it aloud, and replace colours that are difficult for them to differentiate between. They told us they “can’t function without it”. But, if we hadn’t asked them to bring their own device, we would most likely have asked them to use one of our Macs which Dolphin Supernova isn’t compatible with. In that situation, we’d have missed out on seeing our service in a realistic context.  

3. Send digital consent forms

We sent out digital consent forms through Consent Kit before the sessions so that participants could take their time reading them with their assisted technology and understanding what they were signing up for. We knew that paper forms would likely be more time-consuming and less preferable. We also couldn’t anticipate what problems there may be with talking through and then signing digitally in the sessions so it felt important to sort out consent beforehand. 

 4. Talk about travel arrangements  

If you ask visually impaired participants to get to a venue, find out how they plan to get there and whether they’d like you to meet them off public transport. Paul met one of our participants at Manchester Victoria station. She’d never been to Manchester on her own before and told us she found big cities a bit overwhelming. They navigated the short walk to Federation House together and the chat on the way worked as an extra warm up to the session.
 

5. Allow for extra time

Factor in extra time for practicalities like travelling, accessing the building and keep in mind that participants might not instantly feel comfortable in an unfamiliar venue so your introduction may take a little longer while you help them to relax. 

A participant’s personal device may take longer to load or update than you’d expect too. One of the participants we met had specialist screen reader equipment that took a little while to set up on their mobile phone. Around half way through the session, they felt that because they were using the zoom so much, it would be easier for them to switch to a desktop device – they said this is what they would have done at home. Changing over and setting up again also took a little extra time. Seeing this sort of thing is really insightful though, so scheduling extra time means you won’t be tempted to feel like it’s an inconvenience. 

 

6. Go off script – you might learn more

Sometimes the thing you’re testing just won’t meet a participant’s accessibility needs and as demoralising as that is, it’s better to see those problems early. So, as with any usability testing, be prepared to change direction if a participant is struggling with a task because you’re still likely to learn a lot. 

We often found that participants used the service in ways we hadn’t anticipated so if an accessibility issue came up it made sense to discuss straight away, learn from it, and then move back to the script. For example, one of the participants we spoke to zoomed into pages by default. A lot of what we discussed in the session wasn’t in our discussion guide, but we were still getting useful insights. 

Testing with people with other types of access issues

So far, we’ve only run sessions with people who are visually impaired. Of course, there are many more types of vulnerable user and testing with a range of needs is important. This is a good start though.  

If you’ve tested your product or service with people who are visually or hearing impaired, or have a motor or cognitive disability, we’d like to find out what considerations you had before running your sessions. Share it in a comment below or tweet @CoopDigital. We’ll keep it in mind.  

Catherine Malpass 
Lead user researcher 

Co-op Insurance: Usability testing with people who are visually impaired

Co-op

This is a guest post about Co-op Insurance and their website, co-opinsurance.co.uk. The author is Paul Braddock, a user experience designer who works on it.

In the summer, we blogged about how and why we asked AbilityNet to carry out an accessibility audit on the Co-op Insurance website. The post explained the content, design and technical improvements we made off the back of it. To continue our work around better accessibility, the Insurance design team recently did usability testing with visually impaired users. 

In this post we share what we learnt from the testing and how we’re making improvements. 

What we tested

The Insurance team is responsible for co-opinsurance.co.uk. This includes managing the product information and financial promotions for each type of insurance. Buying journeys begin on our site but once a user chooses ‘Get a quote’, their online journey passes over to a partner’s site.

We can’t necessarily fix the accessibility issues we identify on a partner sites, but we can influence them. We’re actually in the process of creating a set of accessibility guidelines that cover our expectations of our partners.

Catherine Malpass from the Co-op Digital team and Louisa Robinson from Insurance ran the usability sessions. We focussed the testing on the travel section of the website including the buying journey. We wanted to look at how easily visually impaired users could:

  • navigate the journey
  • understand information – particularly in tables
  • interact with a pop up

We kept what we’d learnt from the audit in mind when we were considering what to test. 

Positive things that came out of the testing

During the testing, we heard positive feedback about:

  • the in-page navigation and clear labelling which helped users read and identify content quickly. One participant said it’s “fairly easy to find your way around and there’s a decent menu I can use to navigate to other insurance products.”
  • the colours on the homepage because – along with icons – they help users differentiate between the 2 products. “I like that the colours for car and home insurance are different,” said one participant. “I like having the icons next to the product names because they make it obvious and easier to navigate.”
  • the consistency of the page layout. A participant said that “the pages are similar all the way through so you can memorise where things like the next and back button are.”

Areas that need more work 

However, the testing also showed us that some features weren’t compatible with screen readers. We noted them along with recommendations for how to improve them. 

Things we’ve iterated on already include:

  1. How a screen reader reads out the prices in tables. We’ve changed the aria labels so that monetary values are read out how we’d naturally say them, for example, “thirty-three pounds eighty-four” instead of “pound symbol three three full stop eight four”. We don’t feel we should be asking people with visual impairments to work harder to use our service and we think that making this change will reduce some of the cognitive load. 
  2. How well we use alternative text (alt text). Testing threw up instances where images were tagged with the type of product or policy they were there to support. We’ve changed them so they fulfil their role of describing the content of the image. This makes the service more inclusive. 
  3. Making images clickable. The screen grab of our travel product page below shows 3 insurance products (multi-trip annual, single trip and backpacker). Each has an image, the name of the product with a link that takes them to a more detailed product page, and a line of copy to help the user decide if it’s suitable for their needs. Testing showed us that when the user zooms in on the page (common for someone who is visually impaired), or if they’re using a screen reader, the link is difficult to navigate to and then difficult to access. There was an expectation that images should be clickable, so we’ve now made each image clickable which makes the information quicker to find. 

The image shows a screen grab of our homepage below shows 3 insurance products (multi-trip annual, single trip and backpacker). Each has an image, the name of the product with a link that takes them to a more detailed product page, and a line of copy to help the user decide if it’s suitable for their needs.

Things in the backlog we hope to complete before Christmas include:

  1. How a screen reader reads icons in tables. At the moment it reads “tick” or “cross” but we’ve added aria labels so tick symbols will read as “included”, and crosses as “not included” on our next release.
  2. Test alternatives to the pop up. We saw the screen reader struggle and the participants become confused with a pop up on the single trip online journey, shown in the screen grab below. We’ll be looking at how we can give users the same information in a more accessible way. For example, we may embed the content at different points in the journey instead. 

Screen grab show a pop up prompting the user to upgrade to an annual multi-trip policy. the pop up hides much of the content on the webpage.

Things we’re encouraging our third-party partners to look into include:

  1. The live chat feature.  This feature wasn’t compatible with screen readers so thinking about how to improve it or even considering alternative ways to communicate with users instantly is one of our recommendations. At the moment, the feature also covers up content on the page so we recommend looking into how to help the user feel more in control – this might mean giving an option to remove / minimise /block the live chat. 
  2. How we present information. In the testing we saw users become a bit overwhelmed when comparing information. We recommend a review of how we display content when comparing price and cover in insurance tiers.
  3. The postcode finder. Right now, when a user starts to type in a postcode, the screen reader repeats “there are zero results for this postcode” until the field is complete. This makes it difficult for users to hear – and check – which letter or number they’ve just typed. We recommend looking into how this can be improved.

Carrying on testing, iterating, improving and influencing

Accessibility should be a consideration right from the start when we design products and services. At Co-op Insurance there’s a lot linked to our site that we cannot control but we can influence. We’ll continue to test with people with access needs and we’ll keep trying to improve the experience for everyone so it’s as inclusive as possible. 

We’ll also share our research findings, audit feedback and blog posts with our external insurance partners to help raise awareness of the importance of accessibility.

Paul Braddock
UX Designer from Co-op Insurance

Funeralcare: taking the beta to Edinburgh

Co-op3 Comments

Since April 2016, the Funeralcare team at Co-op Digital has been working to make life easier for our colleagues at our funeral homes across the UK. Our aim has always been to reduce the time our colleagues spend juggling and filling in paper forms so that they can spend more time with their clients – people who are grieving for their loved ones.

It’s been awhile since we wrote an update on our work. Back in August Andy Pipes, our Head of Product Management, said that we were rethinking how we deliver our at-need funeral service (an ‘at-need’ service is the immediate assistance someone might needs after reporting a bereavement).

At that point we’d built:

  • a ‘first call’ service that logs details of a death and automatically alerts an ambulance team by SMS to take the deceased into our care
  • a funeral arrangement service which captures the client’s decisions, the costs, and keeps colleagues in various locations from funeral homes and the central care centre updated
  • a hearse booking system, staff diary and staff assignment service
  • a coffin stock control system, and a way for clients to browse the existing coffin range
  • an audit system that captures certain steps in the service

Since then we’ve been busy testing with colleagues and iterating.

We’ve added new features

As we’ve learnt where the gaps are in the service, we’ve added new features. They include a digital mortuary register and a digital belongings log to record possessions.

Deceased can come into our colleagues’ care at any time of the day or night and it’s vital the funeral director knows where that person has been taken. To help, we’ve developed a digital mortuary register so that ambulance staff can book the deceased in and the funeral director can see where the person has been taken.

image shows a screen with the first page of the digital mortuary register. the options are 'booking in' and 'booking out'

Another new feature is a digital belongings log. Often, when someone is brought into our care they’ll have jewellery on them or other personal belongings with them. This means that when a funeral director at a funeral home gets a call from the grieving family to check up on jewellery, they don’t immediately know what the deceased came in with because the paper record is with the deceased at the mortuary. To make this easier and more efficient, we introduced a digital log instead of needing multiple phone calls between different locations.  

Live trial and user testing

We’ve been testing in 2 ways. From September to November we continued to visit funeral homes all over the country to observe how colleagues work but we were also doing usability testing on each of the individual features in the bulleted list above with colleagues in mock labs. We tested and improved each feature separately until we thought we’d built enough of a service to be valuable to colleagues. At that point, in December, we rolled out a beta trial in Bolton.

interaction designer Matt researching which content is most valuable to one of our colleagues with a paper prototype.

We asked colleagues in Bolton to use the service in parallel with their current process which involves whiteboards, post-its, paper diaries, fax machines and the old, often painful-to-use software. Letting them use it for real is the best way to learn what’s working and what’s not. It drew our attention to 3 major things we’d overlooked during usability testing.

  1. We thought we were being helpful by preloading the local churches and crematoriums but we hadn’t given colleagues the option to create new ones.
  2. We found that the calendar couldn’t cope with all day events.
  3. We discovered that colleagues help each other out so having restricted access for specific roles creates a problem if someone is off ill and cover is needed.

Testing the beta with a small number of colleagues helped us catch problems like these before we rolled the service out to more people.

Trialling the service in Edinburgh

We want our service to be useful everywhere but we’ve been told many times by colleagues that there’s no such thing as a ‘typical’ funeral. They vary from region to region for reasons including local traditions, operational set up, affluence, traffic as well as legislation. Because our aim is to give time back to colleagues so they can spend it with their customers, we need to create something that works for all users not just our colleagues in Bolton. That’s why we are launching our at-need funeral service trial in Edinburgh in March.

We’re still learning

The beta has shown us that funeral arrangements are made up of multiple interactions like choosing flowers, booking venues and signing off obituary notices. Funeral arrangements are iterative with lots of tweaks along the way, so iterating the design is the only way we can cope with all the new things we keep learning.

We know that standard software packages don’t solve every problem. By involving colleagues throughout we’re building something that meets their needs and will improve things for both colleagues and their customers.

We’re transforming the Co-op Funeralcare business but we believe that what we’re doing here will actually help transform the entire industry. To help us do this, Co-op Digital is working towards having a dedicated digital product teams within the Co-op Funeralcare business.

If that sounds like something you’d like to help with we’re looking for an agile delivery manager and a product manager.

You can read more about the agile delivery manager role and more about the product manager role.

Come to a talk about the digital transformation of our Funeralcare business on 28 March. We’re particularly interested in speaking to product managers, delivery managers, software developers and platform engineers. You can get your free ticket at Eventbrite.

Carl Burton
Product lead