There were 58.5 billion robocalls in the US last year, up 22 percent from the year prior. The average American receives 171 spam calls each year, which doesn’t include other non-wanted phonecalls from non-spam callers. These unwanted calls waste time and cause frustration to millions who did not give consent to receiving them.
To address this problem, we designed a mobile app to help users control who can call them. We did this by creating a firewall that only allows calls to come through from your contacts, yet still giving non-contact callers the option to send a request, much like a “friend request” on a social media platform.
The main types of research I did were a Card Sort, Usability Test of the previous designs (see below), and Competitive Analysis. I also researched iOS Usability Guidelines to ensure the designs followed standard practices for Apple applications.
The main takeaways I gathered from the research were as follows:
• navigation menu felt overwhelming
• PIN Codes and Call Control Configurations were hard to find
• no information for rejected calls
• users aren't able to decline whitelist requests
• competitor applications aren't user friendly to non-tech savvy users
Based on the research I conducted in the previous step, I discovered our most important design opportunity: How might I restructure and design this app in a way that doesn’t overload the user, yet gives them ease to their necessary actions?
I started by creating the app navigation flow and then started sketching out the initial designs. I experimented with various layouts but in the end, I decided to go with these sketches as a base for my first iterations.
These are the key things I kept in mind with these designs:
• giving the app a tab bar helped alleviate the problem of cognitive overload the previous menu gave users
• giving the app an Apple native feel to it would help users intuitively understand the flow/navigation better within the app
• the stakeholder requested adding a keypad section to see how it performed in the next round of testing
Once I finished the sketches, I moved onto wireframing out the core screens and then turning them into mid-fidelity designs for the next round of usability testing. I made a small change by creating a toggle section on the whitelist page instead of it populating at the top. This was changed after considering users might have a lot of requests that will block their view of their contacts below.
In the second round of usability testing, I used these new mid-fy designs.
These are the key insights I found:
• users still were unsure where the whereabouts of the call configuration settings and PIN codes were
• whitelist requests needed to be in a more prominent location for user ease
• users wanted an option to whitelist a rejected call from their recent calls
• users felt they would not use the keypad feature, and instead would use their native Apple keypad
• users wanted the ability to schedule calls with non-whitelisted callers
After the insights I found in the previous round of Usability Testing, I adjusted the designs to accommodate a lot of users' pain points. The main things that changed were that I removed the keypad feature and added a homepage tab that would house the prominent features of the application that were previously in settings. A call scheduling feature was also included per the CEO's request from user interest.
For the Home screen, I knew that it was vital to have quick actions for the users based on the research I conducted. The following features were chosen on this page due to their importance and/or rate of use.
For the Recents page, I focused on giving it a very familiar feel to what native Apple users are used to. By doing this, they will intuitively know the flow and navigation better within this section.
Much like the Recents page, I focused on giving the Whitelist page a very familiar feel to what native Apple users are used to so that they understand the flow/navigation.
The Alerts page was an addition that was not in the original plans. In the original and mid-fidelity designs, there was only the feature of whitelist requests which were not on its own prominent page. However, due to research, it was made clear that it needed to be a prominent feature on its own for easy viewing and acceptance.
The Voicemail page followed the same idea of sticking to the Apple native feel for users to know the flow/navigation.
I created empty states for the Alerts, PIN Codes, Recents, and Voicemail pages to ensure users knew that they didn't have anything available to be shown. A blank space might confuse users by thinking the app isn't populating the information.
