Aardvark Accessibility

“How can we learn more about accessibility in design?”

By way of the Goal-Directed Design process, I worked alongside three other team members to create a web-based accessibility tool. As novice designers, we were aware of our lack of knowledge on design accessibility standards, and wanted to learn more. Though our idea for “what” we would design evolved throughout our research on the topic, accessibility remained our priority.

This project was created on an eight-person team: four people tackling a mobile form factor and four people working on a web form factor. The concept of an eight-person team piqued our interest, as it would allow us to navigate a larger team than we had previously worked in, as well as giving us the opportunity to manage a cohesive design system for two form factors.

Due to the COVID-19 pandemic, this project was completed in a hybrid format. We led a balance of in-person and virtual meetings with Discord, Zoom, and Microsoft Teams to aid our communication. We utilized Miro (digital whiteboard collaboration software) to perform group activities and organize content, and Figma to design our prototype. This project was completed as part of my Senior Capstone course at Kennesaw State University.

 Using Goal-Directed Design to create a product based on user goals

For our semester-long capstone project, we utilized a design process known as Goal-Directed Design, created by Alan Cooper. Goal Directed Design is a detailed process that keeps user needs at the forefront to produce an effective product. This process is broken up into five phases: Research, Modeling, Requirements, Frameworks, and Refinements.

Meeting to discuss business and user assumptions

To begin our project, we held a kickoff meeting, during which we defined our problem statement and made user and business assumptions. We noted that the current state of Accessibility for Designers is primarily focused on the designer's independent research. In order to combat this, we aim to create a product that acts as a single source of truth where any and all accessibility resources needed for designers will be housed.

Problem Statement

Evaluating our competitors

We then conducted a competitive audit to get a sense of how existing platforms present accessibility content. When choosing what platforms we wanted to explore, we looked at both accessibility websites and learning platforms. We decided it was important to research learning platforms because accessibility topics can be complicated, and we wanted to learn what features could be utilized to help our users learn information with ease. We interacted with 13 accessibility websites and learning platforms and compared their features to see what solutions provide value and where there are limitations or room for improvement. The table displayed here is a condensed version that does not show all of the competitors and features we found.

Our Key Findings

From our interviews, several key insights emerged:

• None of our participants had a solid understanding of accessibility, but acknowledged that it was important and something they wanted to learn more about.

• Despite a lack of knowledge on the topic, some participants were familiar with accessibility checkers that assessed contrast ratios and used things like screen readers or alt text.

• Almost all of our participants have a hands-on learning style, so they learn best by following something step by step or watching someone else do an activity first, then doing it themselves right after.

• As far as learning preferences, they preferred a mix of text, videos, images, and examples.

• When researching anything related to design or accessibility, participants tend to open many tabs which can be a lot of info to sift through.
  

 Modeling our users

The modeling phase is meant to reduce the research to something manageable and allow the team to focus on user goals as a way to easily inform stakeholders of whom we are designing for. The goal of this process is to create a persona based on data gathered from our contextual research, user interviews, affinity mapping, and behavioral variable mapping.

Personas are a tool used by designers to streamline the design process when creating for a specific purpose or individuals. Though considered an archetype based on behavior patterns, personas are not stereotypes, as they are derived from observed behavior rather than broad assumptions.

Benefits of a persona:

• Avoiding elastic users, self-referential design, and edge cases

• To build consensus and commitment on design teams

• To aid strong communication between designers and stakeholders

Defining our vision

 Revisiting our Problem Statement

We revised our problem statement, as we felt we could now articulate our user goals with more formality. In this revalidation, we clarified the purpose for our product and how it will fill a gap in the market.

Vision Statement

Along with our new problem statement, we developed a vision statement. Whlie a problem statement acts as a “business-first mentality,” a vision statement captures the “user-first mentality.”

• Brainstorming gave us the opportunity to air out all of our ideas, regardless of their feasibility.

• We divided our persona expectations into data needs and functional needs.

• Our context scenario was written as a narrative to detail our personas experience using our website with an emphasis on use motivations, needs, and goals. Using this context scenario, we extracted our requirements for our design.

• We categorized our requirements into data, function, context, and others.

 Wireframing our scenarios

Once our personas' needs were established with the help of the requirements list, we began the frameworks phase. We created low-fidelity wireframes in Miro.

Key Path & Validation Scenarios

In the frameworks phase, we created our key path and validation scenarios. A key path scenario is the most “well-worn” path a user takes through the site, while the validation scenarios are alternative scenarios with less-used, but still necessary, features. For our key path scenario, we mapped the user’s journey through signing into the site, interacting with a module, and exploring recommended content.

Low-fidelity Prototype

Moving into Figma, we began our low-fidelity prototype. In this version of our prototype, we prioritized interaction over visual design. We carried over design choices made in our wireframing stage to block out content.

 Refining our Design

In our refinements phase, we conducted four usability testing sessions to gain feedback from our users and enhance our design choices in the prototype. We recruited the same participants we originally interviewed. This not only allowed us a quick recruitment for testing, but it also allowed us to use people who were familiar with the context.

Finding our groove

For our first usability testing session, we structured a set of tasks and scenarios for our users to complete. While completing these tasks, our participant utilized the “Think Aloud Protocol” method, in which they voiced their thoughts on the prototype as they traversed through it.

We quickly realized some navigation and design inconsistencies in our low-fidelity prototype that made some of our tasks and scenarios a lot more difficult to navigate.

For the rest of our usability testing sessions, we provided our participants with the link to our prototype and asked them to utilized the think aloud protocol as they moved through it. As opposed to the first session, we simply observed our users, only speaking when they had clarifying questions. We found that this method gave us great insight on the ways our participants navigated Aardvark Accessibility, as well as their raw impressions.

Minor Changes:

• Adding arrow indicators to the horizontal scrolling sections of modules and articles.

• Showing the progress of the questionnaire, as well as including an option to skip.

• Making highlights to selected options more noticeable.

• Making checkboxes visually clearer.

• Removing the in-broswer tabs to reduce confusion and clutter.

These were seen as various points of confusion for several users and we made sure to address them for our high fidelity prototype. Overall we gathered a lot of positive and constructive feedback on the prototype, most of our users found that a resource like this would be very helpful.

 Final Prototype

At the conclusion of the Goal-Directed Design process, we created a twelve minute audio/visual presentation on the overall design process of our website. We discussed how GDD was applied to each stage of our product, while highlighting the main features Aardvark Accessibility has to offer.

In addition to this link, I will show off specific parts of the prototype below.

 Design System

Because Aardvark Accessibility consisted of two teams and required many components, it was important for us to organize our content that let us grab the same element easily. To organize our content, we created a design system that included our styles, interactive components, and layouts of cards and other graphic elements. Being able to arrange our styles and components made it easier to keep the website consistent and create complex, nested components. While the website itself is relatively simple, we were able to apply our knowledge of Figma to create a seamless and inviting interface.

Wrapping Up

1. As this was my second time producing an end-to-end user experience with Goal-Directed Design, I felt that I had more base knowledge and a better understanding of the overall process.

2. Creating a project based on accessibility in design has greatly influenced my design choices. I now consider accessibility at the forefront of my design process, rather than at the end, or not at all.

3. My team and I would’ve loved to have more time for this project. With more time, we would refine our design based on feedback from a new user group: educators. We would’ve loved the opportunity to interview educators for our platform, as well as subject matter experts on the topic of accessibility.

I must extend a big thank you to each of my team members. This project could not have been done without their help. Thank you to Amali, Antonella, and Ian!