CallStop
Type:
iOS Application
Duration:
Dec 2019 - Mar 2020 | 4 months
Role:
Sole UX/UI Designer
Tools Used:
Sketch, Figma, Gloomaps, Optimal Workshop

THE PROBLEM

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.

SOLUTION OVERVIEW

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.

Research & Discovery

Primary research

• Usability Testing

• Card Sort

• Heuristics Evaluation

• Prototyping

secondary research

• Competitive Analysis

• iOS Usability Guidelines

Stakeholder interview

I met with the stakeholder to ensure that we were both on the same page with the expectations and scope of the designs of the product. During this, I also met with the main engineer of the app to talk about any technical constraints that I might need to be aware of. After speaking to both of them, it was clear that they were fairly open to small or big changes if the research showed there was a necessary reason for it. There were two main takeaways from this conversation was that the stakeholder wanted which were to:

• Test to see if the keypad section of the application needed to be a prominent feature.

• Try to avoid having a user dashboard since Apple's native call application doesn't have one.

card sort

Next I conducted a Card Sort exercise with non-users to assure that I wasn't getting biased information from users that know how to use the app from prior experience. I found these candidates by first doing a screener survey and collecting their emails to send the Card Sort to.

Card Sort Categories and Reason Behind Them

To assure that I would have more of a cohesive result, I chose to preset the categories for the test takers. I wanted to do this so that I could get a good idea of where people expected things to be from a general overview of the sections. Because the navigation on the initial design was overwhelming, I was leaning towards doing a bottom tab bar navigation and these categories gave me a solid base to work from.

Usability testing (round 1)

This step was the one I received the most insights from. I conducted a round of usability testing of the initial designs, with ten people over Zoom through screen sharing on the original designs. I chose them from a wide variety of backgrounds, demographics, and age because the app's data from the first launch showed a wide age range. Although the initial data was skewed towards an older demographic, I didn't want the insights to be skewed from interviewing only their main age demographic. I gathered five users that have been using the app prior, and five users that had not ever interacted with the app. I did this because I wanted to see the pain points of native users and the pain points of new users. Below are the insights I found along with an overview of the original designs I used for the testing.

Native Users Main Pain Points

• The navigation menu felt overwhelming with information. Users would spend a lot of time looking at the menu to find what they were looking for.

• Only 3 out of 5 users could find both PIN Codes and Call Control Configurations.

• All five users wanted to be able to see how many calls were being rejected and the information on them.

Non-Native Users Main Pain Points

• The navigation menu felt overwhelming with information. Users would spend a lot of time looking at the menu to find what they were looking for.

• Only one user could find both PIN Codes and Call Control Configurations.

• Whitelist page contained photos for each contact which users felt was distracting.

Additional Insights Found

• Whitelist's request page does not give users the ability to decline requests.

• Next to every number, there is a call icon that users miss-tap.

• The majority of users wanted a way to navigate contacts without typing in the search.

• Users in the older demographic, from both sets of interviews, had a harder time getting used to the layout and navigation of the application.

competitive analysis

In this space, the only main competitor is another app called Robokiller, which I downloaded and used to get an understanding of the competitor. I spent about a week using the service, and also went through the reviews of the app, which is rated a 4.6/5 on the App Store. I did this so I could put myself in our average user's shoes, and I read the reviews to see if there was any feedback that their users gave that could correlate to CallStop. In the end, I found the app gave a similar feel to a native Apple product, however, the app seemed aimed more towards someone more tech-savvy, than someone who doesn't have much experience navigating apps. I took these things into mind moving forward in the "Ideation" phase.

iOS usability guidelines

My last step in the research phase was to get a better understanding of the guidelines for designs on the App Store. I focused on learning the exact pixel sizes of icons, navigation bar, tab bar, and home indicator. I read through all of the guidelines on the site, here, to ensure I wouldn't waste time on designs that aren't pixel perfect.

Ideate & Define

design opportunity

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?

App navigation

With the design opportunity in mind, I moved forward into the "Ideation" phase. The first step was to take the research I found and figure out a way to break things up in a tab bar. I drew a lot of research from the Card Sort when creating this map.

ideation

With the design opportunity in mind, I moved forward into ideation. I experimented with various layouts that would help users find actions easily within the app. In the end, I decided to go with these sketches as a base for my first iterations for the following reasons:

• Giving the app a tab bar helped alleviate the problem of cognitive overload many users were experiencing with the prior design navigation.

• 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.

Build & Refine

OVERVIEW

After the Ideation process, I had decided on 5 main features for the app: recent, whitelist, keypad, voicemail, and settings. Below is an overview of my building & refining process for the app's interface and navigation before the next round of testing.

Wireframes

My first step in the Build and Refine process was to start wireframing out the designs based on the sketches created in the prior phase.

There were a few small changes made to the original sketches such as 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.

Mid-fy designs

I began to start on the mid-fidelity designs for the next round of usability testing. I decided to test these designs instead of the wireframes due to wanting the most accurate insights as possible. I worried the underwhelming sight of the wireframes would skew the data.

After multiple iterations to improve the look before testing, here are a few screens of the final iterations chosen for the next step.

Usability testing (round 2)

The last step before moving into high fidelity design was to conduct the next round of usability testing on the newly created mid-fy screens. Like how I did in the prior round, I tested ten people over zoom. I kept the same demographic constraints and kept the same five native users, but five new non-native users to ensure I wasn't getting skewed data from only people who saw the previous version. The following were the pain points I observed:

Native Users Main Pain Points

• Users were slightly confused about the whereabouts of the call configuration settings and PIN codes.

• Only 3 out of 5 users could find the location of the whitelist requests. However, all of them voiced that it needed to be more prominent and easier to find because it's such an often-used feature.

Non-Native Users Main Pain Points

• Only 2 out of 5 users could find the locations of call configurations and PIN codes quickly.

• 4 out of 5 users were able to find the whitelist requests section however, it took them a few seconds to find it/think about it.

• On the whitelist request section, older users were confused about whether the “x” meant to decline a request or just hide it from view.

Additional Insights Found

• Users wanted an option to whitelist a rejected call from their recent page log.

• Nearly all users voiced that they do not think they would use the keypad feature over the one that is natively on their iPhone due to ease.

• Users want the ability to schedule calls for meetings with non-whitelisted callers. Upon further research users also mentioned they would love to see their schedule of these calls.

High Fidelity
Process

OVERVIEW

After multiple rounds of user interviews and the other forms of research I did in the 'Discovery' phase, I was ready to finalize the high fidelity designs. During this portion, I had to make some adjustments to the previous designs to reflect the insights I found in the last round of usability testing.

meeting with stakeholder

After the insights I found in the last round of testing, I had a meeting with the stakeholder and the lead engineer to discuss the findings. Three main takeaways came out of this conversation which was the following.

• Users voiced they did not see themselves using the keypad over their Apple native one, which meant that a tab in the tab bar wouldn't be touched much. Because there were a lot of other things that took priority over this feature, we decided to scrap the keypad tab.

• Users needed a way to view their whitelist requests easily, so we decided to replace the keypad tab with an Alerts tab for notifications.

• Many users were confused about the locations of the Call Forwarding Configurations and PIN codes, so we decided to create a user dashboard/home page to help users access features that are used often and of high importance.

• Due to interest in the call scheduling feature, the stakeholder wanted to add the ability to create an event, either call scheduling or a general event, to give the app a leg up on their competition.

app navigation update

My first step in the high fidelity designs was to rework the app navigation since we were changing multiple things within it. The following these were the major changes made:

• Adding the new "creating an event" feature.

• Get rid of the keypad.

• Creating a user dashboard/home page.

• Create an alerts page for notifications.

Typography & Color Palette

Now that I had the app structure down with the new updates, I wanted to finalize the style guide. To the right is a section of the style guide with the chosen typography and color palette.

This deep blue was chosen as the main brand color because it conveys trustworthiness, safety, security, and confidence. All of which were vital for the user to feel while user CallStop.

This yellow was chosen to convey positivity, happiness, and also safety. This color is an accent color to the brand color to cohesively work together to convert an overall feel of trustworthiness and positivity.

Inter was chosen as the typeface because it is easy to read since it is a sans-serif, and it conveys a more youthful/fun vibe while also being professional. It's a bit softer yet similar to Apple's SF Pro typeface.

Final screens overview

After multiple rounds of iterations and small tweaks, I finally reached the end of this sprint. The photo on the right is a high-level view of some of the finals iterations. See below to see some of the main final features.

Final High Fidelity Designs

OVERVIEW

The following are the main high fidelity designs along with their key features.

Home

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.

Feature One: Call Filtering Controls

This feature gives users the ability to control whether all or only their whitelisted callers can get through to them.

Feature Two: View PIN Codes

This feature gives users the ability to quickly view already created PIN codes or create a new one. PIN Codes give non-whitelisted callers the ability to get through, which is vital for emergencies or businesses trying to reach them.

Feature Three: Create an Event

This feature helps users keep track of their busy schedules. From a scheduled phone call to a casual lunch date, users don’t have to remember a thing, because the app will for them.

Feature Four: View Upcoming Events

This feature gives users an immediate view of their upcoming schedule as soon as they open the app. This will make it quick and easy for users to get a snapshot of their upcoming schedules.

Recents

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.

Feature One: Call Insights

This feature gives users the ability to easily see their recent call activity. The colors and symbols give users the ability to quickly identify what type of call it was. The red indicates a missed call and orange indicates a rejected call.

Feature Two: More Information

The more information icon on the far right of each call gives users the ability to pull up additional actions. These actions are call back, add to whitelist, add number to an existing contact, share number, and/or block caller.

Feature Three: Recents Toggle

This toggle gives users to ability to quickly view specific calls such as missed or rejected.

Feature Four: Delete Call

Users can delete calls by either swiping left or clicking edit, so they can declutter their Recents log.

whitelist

Much like the Recents page, I focused on giving it a very familiar feel to what native Apple users are used to so that they understand the flow/navigation.

Feature One: View Contacts

The whitelist page gives users the ability to view all their contacts. These contacts will be able to reach them at any time.

Feature Two: View Specific Contact

Users can easily view specific contacts and are taken to their independent contact page with actions the user can take.

Feature Three: Search

The search feature gives users the ability to quickly find specific contacts they are looking for.

Feature Four: Main Letter Directory

This feature lets a user quickly click the main letter of a user's name to quickly be taken to that section of their contacts. The app automatically sorts by the first letter of a contacts first name, however, this can be changed within settings.

ALERTS

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.

Feature One: View Whitelist Requests

When a non-whitelisted caller calls and can not get through, they have the option to send a whitelist request to the user. This will either be by text or voice message. The user can view these in their alerts, and accept or deny them to be added to their whitelist so they can reach them in the future.

Feature Two: View Upcoming Events

Users will receive an alert about their upcoming events or scheduled calls so they never forget them. They can adjust these notifications in settings.

Feature Three: Search

The search feature gives users the ability to search for a specific alert.

VOICEMAIL

The Voicemail page followed the same idea of sticking to the Apple native feel for users to know the flow/navigation.

Feature One: Listen To/View Voicemail

Users can only see voicemails left by whitelisted callers so that they are not bothered by spam voicemails. Users can either listen or read the transcript of the message for ease.

Feature Two: Quick Action Buttons

When a user clicks on an individual voicemail, they have the quick action buttons which are speaker, voicemail, and play/pause.

Feature Three: Swipe Bar Control

When a user is on an individual voicemail, they have the swipe bar control for the voice message so they can easily navigate the message instead of relistening to the whole thing.

Feature Four: Delete Voicemail

Users can delete voicemails by either swiping left, or clicking edit, so they can declutter their voicemails.

Empty state screens

The empty state screens were created to ensure that a user isn't confused when their alerts, PIN codes, recents, and voicemails are empty.

home

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.

recents

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.

Whitelist

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.

alerts

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.

voicemail

The Voicemail page followed the same idea of sticking to the Apple native feel for users to know the flow/navigation.

empty states

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.

Problems Encountered

research differed from stakeholder's wants

Initially, when I first spoke to the stakeholder and they voiced that they wanted a keypad and no dashboard, I was a little concerned. I was concerned because adding the keypad was another feature that would need a whole page dedicated to it, and I felt the dashboard would be the most user friendly. When the research came back and verified my initial thinking, I was worried about a push back that would hinder the user's experience. However, I made my case for the user and tried to put the stakeholder in the user's shoes, which helped persuade him.

Information overload

This app had a lot of information an features within it that were hard to intuitively place since they are not your everyday features. It pushed me creatively and forced me to understand the user's mind. In the end, I think that that the multiple rounds of usability testing/user interviews helped me to deliver.

New Feature right before high Fidelity

When the new feature got added it was a bump in the road because I had to rethink my designs and flows. I was working constantly with the lead engineer to assure that the new feature and its designs were within the technical scope of our timeline. In the end, the teamwork and communication brought up to the result on time.

Next Steps
Test New feature & hifi designs

Now that the designs are done for this version, I am very excited to see the data on how this does. I am curious to see conversion rates are, and how the new feature performs.

Dark mode

The second thing that I am aiming to do next is to create a dark mode. This, however, will be after testing out the new feature and the new designs to ensure that I am not backtracking. I want to make sure that we have a good basis of overall designs for the app before I do this so there is no time lost.