Viadukt – a mobile-first, while label solution for easy ticket bookings used by Malmö Opera, Bridge Theatre and many others – was built with, and for users with diverse needs.
This case study looks at how we defined accessibility and how we ran testing with users with different abilities, disabilities and challenges, to ultimately design an experience that’s better for everyone.
Online bookings, for everyone
Accessibility is one of Viadukt’s defining principles. So we knew we needed to design a product that considers the broadest range of access needs.
Before progressing from a clickable Maze-based prototype to a live product – read how we worked with users in early stage development in this post – we tested the product in multiple rounds of testing with users with and without access needs.
The purpose was clear – how can we design Viadukt in ways that considers the broadest range of access needs?
What this post covers:
Defining what accessibility means to us
Our testing approach
Actionable insights from testing
Learnings we took forward
Translating these into Viadukt’s content & design
Defining accessibility
Building an accessible product is not just about considering the needs of users with disabilities. There might be conditions, injuries, situational and temporary limitations, or divergent ways of thinking that disable users in a multitude of ways.
Not every user with access needs would ever label themselves as disabled.
There’s a whole spectrum of needs that goes beyond disabilities that might influence how a user chooses their seat when visiting a venue and watching a live event.
Focus on user goals
We needed to make sure we could facilitate the following steps in the UX, while staying in line with our overarching goal of creating the quickest, easiest way for users to book tickets to live performances.
Choose the right performance
Choose the seat that suits their needs
Choose the correct ticket to check out with
Get with any additional information regarding accessing the venue
We worked with a content designer to ensure that our decisions around language were based on expertise rather than assumptions, but we also made sure that copy could be updated and refined throughout the process.
Beyond non-sighted and visually impaired users, deaf and hard of hearing users, or users with mobility issues, there were so many more needs for us to consider – particularly when it came to seat selection.
For example, someone who suffers from claustrophobia might decide where to sit based on the nearest exit. A user with Crohn’s disease might need to know where the nearest bathrooms are. An obese user might wish to know the size of the seat.
Mobility issues might range from wheelchair users to someone who can’t walk very far through to users who feel pain in particular kinds of seats after a prolonged time, to temporary mobility limitations – and many more in between.
Information about the seats, the steps, lifts to the venue itself and being able to see the auditorium were therefore all crucial components we assumed we would need to consider.
Towards an accessible product
We had already done one round of testing on a prototype of Viadukt to get initial usability insights to improve our design (read more in this post), but we needed to take the testing to the next level and focus on making the product accessible.
We tested the product in progress from the moment a user chooses a performance through to landing on the confirmation page.
To validate our assumptions around what an accessible product entailed, we recruited 11 testers:
3 users without access needs who had never seen the product before
3 users without access needs who had tested the prototype
5 users with a variety of access needs (2 non-sighed users using 2 different screen-readers, 2 users with varying mobility issues and a hard of hearing user)
We conducted observed testing only, which meant we had organised one-on-one Zoom sessions with each tester.
From observation to action
Having tested with such a variety of users, we were able to divide the insights into:
1) general improvements to the product that would serve all users – irrespective of whether they had a specific access need or not.
2) Improvements specific to the range of access needs we’d identified
For both groups, we were able to validate our assumption that the journey from the basket to the confirmation page was clear and straightforward (bar some minor tweaks that would make the journey even more efficient).
For users with access needs, we identified some immediately actionable insights around giving users key information at the right points in the booking journey:
Access ticket availability
Having chosen a single ticket, the user has no option to add a free carer ticket so would need to call the box office at this point.
Action – make a free carer ticket available and provide all key information.
What happens outside of the venue?
Within the accessibility information modal on the seat map page, we can give the user more context about things such as:
how to get to the auditorium
how many steps are involved
whether there are lifts available in the venue
Action – add this information to the modal
What happens inside the auditorium?
Within the same modal, we can add more contextual information about the auditorium than is available on the seating overview page.
This will help answer questions such as:
How many stairs are there? Is there a hearing loop in place?
What are the seats like?
Where are the speakers?
Where are the nearest toilets?
What is the view from a wheelchair seat like?
Action – add this information to the modal
We learned that a crucial piece of information for users with access needs was the kind of missing information that would make them drop off and call the box office instead.
So we knew that our communications about choosing the right seat and checking out were going to be critical.
From insights to learnings
There were some key learnings from an access point of view that we took into the next round of build and design.
Testers with the ‘same access need’ still have different needs
This became particularly apparent when testing with non-sighted users.
Not only do different visually impaired users use different types of screen-readers (or magnifiers), but as with any other user, they will also have different preferences around how to navigate a website.
Some are very digitally savvy and some are not.
Some rely on screen-readers to give them all the choices so they can make an informed decision, while others prefer website shortcuts and to have fewer options.
Some users naturally have more or less time or patience too.
Two key things we took from this:
Some non-sighted users are more comfortable with their screen readers
This means they want a lot of detailed information to make an informed choice – particularly when it comes to choosing their seat.
One non-sighted tester was excited about the prospect of understanding the layout of the venue, tabbing through the rows, learning how many seats there were in each row and being able to make a decision about where to sit in relation to the stage.
Some non-sighted users want shortcuts
Conversely, our other non-sighted tester felt very overwhelmed by the number of options she was presented with on the seat map page.
Instead, she wanted to navigate to shortcuts based on recommendations (e.g. recommend seats that will have the best sound to me) and so we knew we needed to give her more information about the venue and auditorium layout before she’d delved into the other details.
How did we address these needs?
We made the accessibility modal on the seat map page one of the first links that both a user and a screen-reader can open.
We created a mechanism for the user to ‘skip to the next call to action’ based on their needs and preferences.
We added an option to call Box Office as a last resort in case the online booking journey still couldn’t meet their needs.
Making a product navigable, accessible and ‘digestible’
We also learned that accounting for a lot of needs can make information on a page overwhelming.
So how did we ensure the UX and copy was still easily navigable and digestible while providing users with varying access needs (and varying user behaviour within that) with the right information they needed, at the right time?
Our design and accessibility principle was around being clear about the purpose of each page or component within a page – what did the user need to know in order to make an informed choice and click on the next CTA?
Committing to an accessible product
Here’s a summary of our final learnings and questions we’d love for anyone else building an accessible product to think through:
There’s no such thing as building a product in a user-focused way and then making it accessible – how are you ensuring you are working with users with diverse needs as soon as possible in your project planning?
When you want to build an accessible product, you need to test with users with and without access needs continuously and not treat them as separate layers of usability testing – how are you recruiting your users and who ensure you have a good balance of diverse needs represented?
Quick and efficient versus accessible versus benefiting the business more than user – sometimes there will a conflict of interest, which features do you want to commit to and why? What are the guiding principles of how you build your products – and how are you making ‘trade-offs’ in ways that still considers accessibility, every step of the way?