Design new interactions for visually impaired people to interact with digital displays

HCI

UI/UX Design

ux research

BrightPage Tech

2022

Project brief

The founders at BrightPage had developed a new way of reading, called BrightScroll, which enabled users to experience special text movements that mimics natural eye movement, without any squinting or zooming. My task in my time at BrightPage involved showcasing BrightScroll technology in Mobile and Tablet form, as a PDF Reader, as well as to develop interactions for the Reader app. I successfully interviewed people, went through multiple cycles of the design thinking process and delivered ideated and designed outputs to the development team at the end of my project

timeframe

5 months

industry

Education Technology

01 context

Text on screen is typically presented like it is ink on a page. The potential of dynamic, powerful, electronic displays is not being harnessed. Reading can be a more engaging and efficient experience for everyone, but a new approach is especially needed for the visually impaired. My role at BrightPage Technologies involved spearheading the design and testing of a new way of Human-Computer Interaction involving visually impaired people as the end-users.

02 Problem statement

I was brought onto the BrightPage project to create new interactions and to package up BrightScroll technology into the form of a PDF Reader fit for Mobile and Tablets. While BrightPage already had a functioning Website and Mobile Site prototype, I was responsible for designing the interactions for a native app and to improve BrightScroll’s existing interactions. As such, my first action as a User Experience Designer was to build upon the Problem Statement presented to me. As the sole member of the Mobile Design team, I saw fit to use Figma so I could communicate with the CEO and present my findings more easily.

My second step in my Plan of Action was to create a User Journey and understand how it would reflect on the designs and interactions I would be making for Mobile and Tablets. While simple, the user journey allowed me to segue into BrightPage’s existing websites and create a set of Observations as well as create a set of First Impressions for where I realised pain points existed and how I might design for them. Both of which, are documented below.

I had originally compiled a list of questions to keep in mind as I navigated the BrightPage mobile and desktop websites for the first time. Furthermore, I noted down the issues the current website might have, and how to design to solve those particular pain points. I moved further to compile a further list of questions now that I had a goal in mind, so as to lead me towards an action I could work towards. This is documented on the next page.

02 research

The process of noting down my observations and ideas(as they came to mind)allowed me to come up with a set of interactions and gestures that I could use for the native mobile and tablet applications. These sets of initial observations, pictured below, showcase my thinking process. As stated, my key responsibility for this project was to design the controlling interface for the PDF Reader. One of the key issues to address during the design of the controlling interface for the visually impaired was that it would not be good design practice to put small buttons on a digital screen. Furthermore, it would clutter up the screen, reducing the control area and leave much room for error. As a visually disabled person myself, I was familiar with the research done on RSVP Readers and how a set of gestures are universally transferrable over devices for ease of use and remembrance. A Paper from the ACM CHI Conference 2018 informed my research on what kind of gestures and interactions I would be designing for.

03 components

These were the components designed for the Mobile Application Views.

04 Designing the reader

I immediately set about Desiging and Naming core UI Components I would be using and iterating over through the Design Cycle. I have documented ideations for the mobile portraits as well. Once I decided to use the set of unified gestures for the controller interface, I decided to research different ways controller interfaces could be, well, interfaced with. It was important that the interface have these primary features:-

Load PDFs & Parse Weblinks

Change the speed of BrightScroll

Pause/Play BrightScroll

Cursor Control for Words, Sentences and Paragraphs

The Navigational interface was at first, designed with swipe gestures, for ease of use. However, after a feedback session facilitated using Maze with a closed-beta user, I iterated to using a joy-stick controller mechanism. Where Right/Left would be used to move the cursor, and Up/Down would be used to change sentences in the document, moving immediately to the word after the period. If the user wanted to change the paragraph, all they had to do was head to the PDF Preview page and select the desired paragraph.

04.1 speed controller

This is a first-iteration of the speed controller as well as the of the controlling interface. Along with this controlling interface, first iterations of the Speed Controller and PDF Page views were also made, which were also subjected to a feedback session with the founders. After a feedback session with the founders, the controlling interface was moved into a navigational drawer that could be hidden when the users asked for it.

04.2 oops button

After the feedback sessions from the Founders, and testing the navigational controller interfaces with closed-beta testers, it was time to design iterations for the speed controller and iterate on the design for the controllers based on feedback, whose interactions were one of the key problems with the Desktop and Mobile Websites. Numerous designs were created before the final designs were sent to the development team. We also decided to include an Oops Button in the controller interface, which would allow the user to reverse the playback of BrightScroll by 10 seconds. This was incase the user missed some of the text as it flowed past, or if they were still adjusting to the new speeds they’d picked.

04.3 Iterations of the speed control widegt

The speed controller was one of my primary responsibilities during the project. A key part of designing the controllers was deciding how it would function and operate. It was important to make sure that the symbols used were easy for visually disabled people to spot and understand, which is why the initial idea was to use colours to guide using the speed controller. The symbol of the rabbit was used to denote increasing the speed, while the tortoise was used to denote decreasing the speed. This choice was based on the Aesop's Fable, The Rabbit & The Tortoise.

After feedback from the founders, and from our closed-beta testers, I pivoted to testing a variety of different speed controller designs, before deciding on the final widget for handoff.

05 final designs & interactions

You can check out the Figma Files for my BrightPage Designs here, and video playbacks of the interactions here. My controller interface was used for the final designs of the application, which can be found here. If you want to test BrightScroll on Desktop, you can request access from the Founders here. If you want to see how the speed controller iterations look in the context of the entire Mobile view, check the appendix here.

Appendix - prototypes tested