Robert Oxford

I started this app development with the Design Thinking framework that is used to focus on users, challenge assumptions, redefine problems, and create testable solutions.

Design Process: Research –> Define –> Iterate –> Prototype –> Test

Beginnings: Primary research, user interviews: I interviewed five people about their thoughts about museums, museum tours, and museum apps. I collected this data and used it to understand the user journey, from using an app to booking a museum tour, and to understand pain points that interrupt their happy path. One person's comments on usability and accessibility stood out as an important consideration about a potential audience that has been historically marginalized and ignored in technology design: the deaf and hearing impared. I then used the data to create a persona.*

This data yielded a useful Problem Statement: Jerry is a hearing impaired museum lover and uses ASL and who needs ASL interpretation during museum tours because there are many museums that do not offer this service.

From this research, I found a design opportunity: how can ASL users take museum tours when an interpreter is not available on-site?

I then used a competitive audit, a form of secondary research, to understand how large and small museums provided accessibility options for patrons who are hearing impaired. I analyzed tour apps for major and smaller museums for ASL accessibility.

I could then revise my problem with more considerations from audit: I found a glaring problem. Museums are notoriously limited in addressing accessibility needs especially with in-person tours. Museum apps did not allow the ASL community to book an interpreter as part of a tour and there were many pain points for hearing impaired users along the way.

I could then draft a hypothesis which took the form of "if we implement the SOLUTION it will improve the USER EXPERIENCE at in crease BUSINESS METRICS": For my app, I hypothesized that:

I then entered the Ideation Phase. I used a common method in brainstorming by asking "how might we?" to try to answer the hypothesis.

Here, I started to map out the user journey:*

I then used a pencil and paper to create iterative wire frames as a way to solve the problems above that I continued to modify throughout the design process.

I then used Figma to create low fidelity wireframe versions of the app to test functionality, user navigation, and information architecture (IA).

I then settled on my first prototype which you can access and interact with below.

Then, with five participants, I began usability testing* with this prototype for functionality, including using a System Usability Scale. The goal was to find and address problems with KPIs like drop off, errors, and time-on-task. Below are the unmoderated prompts for each participant. Click paths, observations, and quotes were recorded along with measuring the difficulty of each task as participants completed them.

Priority Zero insight required fixing navigation functionality so that users can get out of a loop that prohibited them from exiting to a previous screen.

Priority One insights required considering how to streamline the process of selecting an interpreter so that it's a little easier to search.

Priority Two insights would be a way to implement better selections for cities and museums.

With these recommendations, I improved the app design based research insights:

1) Home screen cleaned-up to emphasize the main choices in using the app (requesting an ASL tour and signing-up to sign). Location and museum search were removed from the home screen.

2) Museum search and location were moved to the screen after selecting Request ASL Tour as part of the booking process.

3) "Signers in your area" was changed from a carousel selection to a selectable, scrollable list

Notes about the project and reflections: MuseumSign was born out of student work for the Google Professional Certification in User Experience Design and is a work in progress. Inspired by the course, I was interested in Accessibility and Adaptive Technologies (AT), which are a segment of the industry that has long lagged behind in app development. MuseumSign's intervention regarding these inequities is to provide greater access to cultural institutions for those who are hearing impaired. Because users required AT or interpreters, and given the limited scope and resources of this project, more user testing is required to be certain that the product is providing a value for the hearing impaired community. This student work simply cannot scale to the right level at the speed required to account for the many users in the ASL community the app is intended for. Reflectively, this is a critical shortcoming in the app's development.

If this project were in a funded, team setting, the first step would be to recruit ASL and hearing impaired subjects for user journey and in-depth interviews at the beginning of the project with the tools needed to succeed in interviewing with the hearing impaired. Second, ASL and hearing impaired researchers and designers would be necessary parts of the team. Finally, usability testing would be conducted with the ASL community and the hearing impaired. It was regrettably impractical to do this due diligence as a student.

In an illuminating podcast episode from Awkward Silences, part of User Interviews, Samuel Proulx argues these points with clarity, urgency, and integrity. I am inspired by the push to design for AT and historically marginalized communities and endeavor to follow this path in my career as a UX Researcher.