Aardvark Accessibility

Web Designer
Aardvark Accessibility is a resource that aids novice designers and developers in learning how to make web content more accessible. Using the information from the WCAG, we use progression metrics, engaging visuals, and chunking to reach all learners with different learning styles.

Year

2022

Prototype

Problem & Solution

Problem

The current state of web accessibility has focused primarily on existing resources such as the Web Content Accessibility Guidelines (WCAG). While resources like WCAG and others exist, they present a challenge for novice designers and developers. The complexity and difficulty in understanding the content create a barrier to the implementation of inclusive design.

Goal-Directed Design Process

Working alongside a team of other UX/UI designers, we collaborated on the educational mobile app using the design process by Alan Cooper, Goal-Directed Design (GDD).

GDD is an approach to design that focuses on satisfying user goals. It emphasizes understanding the needs and motivations of users and designing products and services that help them achieve their goals. On this page, each phase of the design process that the team navigated will be comprehensively described.​

Research Phase

In the Research Phase, we built an understanding of the problems and stories users had in our product's domain. We collected both qualitative and quantitative information that not only helped justify the decisions we made in the design process but assured us that we were addressing the correct demographic. By allowing research to be the foundation of our project, we acknowledged and empathized with our users’ needs.

In this phase, we underwent two types of thinking -- convergent and divergent. We considered all possibilities and then embraced structure to define a clear solution. By dong so, we increased the value we delivered to the end-user.

The following is what the team and I did within the Research phase: Kick-off Meeting, Literature Review, Competitive Audit, and User Interviews.
Uncover the Details: Click to Expand and Dive Deeper into Our Creative Process
Kick-off Meeting
​The sole purpose of the kickoff meeting is to get together to discuss the main elements of a product's demand and gain an understanding of how stakeholders envision their product, users, and goals. However, because this is a class project, there were no actual clients. To improvise, we filled out a Kickoff Meeting worksheet to mimic real-life work environments.

​Led by our team leader, Krista, we held an in-person meeting where we discussed project goals, visions, and expectations for the project. We initiated the conversation with the timeline and how the project will fit within each of our schedules.

After acknowledging the teams' varying and diverse skills, we set expectations for the duration of the project and get a shared understanding of the vision of our product.

On Miro, we worked together to answer create a problem statement, assumption statements, and a hypothesis on our persona(s).
Literature Review
​This phase included collecting data on our product domain—current views on it, user reviews of products, any externalities that might shape product domain, et cetera. We collected qualitative and quantitative data that can be used as a basis for developing questions to ask in an interview.

Sources that we collected were: internal documents, web searches, and industry reports.

A few of our findings:

  • Interesting statistical surveys, shows usage of an accessibility tool (screen readers) and how they vary in demographics with web vs. mobile
  • Accessibility is addressed to those who can afford technology that helps those who experience disabilities. (Does not consider demographics of socioeconomic status, people who low income)
  • Attention spans are short in mobile UX. Users want results fast, with minimal effort and zero friction
  • A11y is frequently used outside of social media and in tech circles to refer to the movement for a more accessible internet and technological infrastructure altogether
  • All websites from the public or private sector designed after 2014 need to follow most of the A and AA standards from WCAG (with the exception of 1.2.3–1.2.5)
Competitive Audit
To guarantee success and stand out from the competition, we need to consider and address gaps other apps fail to fill. Half the team investigated our competitor’s strengths and weaknesses to get a general idea of the product's current functional scope.

​A few educational platforms that were reviewed were: Khan Academy, Quizlet, Kahoot, w3schools, Duolingo. Each platform was analyzed not only by features, but on interaction and visual design principles.

What we looked for:

  • Was it free?
  • Are video lessons provided?
  • Were animated illustrations/graphics used?
  • Was there an interactive community space?
  • Does it track user progress?
  • Is the learning reward-based?
User Interviews
After concluding the literature review and competitive analysis, both halves of the team regrouped to exchange and discuss the knowledge we came across on such as: business marketing plans, branding  strategy, market research and relevant features. This data was a great premise for creating questions to inquire interviewees.

To get direct exposure to potential users and how they behave, we conducted interviews. This is incredibly important to us as we get to hear from real people and their experiences.

To get the most out of these interviews, we created a standardized set of topics we wanted to cover to ensure we gathered enough details to recognize significant behavior patterns.

Some topics we touched but not limited to are:

  • Education background
  • Accessibility
  • Learning style
  • Information UI
  • Device
Interviews were done remotely through Discord.
Each one of our team members was assigned to be a moderator for each user interview. The moderator would deliver the questions to each interviewee and all other team members that were present were listening and writing down all the answers the interviewee provided. After each user interview was conducted, the present team members would write down individual ideas on sticky notes with information that stood out to them about each specific interviewee to put on the Miro board. After all the user interviews were conducted, we applied a practice called "affinity mapping" to sort the information from each user by finding patterns and themes in our collected data.
After we completed the Research phase, we continued onto the Modeling phase where we created Personas. This is a crucial step for designers as it is a fictional representation of our ideal customer, and it lets us know exactly who we are designing for. Without personas, we would risk designing a mobile app that is not functional to our target audience.

Modeling Phase

​To start this phase in the Goal-Directed design process, we took our work from the affinity maps to identify behavioral variables such as activities, aptitudes, motivations, and skills. We then used a behavioral mapping tool to map the interview subjects. This helped us recognize significant behavioral patterns.
With this information, we created a persona, a fictional character based on our research. Being based on real experiences, personas are wonderful representations of our potential users.

Our primary persona derives from the majority of the users we interviewed who were not familiar with web accessibility.

Requirements Phase

​In the requirements phase, we had to visualize how our personas would use our educational app and how the product would fit into their lives. This is important because it assists our team to create features that would help potential users achieve their goals.

My team and I met in-person discuss context scenarios and create a requirements list. Context scenario is the story of a persona optimally using the future product. This enabled us to think like our primary persona, Zara, and imagine what she would do when she wishes to learn more on accessibility.

With the context scenario created, we can move onto creating a requirements list. At this stage, we examine features and functions that would greatly benefit our primary and secondary personas that should be required in the app.

Frameworks Phase

As the team progressed through the Goal-Directed Design process, each phase elaborated further on data previously collected from prior phases. In the frameworks phase, my team and I were ready to create an easy-to-use app interface for our targeted demographic.

Before finally prototyping, my team and I collaborated on Miro to create low-fidelity wireframes. Each member created mock screens that had little content and placeholder text. This a crucial step in GGD since it lets us visualize concepts and brainstorm with ease; not much time would be lost since they are screens with placeholder text and images.
Moving on to the next stage, all team members assumed the role of prototyper, and with the low-fidelity wireframes as a foundation, we efficiently translated our ideas into Figma to create the final product.

To begin designing the prototype, we collaborated as a team to establish a color palette and brand identity. As a team that heavily researched how to create accessible web content, we were careful to choose colors with good contrast ratios that are visible to those with color blindness.

​Our competitors' interfaces featured fun and engaging colors to enhance information retention, and we applied the same principles to our design. The visual design is a critical aspect of the project's success because it can encourage users to continue interacting with the app and maintain their attention.

Refinement Phase

​Before we consider the project complete, we need to refine the prototype by iterating on any misunderstandings that testers may have had. To gain the confidence in the mobile app, we conducted user testing to ensure that the target user can navigate and use the app effectively.

We conducted virtual usability testing sessions on Discord with two participants, allowing us to share our screen and observe how they interacted with the app. After each session, we asked the user about their experience with the app and used their feedback to refine the prototype for a better user experience.

The refinement phase is critical because it allows us to see the app from the perspective of an actual user rather than just as designers. By observing a user in real-time as they navigate Aardvark Accessibility, we can design for their actual needs, rather than what we think their needs might be. This stage ensures that the final product provides a positive and effective user experience.

Conclusion

Challenges

One aspect of the project that we were not able to explore as thoroughly as we had hoped was the student versus teacher account plans. Due to time constraints, we were unable to conduct in-depth research and testing with subject matter experts such as professors. However, we recognize the importance of this aspect of the user experience and would love to explore it further in the future. To do so, we plan to set up subject matter expert interviews with professors to gain a better understanding of their needs and how we can optimize the app to meet those needs.

Despite these challenges, we're incredibly proud of the job we accomplished on this project. We faced several obstacles, including time constraints, limited resources, and the need to learn about web accessibility from scratch. However, we overcame these challenges by working collaboratively and utilizing our design process effectively. We focused on the user's needs and goals throughout the design process, and we constantly iterated and improved our designs based on user feedback. As a result, we were able to create a valuable educational app that simplifies web accessibility for both students and teachers. We're proud of what we've accomplished and excited to continue improving our skills and creating products that make a positive impact on people's lives.​
Creating Aardvark Accessibility, an educational mobile app that teaches web accessibility, was a valuable learning experience for our team. We realized early on that we lacked training in accessibility, which made us even more determined to create an app that could educate both us and our users. We conducted extensive research on accessibility guidelines and best practices, which helped us gain a better understanding of the principles we needed to teach. Working on this project provided us with valuable information that we will be able to apply to future projects.

Throughout the design process, we saw significant improvements compared to our past projects. As a senior capstone project, Aardvark Accessibility represented the culmination of our learning and growth as UX/UI designers. We approached each phase of the Goal-Directed Design process with greater confidence and competence, thanks to the knowledge and skills we gained through this project. We're proud of the progress we've made, and we're excited to continue applying these principles to future projects to create products that are not only aesthetically pleasing but also accessible to all users.