L!SNEN: UX Design Case Study
An assistive app for the deaf and hard of hearing community.
Lisnen is a form of assistive technology for those who are deaf or hard of hearing (DHH). Our task was to create an app that detects important environmental sounds as they occur, and alerts individuals through the phone’s vibration and flashing light.
Product: Native app for iOS and Android
Design Sprint: 3 weeks
Tools: Figma and Principle
Our UX team surveyed 16 people and interviewed 6 people with moderate to profound hearing loss. Through our research we were able to get a greater understanding of the lives of the DHH community and how they overcome obstacles related to living in a hearing world.
Getting To Know Our Users
From our surveys and interviews, we realized that we had 2 similar but distinct users: our younger user Sara, and our older user Jack. They both have common needs and frustrations, however they have some distinct differences: Sara, our younger user enjoys engaging with new technology and wants something that is customizable that can pair with other devices, whereas Jack really needs something that is simple and intuitive, as he is older and less comfortable with technology.
We needed to keep both of our core users in mind while designing the app.
After getting to know our users needs and frustrations, we wanted to know what solutions they are currently using. There are a number of apps and devices available on the market, however throughout our interviews and surveys we kept hearing that users were not satisfied with available solutions.
Our UX team downloaded the available competing apps and found that their UI was not intuitive, they were difficult to use, and they didn’t reliably work! We realized that there is a gap in the market for a functional, well designed alerting app.
After completing our research, we were able to pinpoint the main qualities our users wanted to see in an app:
- Ability to customize alerts
- Intuitive and easy to use
- The app should blend seamlessly into their lives and habits
We did a whiteboard exercise to look at which features were essential to our app, and which features our users could do without.
We included all of our must-have features in the app, and also decided to include one nice-to-have: the setup tutorial. This would make the app easier to understand for our older user, Jack.
We began with low fi paper sketches which allowed us to quickly explore many options before moving on to mid fidelity wireframes.
Mid-Fi Prototype & Testing
We went through 5 versions of mid fidelity wireframes and 3 rounds of prototype testing before we landed on a final version we were happy with.
As shown in the below journey map, the most notable improvements were made in onboarding and sign-up/subscription.
V1 users felt that the billing screen was off-putting, as this was the first time they were made aware of the subscription based model. We needed a smoother introduction to payment, and give users a reason to subscribe before asking for their card details.
We changed the title from “Billing” to “Subscription”, which sounds less imposing. In addition to removing needless billing fields, we added a welcome screen before asking users to subscribe. This introduced the subscription model, and gave users an option of “show me around” to see more of the app before subscribing.
Users who select “show me around” on the welcome screen, are taken through a brief tutorial and mic test where they can see real sound waves and gain confidence in the app before subscribing.
Technical Road Blocks
During the testing phase, we were struck by many technical questions we hadn’t previously considered. This was a major road block in our work.
With Android, alerts would be able to take over the phone’s screen and vibration however iOS has a strict operating system which would restrict some functions. The following iOS limitations threatened Lisnen’s ability to function as we had imagined:
- 3rd party apps not allowed access to system functions
- Alerts cannot take over screen (push notifications only)
- 3rd party apps are unable to have long-lasting notifications (30 seconds maximum)
- Limited customization allowed
In all honesty, we started to panic. We thought there was no way this was going to work as an iOS app — which would be a big problem as half of our users are on iOS.
After a lot of online research and consulting our local app development expert, we were able to come up with a functional solution that would allow Lisnen to fulfil it’s purpose for iOS.
Lisnen’s alert for iOS would come in the form of a phone call. When a sound is detected, the Lisnen app would send feedback to their server, which would then place a phone call to the user’s phone. This would allow a full screen take-over and would keep alerting the user until the phone call is picked up.
The downside: this solution doesn’t work when the phone is offline. When the phone is offline, it will receive a push notification with 30 seconds of vibration. Although not ideal, this is only a minor hinderance; research indicated that users would mainly use Lisnen in their home where people tend to be connected to wifi.
The Final Product
After Gerald, our UI designer, worked his magic on the wireframes, Jamil and I began working on the high-fi prototype.
Using Principle, we added animations to bring the app to life.
Jamil animated the onboarding characters which gave the app a welcoming and friendly personality.
I animated the sound wave so that it appears to be picking up environmental sound. Once the app is developed, the sound wave will move in real-time, reacting to actual sounds.
Due to the technical limitations of iOS, we recommended that the MVP should be presented as an Android app. This will allow Lisnen to get a solid user base with our ideal Android functionality before rolling it out for iOS. Other future considerations would be pairing the app with wearables such as smart watches and smart home devices.
When I first started working on the Lisnen app I was focussed on the visual appeal and user interactions, but when I reflect back on the project, our greatest acomplishment had been understanding and overcoming the technical constraints of the operating systems. The experience really made me realize that, as a UX designer, I can’t always take the client’s word for it — I need to make sure I have done my own technical research to know that the technology will work as intended.
If I could do it all again, I would have looked into the technical considerations earlier on avoided our scare mid-way through the project. I am very happy with our Android app and, although our iOS solution isn’t ideal, it is still a functional solution to assist the DHH community.