I love personas. I feel really lucky that I get to spend a lot of time at work thinking and talking about them. For those less familiar with the concept, personas are fictionalised representations of different types of users that come into contact with your product or service. They focus on the user’s needs and any frustrations they might have, so that Product & UX teams can design and build solutions that work for them.

I’ve written before about making personas accessible — but this time I am talking about accessibility personas — personas that are designed specifically with a user’s accessibility needs in mind. Accessibility means that people with a wide range of hearing, movement, sight, and cognitive abilities are able to access your products and services. When we design inclusively, we consider all of the situational and contextual information related to how our users interact with our products and services so we can create great experiences for them.

When I started thinking about adding accessibility into our company’s personas, I realised there were a few ways to go about it. I could add accessibility elements onto our existing personas, or I could create new ones that were about business users in general but were focused on the accessibility need. Accessibility is not separate — it is a part of the design and build process — so I wasn’t sure that I wanted to have separate personas. But I also worried about getting across the true needs of the business persona and the accessibility persona if they were combined into one.

The combined method

It’s always good to do a bit of a competitive analysis, to see how other teams are addressing this issue. Shawn Lawton Henry has been an advocate for inclusive design for decades and leads education and outreach at W3C. In a 2008 interview, she discussed that one of the main challenges around creating accessible experiences was “lack of awareness. Most people aren’t aware that people with disabilities use the web” and called for more education and training on the subject.

Shawn’s book Just Ask: Integrating Accessibility Throughout Design (2007) helps to educate teams on thinking about accessibility needs. In the book, Shawn describes what personas are and how to use them. There are examples of business user personas including their goals, level of tech comfort and working environment. The personas then are supplemented with additional accessibility information, such as that what disability they have and what assistive technology they use.

For example, we learn that Hanna is in Human Resources and works from home a few days per week. She likes the flexibility of remote working, but finds her home equipment frustrating as the computer is older and slower than her work setup. By adding the accessibility elements to the persona, we learn that Hanna is blind and when she is at work she has access to a newer version of JAWS than what she uses at home, which causes her to work slower and be less productive.

In another example, Barclays worked in partnership with accessibility experts on diverse personas to “provide an insight into how people with disabilities may interact differently with our products and services”.

The Barclays personas include information about the user’s background, comfort level with technology, how they interact with the bank and specific tips to make each personas experience great. Barclays have done a lot of work to have a paradigm shift from accessibility as a legal requirement to accessibility as an inspiration for great design solutions. You can read more about Barclays Inclusive Design principles in this interview from 2017.

Designers Graeme Fulton and Nick Throckmorton have also both written recently about their approach to accessibility personas and why it is important to add disability and assistive technology directly into business personas.

Standalone accessibility personas

Despite finding several examples of how teams incorporated accessibility needs directly into business personas, I still wasn’t entirely convinced this was the way I wanted to approach it. The ways in which we think about accessibility needs can be complex and by trying to combine the distinct user persona needs with accessibility needs on top, it could be further confusing things.

Sheri Byrne-Haber, CPACC identified this and other challenges with updating existing business personas into one with disabilities. Are you able to include enough detail about a persona’s needs when accessibility is dropped into an existing persona? And what about the sheer variety of disabilities — is there deaf Jane, Jane with Migraines, Jane with ADHD etc?

In businesses where personas have been around for some time “people get very attached to their personas…(and) literally border on religious conviction”. Sheri instead suggests creating orthogonal personas with disabilities, which allows the personas to be “treated as if they are connected with and at a right angle to, but not integrated with, your existing personas that everyone knows and loves”.

There is precedent in creating standalone accessibility personas. In A Web for Everyone: Designing Accessible User Experiences (2014), Sarah Horton and Whitney Quesenbery shared eight personas focused on a variety of different disabilities. In addition to disability, the authors included contextual information about each persona, such as details about their families, jobs, or where they live. The purpose of the personas is to represent how everyday people, who happen to have disabilities, use technology in their daily life.

Whitney has a theatre background, so thinking about people and characters came naturally to her. “I think personas add something that’s often missing in discussions about accessibility, which is the people and their lives. We often think about designing for someone who’s blind or designing for someone who’s deaf, but we don’t think about designing for Jacob. He’s a paralegal, he’s an equipment geek, he loves new tools, and, by the way, he happens to be blind. Blind is the last thing about him in his mind. It’s not the only thing we should be thinking about. We should be thinking about everything about the person”.

Similarly, the World Wide Web Consortium (W3C) uses stories of web users to provide real life examples of how different disabled users want to interact with online content. The persona stories include background information about the individual, what challenges they face with inaccessible content and what design choices help their access needs.

The Helen Hamlyn Centre at the Royal College of Art in London used a persona format to highlight the accessibility needs of ten research participants. The personas provide a “richness of information” that comes from combining information about users abilities and lifestyles, and therefore leads to better design outcomes.

The personas are also complemented by exploring more about people’s daily activities. For example, by examining the challenges that older and disabled employees face both in the areas of working at home and working in the community through videos, quotes and case studies, teams can get a holistic understanding of their accessibility needs.

Finally, Government Digital Services (GDS) has been working to ensure that disabled citizens can interact with needed government services, even when they move online. They’ve taken their accessibility personas a step further and have created Chrome settings that simulate each of their accessibility personas. This enables them to both test software releases to ensure they pass accessibility requirements, but is also a useful tool for training R&D teams on why it is important to consider the needs of disabled users.

How to decide

For me, in creating accessibility personas I wanted to do a few things:

1. Focus on the person
2. Focus on the need
3. Allow people to understand and connect

Focusing on the person is kind of what personas are all about, right? We are attempting to create empathy for our users. This is done by creating understanding about the person and what they are trying to do. Accessibility considerations for personas are no different, and should be centered on telling a story about that person.

For our personas, I flipped the approach slightly and instead of focusing on the disability, I focused on the need. So instead of having an autistic persona, we talk about Serena, who needs to have information presented in a clear and straight-forward way. She might be autistic or have ADHD. But she also could be someone who is new to your product or service, or maybe has a migraine. Focusing on the need allows us to talk about similar needs that have different causes, thus allowing us to cover inclusive concepts in fewer personas.

For example, Serena appreciates simple, well-structured layouts, ‘just right” levels of information, contextual support and guidance, and patterns that help her focus. For a good user experience, we should avoid making her remember things (if I’ve told you something before, don’t make me tell you again), complex workflows with lots of pages and clicking, large blocks of text and timed interactions.

In the end, I decided that I wanted to have separate business and accessibility personas. Our business personas have evolved over the last 5 years or so, and some of them are very well known and loved within our company. Much to Sheri’s points above, I didn’t want to detract from either the strength of our existing personas or the importance of telling the accessibility stories. Separating them felt like the right thing to do.

I am in the process of incorporating the personas into our content and training materials internally, and the feedback has been positive. In February 2020, I presented the personas with my colleague Mark Boyes-Smith at a UX Crunch event in Manchester, which you can read about in the article below.

As always, personas are a work in progress, so it will be interesting to see how these personas change and grow. Mark and I have have made these personas available on Medium so that others can use them too.

At the end of the day, personas are just one tool that teams can use to help them understand their users. Don’t forget to actually talk to your users — including those with disabilities — across the design and development stages to ensure your product and service really is a great experience for them.

How are you handling accessibility personas at your workplace? Are they separate or a part of your business personas? Even if you haven’t started, reach out and tell me about your journey and where you would like to begin with your accessibility personas. I’d love to hear your thoughts.

This article is written by Wizly Product Management Expert, Alicia Crowther. Originally published on Medium.‍