Skip Navigation
News & Ideas

Tappers and Swipers: Interaction-based (IB) Personas for Designing Accessible Products

Accessible Media Inc (AMI), a non-profit broadcaster of described video and other accessible content, approached TWG with a challenge that confounded the Visually Impaired (VI) community. People who are visually impaired have as much desire to adopt technology as sighted individuals. In fact, many VI folks are highly proficient technology users, and find immense value when apps are shipped with them in mind. That said, product development doesn’t often consider the VI community’s point of view. It was a compelling issue, and a challenge TWG wanted to tackle head-on by creating a video content mobile app built specifically for the VI community.

While researching, designing and building the AMI product, the TWG team discovered two distinct ways VI folks interact with technology. We turned that discovery into interaction-based (IB) personas we call Tappers and Swipers. Developed by TWG, IB personas are a completely revolutionary persona type in user research. Our process certainly taught us a lot about the unique needs of people who are not typically considered during the development of an app. We are pleased to share our learnings so that you, too, can use the IB Tapper and Swiper personas to build more accessible products.

The Project

Many of the most popular apps are virtually unusable if you don’t have full vision (looking at you, Uber and Snapchat!), Certain operating systems, like Android, tend to be difficult for the visually impaired to use as well. On the other hand, operating systems like iOS are pivotal for the VI community. Engineers at Apple undoubtedly spent countless hours architecting and building an incredibly sophisticated set of tools to make iOS work seamlessly for people who have limited or no vision. Most sighted people have no idea these features exist. But they do, and are a lifeline for users with accessibility needs.

AMI wanted to leverage the accessibility features of iOS to serve their content to the VI community. The TWG product team working on the AMI mobile app knew from the get-go we had a lot to learn. With questions in-hand, we reached out to VI folks to learn about their lives and empathize with their experiences.

Before prototyping anything, we undertook dozens of hours of research on platforms comparable to AMI such as Netflix and Youtube. We also explored commonly used apps like Gmail, Twitter and more to discover both pain and pleasure points for VI folks. With this critical information we began to design and engineer our own experience through bi-weekly UX research and user testing with more than 30 individuals from the VI community and gathered more than 50 hours worth of data.

We discovered VI individuals interact with technology in one of two distinct ways: tapping and swiping. We took this learning and turned it into what we call interaction-based (IB) personas.

Personas are Tools

Among common practices and workshops used by design and product teams, persona-building is often the first that comes to mind. Many of us have worked in a place with big sheets of paper labeled ‘Mary Marketer’, ‘Social Sam’, and ‘Director David’ that adorn the walls. They are often laundry lists of demographic characteristics ranging from salary, marital status and favourite type of foods.

We use these personas when building products as shorthand for the list of motivations, traits and characteristics that are central to understanding the people for which the product is designed. This in turn helps us frame discussions around building new features. For example, the conversation might go like this: This new feature design will prevent Mary from churning, but likely won’t have any effect on Juan or David.”

Personas are powerful communication tools, and see frequent use on fast-moving technology teams for that reason. But in the case of the AMI app development process, traditional personas fell flat because didn’t help us make specific feature decisions. We needed to develop something completely different. That’s when the IB persona concept was born. They filled in the missing pieces of the user profile and got us to specific features that were needed as part of the app.

An IB persona is different from a traditional persona. It has little focus on motivations or personal traits. The focus of an IB persona is the interaction pattern that defines it, and the attributes that strongly correlate with that interaction pattern. This new persona type helps to picture exactly when and how someone will use a product, and in what specific context. In the case of the AMI project, IB personas specifically helped us to characterize two mutually-exclusive interaction patterns and communicate those patterns with others quickly and easily.

Building the IB Personas of the VI Community

As we put together our insights on the IB personas, we found the following approach worked best for us:

Defining Characteristic

What is the main quality that differentiates the two personas from each other? What was the main quality that defined each of the interaction groups? In our case, it was comfort level with technology.


What did we observe to be common attributes of these people? This could include demographic attributes like age, or behavioural attributes like mobility.

Directional Information Processing

This is where we got hyper-specific about interaction patterns. Since our IB personas were specific to the visually impaired community (and even more specifically, blind and partially blind users), our personas included cues about how the two groups navigated around the screen with and without the assistance of VoiceOver.

From this core structure, we filled out the key information of the two IB personas we discovered: tappers and swipers. We believe that these IB personas are applicable to any app on an iOS device (phone or tablet), as they held consistent across all the different apps we researched.


Individuals less comfortable with technology (and the accessibility features iOS provides) use apps with a ‘tap somewhere and see what happens’ mentality. This chaotic approach to navigating a screen is a challenge for designers, because tappers often interact with elements without understanding the context of the rest of the experience.

Imagine trying to find a video to watch on YouTube’s home screen without knowing what the headings are. This approach to app navigation pushed our team to be extremely precise with our descriptive labels, hints and commands of elements, making sure to contextualize them with everything else on the screen.


In contrast with tappers, swipers move through mobile experiences with incredible speed in a way that can be described as programmatic. They go through content in an orderly fashion, and as a result it is much easier to build experiences for them.

Swipers are often able to use the accessibility rotor to jump from heading to heading. In some cases they are able to navigate their phone faster than sighted people. As long as you create an internally consistent experience in your mobile app, you’ll probably be a hit with swipers.

Putting IB personas to work

Creating a common taxonomy to describe core interaction behaviours helped the TWG team rally around these consistent archetypes of our core users. Our entire team was able to empathize with the user and make practical decisions about the product that ranged from the width of buttons to the placement of the app’s key features.

Here’s how we applied these learnings in practice:

  • Making decisions about the size of touch targets and clickable areas
  • Determining the order with which VoiceOver elements would be read aloud
  • How descriptions were formatted and ordered (show an example)

Engineers referred to our IB personas as a tool to understand usability issues that were unique to each of the two user groups. This gave them an opportunity to mimic behaviours of both groups while testing their work. During this project, it would be common to see a fully sighted developer with their eyes closed, headphones on, immersed in interacting with the half-baked feature they just coded. You’d see them swiping in a linear fashion, like the swiper, and then tapping around the screen like the tapper.

Quality Assurance kept the personas top-of-mind in bug bashes and other quality testing rituals. They were then able to append feedback to user stories in JIRA that referenced tappers and swipers specifically: “As a tapper I need larger font sizes on all clickable elements so I can access this content without having to tap twice.”

An invaluable benefit of having IB personas was that our technical team members were able to find a common thread with the users and empathize with their needs with every line of code they wrote and tested. Often, they weren’t able to attend all usability tests, so IB personas gave them the framework they needed to write VoiceOver hints and labels with the audience top-of-mind.

Designers, researchers and product managers used the IB persona framework most of all, especially in client settings. Our team came prepared with the context of the patterns to discuss feature and design decisions in the app. The width of a button style could be attributed to the interaction patterns of a tapper, while a feature on the roadmap would be attributed to the needs of the swiper (like a VoiceOver hint on a specific element).

IB persona’s became the designer’s not-so-secret weapon when discussing features, sizing and styling of elements, and functional labelling within the app. Contrary to the way in which traditional personas are used in app development, IB personas were directly employed at the feature level as opposed to being used for more wide-angle decisions. This approach made it feel as though we had zoomed-in on the decisions we were making at 200%.

Decision Making, 200% zoomed-in

The benefits of the IB approach to persona development permeated all aspects of the project — from the way our teams conversed at standups to how we presented our work to the end users (and our client). We felt the ripple effect of this simple deliverable throughout the entire project.

Our hope is that the IB persona methodology and process will help others developing accessible apps zoom-in on the work in order to make similar tactical decisions about a product.

For now, we believe we’ve only scratched the surface on potential use cases for IB personas. We’d love to hear from you about how the application of IB personas to your product. Send us a note at

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

If you’d like to build an accessible product experience, or audit an existing one? We’re happy to chat.

Interested in more detail about IB personas? We’ve developed a comprehensive guide to mobile accessibility, with many more of our learnings. Get your copy here.