After several weeks into researching web accessibility, we recruited four participants (three are pictured below) to get an outside perspective on their knowledge of web accessibility, this would help us create our persona and overall help us decide who to design for. Two of our participants were graduates and two were finishing up school so we had a good industry mix from our interviews. When it came to the contents of our interviews, we developed questions around categories that pertained to how our participants preferred to learn, what their knowledge of web accessibility was, and their preference for how informational content was delivered. During the moderation, we also asked follow-up questions to find any annoyances among the participants had regarding informational site structure.

We compiled our notes from each interview and wrote down key points from multiple sections of each interview and grouped them together to create our key findings. This would help in the creation of the goals and aspirations of our primary persona, Zara.

From our interviews we found several key insights:

• Regardless of current standing, the knowledge surrounding web accessibility was at an overall low point
• Almost all of out participants have a hands-on, visually enhanced learning style
• Preference of media to be mixed in with text when it came to online instruction

Zara Harper, our primary persona, is new to the designer scene. She is fresh out of college and eager to make a difference at the startup that just hired her. While not knowing much about web accessibility, she spends her free time researching and learning as much as she can about it. Zara is a hands-on learner and prefers having photos and videos mixed in with her instructions. Due to the influx of biased information, she needs to make sure that the information she is getting is reliable and as unbiased as possible. Although she is used to long word heavy articles about accessibility, she hopes for a way to make learning such more engaging.

Like most things, they require change. This is especially true for our problem statement, after taking time with our research and persona creation, we revised our vision statement to clarify more of what our goals were and how we will be filling the space that is the lack of web accessibility knowledge:
“The current state of web accessibility resources for novice UX Designers relies heavily on independent research and is poorly structured, making it difficult to digest. Existing resources are made up of complex information and an over saturation of biased articles. What they fail to accomplish is communicating accessibility guidelines that are intuitive and comprehensive. Our product will address this gap by creating a central hub that ensures our accessibility content is engaging and tailored to our users’ learning styles. This will create a desire to learn accessibility so that users can develop designs that are accessible to all.”

With our revision, we created our vision statement to voice our problem and solution to users and not so much the "business" side like our problem statement covers:
“The design for our accessibility resource will help users learn and engage with web accessibility guidelines by allowing them to interact with the content directly through their preferred medium of instruction and learn at their own pace. By creating a tool that intuitively guides designers, allows users to access information from a single source, and provides users with a stress-free environment that allows them to learn at their own pace, our product will dramatically improve the delivery of web accessibility guidelines.”

In our requirement phase, we developed our persona expectations, a context scenario, and created our requirements for our product.
Tasks we completed in our requirements phase:

• Brainstorming for the app design and functionality, this allowed us to collaborate on ideas verbally and get valuable insight from every member of the group
• Implemented persona expectations, these were grouped based on needs for functionality as well as content
• Developed our context scenario, this was a narrative to depict our persona's use of our site, this covered goals and needs. With this we developed the list of requirements for the design
• Created requirements list, we separated our list into four categories: Data (object), Function (actions), Context, and another category titled "Other" where we included other requirements that didn't fit anywhere else, but we wanted to include

We started creating our low-fidelity (lo-fi) wireframes in Miro (then moved to figma after the design studios), the screens we included were to be made based off of necessity in our requirements list. This included our key path, which is the main path a user takes when using the site, and validation scenarios, which cover any infrequently used features that our user will come across. Our key path included the steps of logging into the site, opening a saved module, browsing through recommended modules and eventually finding another one to repeat the process.

After our scenarios were established, we conducted two design studios to start establishing ideas and styles for our wireframes and any possible future designs. Each studio consisted of a 5 minute period, the first studio was to choose a screen in the key path that our user would see and design what we thought it would look like (each member created something). We then voted on features and screens from the other members that we thought were good and took the time of our second studio to recreate another screen with elements we like from the previous studio. We then took these screens and added them to Miro.

After starting our lo-fi wireframing in Miro, we moved to figma to start creating more animated screens, here we prioritized function over visual design.

We started our refinement phase by reaching back out to our four, previously interviewed, participants asking them to participate in some usability testing sessions, This was beneficial in gaining feedback since our participants were familiar with the product.

We started our usability tests in a very structured way, this included a set of tasks and scenarios that the participant was given to complete. We asked that they follow the "Think Aloud Protocol" (TAP) method when navigating through their tasks so that we could have some insight as to what was going through their head while working. After the first test we noticed that there is no structure when it comes to the curiosity of an eager user. So we loosened the reins and just used scenarios until we notice that the user was lost or sidetracked, this is when the author of whatever screen the user was on would ask questions regarding the layout and structure of the screen. The users were instructed to return to pages after their scenarios were complete to answer further questions from all of the members. This resulted in a more natural test and it allowed us to observe our participants in a more lax setting.

These were the necessary changes needed moving into our high-fidelity prototype. Many of these pain points were mentioned by several of our test participants. We collected a lot of things to improve upon and a lot of encouraging words about how this is a necessary tool for many.

Primary changes:

• Make the navigation more intuitive
• Overhaul the design of the homepage so that it looks like a home page
• Add a filter option for all pages that have have content to search

Secondary changes:

• Add indicators to swim lanes to make it more apparent as to what it is
• Include progress bars in the questionnaire and "tour" sections, as well as an option to skip
• Make it more obvious as to what options are selected
• Remove in-browser tabs to reduce cognitive load

The final step of our process was to create a presentation video that showcased our journey to design our site. We made sure to cover how GDD was applied in each stage of the process and coved key points Aardvark Accessibility offered to its users.

This was my second project that I saw through from beginning to end while using GDD, and from comparing my skills and knowledge then versus now, I can say I have grown a lot. Like all projects, time was of the essence and to do what we did with our deadlines really resulted in a project I can look back on and be proud of. Not only has this project made me more conscious of web accessibility, but it also allowed me more opportunity to work with new people and tools I was not so familiar with.

With all of that being said, I would like to extend a big thank you to my team members and professors, I could not have done it without them.

Goal-Directed Design is a collection of stages created as a tool that helps designers find and meet users' goals and needs. It also helps address the needs of businesses and sites that will be dealing with users of all types. Like most projects, one has to start out with research, this step focuses on interviewing potential users as a means to collect data and find and better understand users' goals and desires.