My role
UX Designer
My role
UX Designer
Team
Christine Whittle (UX Research)
Josh Turk (UI Design)
Team
Christine Whittle (UX Research)
Josh Turk (UI Design)
Project timeline
2/2016 - 3/2017
Dates
2/2016 - 3/2017
Applied methods
Subject Matter Research, Stakeholder Interviews, User Research & Synthesis, Information Architecture, Design Sprint, Facilitation, Interaction Design, Wireframes, UI Design, Style Guide Documentation
The Prentke Romich Company (PRC) creates devices for augmentative and alternative communication (AAC), helping people who are unable to use verbal speech to communicate. Since 1966, PRC has been an industry leader of speech-generating devices with their picture-based language system. Considered a pioneer in the industry and having sold more than 100,000 devices globally, PRC has been largely successful for the past 50 years. However, over time, the device’s software settings (dubbed the "Toolbox") became outdated. For current users, they were inefficient and difficult, and for new users, they were intimidating and had a steep learning curve.
Because the company was redesigning the back-end, they also wanted a modern front-end to match. Our team was asked to overhaul the experience, focusing on speech language pathologists (SLPs) and caregivers as the core users. At the UX consultancy Iteration Group, I led the UX design efforts while my colleague Christine Whittle led the UX research efforts.
There is no “typical” AAC user: users may include people with autism, cerebral palsy, Down syndrome, aphasia, ALS, Rett syndrome, and others with a range of cognitive and physical abilities that affect their ability to verbally communicate.
While the industry has lauded PRC's picture-based language system in their devices, the software settings of the device itself were difficult to use, and have had no significant updates over the company's history.
As PRC has learned, those that use the device settings (the “Toolbox”) the most are not those with communication impairments. Rather, it’s the members of their support team who use the Toolbox to adjust the settings for them. This support team includes parents, caregivers, speech language pathologists (therapists), occupational therapists, physical therapists, and teachers. Of course, we had to keep accessibility issues in mind for the users with physical deficits, but we also decided we would first optimize the settings based on the specific needs of therapists and caregivers, who are able-bodied.
The Toolbox was a highly complex, highly powerful, and highly customizable system with seemingly endless options and settings.
No designer had ever worked on the settings. There was an apparent lack of content organization, information architecture, and design patterns. There was no library for the interface. There were also no tracked metrics or usage data. New features were tacked on haphazardly to react to individual feature requests.
Christine and I were completely unfamiliar with the topic, industry, and population segment of speech-language pathology, augmentative and alternative communication (AAC), and nonverbal children with physical or cognitive limitations. We knew we would have to immerse ourselves in the context of the product, speaking with therapists and experts, and learning how to use the device ourselves.
After the kick-off meeting, Christine and I conducted stakeholder interviews with product managers, developers, and sales reps to understand the history of the project, identify obstacles, and most importantly, determine PRC’s expectations and goals. We also took a training course on the devices and read through manuals and other training materials.
To get a better understanding of the current landscape and standards across AAC devices, I also did a competitive analysis of PRC's main competitors. It was certainly clear that the other apps looked better, but I felt there was an opportunity to better organize the functions and make the unique settings of PRC's devices more discoverable.
While it was obvious the Toolbox needed a facelift, we wanted to get more insight into how SLPs and caregivers were using it—what their needs, motivations and behaviors were, and what they liked and disliked about PRC's current device settings. We conducted interviews with screen sharing; we also visited a special needs school and attended a language conference to meet with therapists in-person.
While it was obvious the Toolbox needed a facelift, we wanted to get more insight into how SLPs and caregivers were using it—what their needs, motivations and behaviors were, and what they liked and disliked about PRC's current device settings. We conducted interviews with screen sharing; we also visited a special needs school and attended a language conference to meet with therapists in-person.
13 of 14
didn't understand more than half of the settings.
13 of 14
rarely went into the Toolbox after the initial device set-up.
14 of 14
said it was difficult to train others on the Toolbox.
After presenting the research findings, we facilitated a two-day workshop with the PRC team, where, as a group, we determined the guiding design principles, which user groups to focus on, the most common use cases, and a foundational information architecture. We also had the team participate in rounds of "Crazy 8's." Everyone contributing ideas not only gave us subject matter insights for the design, but also helped us align the team and increase the buy-in into the direction.
A keyguard is an optional plastic plate that sits on top of the device screen; it helps users with unsteady hands find the keys they want by providing a physical separation on the interface. In the middle of the design process, PRC told us that approximately 40-50% of users have keyguards on their devices.
PRC's devices have multiple grid sizes (the images below show an example of a 45-key grid). As you can see, the designs of the language screen (1) and the top-level menu for the Toolbox (2), were optimized to accommodate any of PRC's grid sizes (16, 28, 32, 64, 96, 128). However, the deeper level menus in the Toolbox (3) were not. Therefore, the keyguard has to be lifted by the caregiver or therapist to access the buttons (4). This can be cumbersome as it requires some effort, since the keyguard is snapped firmly into place.
(1) Language Screen with Keyguard
(2) Main Toolbox Screen with Keyguard
(3) Second Level Menu with Keyguard
(4) Keyguard Flipped Up
The video below shows how long it takes to change one setting on a device that has a keyguard.
While we couldn't account for every grid size for the Toolbox, we felt we could at least make it easier for the more commonly used settings to be accessible without lifting the keyguard.
The space above the language keys, where the AAC user's sentences are displayed (aka the "text message area"), is not utilized when in the Toolbox menus. We thought we could use that space for shortcuts or a "Quick Menu."
(1) Text Area used for showing the words pressed
(2) Text Area in the settings screen, which is not being used in this context
Looking at our red route analysis, we prioritized features in the "Quick Menu," surfacing only the most used items there as shortcuts.
Creating a “Quick Menu” for shortcuts (such as "Volume" and "Adding a Key") would give caregivers and therapists easy access to the settings they use most frequently. We also gave them the ability to customize their shortcuts, since we found that everyone uses the settings slightly differently, depending on their teaching methods.
For the rest of the screens, I relied on familiar patterns from current touch devices, since all of the users we spoke to used smartphones on a daily basis.
After getting approvals from stakeholders on the wireframes, we did two rounds of usability testing. We wanted to make sure the design was headed in the right direction, and also answer questions that the PRC team was unsure about.
The prototype can be viewed here.
In the old design, the shortcut menu (or “Quick Menu”) was only accessible via the home button of the device. In the new design, I prioritized the shortcut menu, moving it to the top right. More advanced settings (the Toolbox) could be accessed in the Quick Menu.
The Quick Menu gives easy access to common functions, such as volume and adding a vocabulary word, but it is also fully customizable.
Based on the research, I re-organized the Toolbox settings into groupings that made sense to users. I also separated the groups using a tab layout.
The original design had users going three to four levels deep to change settings, and they would often get lost. I used a modal to help keep users in context; they can easily navigate back to what they were doing before.
Working closely with our UI designer, Josh, we established a style guide that PRC's development team could follow to ensure consistency throughout all screens. Here are some screens from the final deliverable.
Immersing ourselves helped us learn a completely new domain
When we started the project, we were completely unfamiliar with users of AAC and the world of speech language pathology. Speaking with users, experts, and attending a special needs school and a speech conference was really valuable, and by the time we reached the usability testing phase with SLPs, we could easily traverse the lingo and better understand their needs.
An extensive research phase upfront saved time later in the process
PRC was on board with our proposal for a two-month long research phase. Spending the time in the beginning of the project to understand user needs helped us with a more focused design, and it showed in the usability testing.
Conducting usability testing early and often
Oftentimes, project teams conduct usability testing towards the end of a project, which can be time-consuming if you have to make major adjustments. We scheduled the first round usability testing after the initial set of wires were complete. From there, we were able to get signals on if the design was going in the right direction. We then adjusted our designs and scheduled another round later in process.
Involving stakeholders improved collaboration and consensus
Working with a client who had never had in-house designers or spoken to users, we wanted to be sure that the team was comfortable with a user-centered design process. Keeping the stakeholders informed along the way as we did our research, and involving product, engineering, sales, and subject matter experts in a design sprint not only made for a better design, but also for complete buy-in from all team members on the direction of the design.
More Projects
Bringing a networking startup's roadmap to life.Networking Platform
Keeping users on top of their tutoring.Education App
Modernizing membership for a distinguished institution.Membership Website