Back to projects

Accessible QDAS

Project Background

This project is in collaboration with the American Foundation for the Blind.

The researchers that work at AFB are blind or low vision which excludes them from using popular Qualitative Data Analysis Software (QDAS) available in the market. This makes their workflow slow, inefficient and overall frustrating. They have had to figure out multiple workarouds to complete their tasks using Word, Excel and Google Drive.

This project will be handed off to the Masters of Computer Science Capstone next year to complete development.

My role: Lead Designer

Contributions:

I created Wireframes, hi-fi designs, and a design system from scratch for this project. I had to keep in mind keyboard interactions and compatibility with screen readers and magnification software while still making the software aesthetically pleasing and high-contrast.

I was also in charge of creating documentation for all files for handoff.

Problem statement

How might we improve the accessibility and efficiency of qualitative research workflows, with a focus on transcript coding and analysis, for blind and low vision (BLV) researchers at AFB?

Research

We conducted several research activities for this project

Literature review
Competitive Analysis
Shadow/Observation sessions
Interviews

Research insights summary

The current workflow is an adaptive response to the limitations of the available QDAS tools.

The team prioritized participation, accessibility, and learnability.

A central tension is the need to support both accessibility and methodological rigor.

Design

Co-design workshop

We started the design phase by conducting a Co-Design workshop with the AFB team of researchers. The workshop had to be accessible for all the members so we opted for a Google Docs worksheet approach. We gave them some prompts and we had an open discussion about what features they would like to have for their software. After the Workshop we created an effort vs impact matrix to prioritize what we would work on this quarter.

This image shows a priority matrix for the upcoming prototype. It has 4 quadrants, high impact and low effort, high impact and high effort, low impact and low effort, low impact and hight effort. Post-its are with features are distributed across the matrix

Pain points

Individuals

Disorienting to navigate between windows - lose their place
Different platforms don’t work for different people
Admin work is burdensome and done by hand
Everything is spread out, meaning lots of copying and pasting between windows

Collaboration

Hard to work on the same thing at the same time
No easy way to review others’ work
Every team member uses different tools hence version control is difficult

Low-fidelity prototype

After the workshop I sketched some wireframes to brainstorm ideas and then made a higher fidelity version in black and white.

Digitized black and white prototype of the trasncript screen

Features included

Tab-based organization and single keystroke navigation / location querying
Ability to code and take notes directly on the transcript
Individual tabs for coded data, notes and overarching themes

User testing

We took this first prototype to validate it with out users and get some feedback. We interviewed 3 researchers for this test, 1 sighted, 1 blind and 1 low vision to get perspectives from all of our user types.

Round 1 findings:

Coding notes and overarching themes notes are different types of notes, so they should be separate.
Notes should always be visible to the team
Minimize navigating across the screen for magnification users.
Varying preferences on codebook visibility
Prioritize team wide features vs admin features.

Functionality prototype

From these findings we worked on a higher fidelity web prototype using Claude Code. We took this and tested the functionality. We were able to test compatibility with screen readers and magnification users. The necessity for this prototype comes form the issue that Figma prototyping system doesn't accommodate screen readers, nor is it possible to have it play confirmation sounds. This prototype will be a functionality reference for the Software Eng. team.

Screenshot of the trasncript workspace created with Claud Code.

Round 2 findings:

Not all screen readers or operating systems handle HTML the same way. Further testing needs to be done for correct implementation of a native app.
Code book hierarchy was confusing and inconsistent across pages
Having to scroll through a whole list of codes to reach the note button is inefficient.
Underlines for linked text is necessary and doesn’t impact readability
Admin: needs to check for code discrepancy
In notes page: distinction between quoted text and researcher note is not obvious.
Screen reader needs to announce an excerpt is coded before the excerpt is read.

Design System

Since this project is being handed off to the Software Engineering Master's program at UCI. It was important to document the design in great detail. We created design system from scratch for this project. Here are some examples from the design system itself.

Typography

screenshot of the buttons section of the design system. It has every button style listed with its corresponding styling

Example of the design tokens

Color palette

Screenshot of the grid section of the design system. It has examples of how we used a 4 point grid system throughout the interface.

Final Figma prototype

This is the final clean version of the protoype created in Figma. This design will be handed over to the SE Master's to guide them for how the software should end up looking from a visual perspective.

Transcript page for the prototype. It features a left column with tabs to important pages in the software: project files, code book, coded data and notes. On the top page there's a tool bar with position information, transcript progress, a search bar and a text size selector. In the main area of the page, the working area, the transcript is formatted in a grid system. First column includes the speaker and timestamp, second column includes the excerpts, third column is for codes applied and last column has a note icon in case a researcher left a note. Lastly, at the bottom of the screen, there's a player for the audio version of the transcript.

Transcript screen. This screen is where the researcher can read, select and apply codes to excerpts.

A large text version of the trasncript page

Transcript screen. Large text version

This is the code book page, like the transcript page, it features a left column with tabs to important pages in the software: project files, code book, coded data and notes. On the top page there's a tool bar with information about the codebook version, add a code button and a search bar. The main working area has the code book itself. The codes are grouped by parent codes. A color may be selected from a drop down to assign a color to that parent category. Parent, child and grandchild codes are differentiated by indents in the paragraphs.

Code book page. This screen lists all codes in the code book.

Note screen. Same screen layout as before. The working area here features two columns. First column lists all the files. The user can filter through all the files or project wide notes. On the second column, there's the list of notes. This column only shows notes from the option that the user selected on the first column. They are organized by transcript. Each note has the companion excerpt, a box with the note itself, who wrote it and what codes they assigned to the excerpt.

Notes page. In this screen the researchers can review notes left by themselves. Or, in case of the team lead, they can review notes from everyone in the team.

Coded data page. This page has the same layout as the past two screens. In the main working area, there's 2 columns. The first column lists all the codes with a frequency number. Codes may be selected to filter the data on the second column. In the second column the user can find the list of excerpts that were all coded with the selected code from the list. This column has the speaker, timestamp, the excerpt, all the codes assigned to this excerpt, if there's a note, an icon will show up, and the name of the person who coded this excerpt. If the users interacts with the note icon, the note assigned to this excerpt will display.

Coded data page. In this page the researcher can filter through the codes to view only the excerpts that include the code they selected.