Malwarebytes for iOS 4.0

Product Design
Lead Designer
Jul 2019 - Oct 2019
About a year after Malwarebytes for iOS shipped, Apple started letting apps with DNS-redirect technology back into the App Store. This was the perfect opportunity to add more robustness to our app's Web Protection feature. With DNS-redirect, we can now protect users on all applications, not just on Safari.

Adding in a more robust Web Protection feature proved to be an opportunity to address some usability issues with the original design, specifically with the navigation. The final design utilized a more semantically tight conceptual model to simplify the entire information architecture. We also worked out some other usability kinks along the way.
Final designs in device mockups

Advanced Web Protection

The existing web protection relied on Safari content blockers to protect users; it only worked on Safari. The new Advanced Web Protection features DNS-redirect. When a user or an app tries to access a suspicious site (the criteria is based on proprietary Malwarebytes technology), we block the site and serve up a block page, detailing the type of threat and providing users with an option advance to the site against our suggestion.
Advanced Web Protection

What’s the challenge?

How do we add a new feature that’s similar to an existing feature? I could add in another module to the dashboard. But this method seemed clunky. It also pushed the free features down. This would be problematic on smaller devices such as iPhone SE. I knew there was a better solution.
Adding another dashboard module

An opportunity arises

I had a lightbulb moment; I remembered seeing old usability tests showing how whenever we asked users where they would go to report a fraudulent number to us, users would tap on the dashboard module most closely related to the task.
heat maps from existing usability tests
Previous usability tests
These heat maps indicated an opportunity to append actions and attributes related to customizing or editing features to each protection module on the dashboard. This not only allowed me to append the Advanced Web Protection to the existing Web Protection but also to simplify the navigation.

The existing navigation separated out objects, actions, and attributes into disparate places. This added complexity. Users would have to go to to two different places to turn off a protection module and edit a protection module.
Existing objects, actions, attributes
For call protection, users would toggle off the protection on the dashboard, go to customize protection underneath the toggle to customize the level of protection, and go to Allow on the bottom tab to allow a number we incorrectly flagged as fraudulent.

Grouping objects, actions, and attributes

Instead of adding yet another protection module called Advanced Web Protection on the dashboard, I decided to group all the objects, actions, and attributes together, with an object-oriented interface.
Existing v. new dashboard

Simplified dashboard and navigation

Just as in the current dashboard, the new dashboard would still contain the 4 protection modules - web protection, call protection, ad blocking, and text message filtering. However, the actions and attributes of each protection module would be subsumed under each of these protection objects.
Instead of using toggles, I opted to use a text label to indicate protection module status. I appended a chevron to signify more content and actions to which the users have access.

The actions and attributes of each protection module would move from the dashboard and the bottom navigation into its container object on the dashboard. Thus, the bottom navigation can now be simplified into 3 items - dashboard, help, and settings.
Existing grammar model into new grammar model

Actions and attributes

Just as in the current dashboard, the new dashboard would still contain the 4 protection modules - web protection, call protection, ad blocking, and text message filtering. However, the actions and attributes of each protection module would be subsumed under each of these protection objects.
The Web Protection object now holds the option to toggle on and off the protection as well as customization actions such as Web Allow List.
Instead of splitting up Call Protection actions into separate locations of Allow and Block on the bottom nav, both actions can how live within the Call Protection page.
Customizing Call Protection attributes - choosing warn or block for different types of calls and setting spoof call sensitivity - is no longer on the dashboard. It now lives within the Call Protection page.
Existing Call Protection and SMS filtering modals
The same Allow and Block list for Call Protection and Text Message Filtering can now exist inside their container objects, thereby reducing awkward and lengthy copy that was used in the original design to indicate this.

Validation testing round 1

With this proposal in hand, I had planned on getting feedback from the product manager and engineering counterparts. However, I had enough time to run a quick test. Thus, with the help of the UX Researcher, we set up a quick round of testing to validate the designs.

One of the biggest concerns I had was whether moving “Allow” and “Report” out of the bottom navigation and into the dashboard modules would adversely affect how easily users complete key tasks?
Prototype tested

Tasks and participants

The UX researcher and I ran moderated tests remotely using Zoom with 11 users  (not all users were asked to perform all the tasks).

We asked them to perform 6 main tasks:

Web protection:
• What does “partial” mean?
• Adding a site to the Web Allow List
• Configure allow options

Call protection:
• Report a number we didn’t flag
• Allow a number we flagged

• Turn off scam call warning


If a web page is blocked by Advance Web Protection, users can use the deep link on the block page [fig 2] to advance to the blocked site or manually add the website to the Web Allow List. When they do so, the application defaults to only allowing the non-suspicious portions to load. However, users can choose to allow all of the site to load.
Web Allow options
Prototype tested
After testing the prototype with the first 5 participants, I saw an area for improvement. The initial prototype didn’t provide feedback for the action of allowing a new website. None of the 5 users were able to figure out where to go to “allow all of the site”.

I revised the prototype so that there was more feedback for users allowing a new site. Even if users had tapped on the “Allow a new site” button from the Web Protection page, they would land on the Website Allow List after allowing a new site. They would see the newly allowed site drop in from the top, thereby discoverability to the “Allow list options” page.

Usability Test results

🌐 Web protection

Understanding what "partial" protection meant

  • 1 passed without prompting
  • 5 passed with prompting
  • 5 were not asked

Adding a site to the web allow list

  • 9 passed without prompting

Configure web allow list options (partial allow to full allow)

  • 3 passed without prompting
  • 3 passed with prompting
☎️ Call Protection

Report a number we didn’t flag

  • 9 passed without prompting
  • 1 passed with prompting

Allow a number we flagged

  • 9 passed without prompting
  • 1 passed with prompting

Turn off scam call warning

  • 9 passed without prompting
  • 1 passed with prompting
We can see that there were two significant problems with the new design:

1) Even after the prototype change, the Web Allow List options - partial allow or full allow - weren’t discoverable.

2) What I meant by partial Web Protection didn’t match what the users thought. I used “partial” to mean that only Advanced Web Protection or Safari Web Protection was on; only if both were on would the dashboard display “on” for Web Protection.

From follow-up questions, we saw that users understood partial protection as certain sites, parts of sites, or types of suspicious activity. Users also did not like having to leave the dashboard to find out what “partial” meant.

💡 My conceptual model did not match users’ mental model.

Refine and revalidate

To address some of the issues made apparent in the first round of testing, I thought about changing the requirement that both Advanced Web Protection and Safari Web Protection had to be on for Web Protection to be displayed as on.

Instead, we could use “All apps” to indicate Advanced Web Protection being on and “Safari only” to indicate the regular web protection being on.
All apps = Advanced Web Protection
Safari only = Safari Web Protection
Only one or the other
I felt this solution was awkward. There wasn’t an apparent connection between the labels “All apps” and “Advanced Web Protection”, especially if users do not read the description under Advanced Web Protection.

Thus I talked to our Product Manager. After a VERY long Slack conversation, a lightbulb flashed. There wasn’t a need for both to be on for users to be fully protected. If Advanced Web Protection was on, the Safari-only protection wouldn’t be adding any additional protection.

With clearer requirements, I was able to pivot to a segmented control component to indicate the different levels of Web Protection.
I don’t see a case where both being on is meaningful... really, only one or the other would be on at a time.
Thomas, Product Manager
Web Protection’s segmented control
Web Protection’s segmented control

Improving Web Allow List options

In the first prototype and test session, we saw that Web Allow List options were still problematic. Landing users on the list of allowed websites with the newly allowed site URL animating in didn’t address the issue.

I decided to add a tool tip. For the first few times users allow a new site, they would see a tool tip pointing to the chevron, with the content “Configure how much of the site you want to load”.
Tool tip indicating more options
Web Allow List options
The copy on the Allow List options page was also problematic. It did not have an effective conceptual grammar model. The option was to load some of the allowed site (the non-suspicious parts) or all of the allowed site (even the suspicious parts). The original design used the choices of Allow and Allow all. Grammatically, these were not good choices for the question.

I decided to change the choices to “some” and “everything”. I also appended a simple imagery for each choice to further visually differentiate the two choices.

Improving Call Protection options

Users can configure Call Protection options to their liking, for both fraudulent and spoof calls. For either, they can choose to be warned or to block these calls outright. The latter option would prevent them from even knowing the call occurred.

To clearly explain this, we relied on very detailed copy, adding to the length and visual complexity of this page. Users complained about this.
Existing Call Protection options
Revised Call Protection options
To reduce the amount of content, the UX researcher suggested toggles instead of check marks. The toggles would be for the warning screen. By default, the app would show warning screens for incoming fraudulent and spoof calls.

Users can turn off the warning but would receive a native iOS alert warning them about the severity of this action.

Elevating shortcut to report a number

Users can actually report a fraudulent number we missed to us directly through the native iOS phone app through a shortcut. The problem was that this shortcut had to be enabled, which is somewhat complex. Once enabled, it is much easier to report numbers we missed to us than going into the Malwarebytes app and manually typing in the number.

The existing design featured a “Learn how” link that directed users to a support article with step-by-step instructions for turning on this shortcut. Looking at app analytics, it had very little engagement. This made sense as users are unlikely to want to exit an app to learn something more in the midst of an important task.
Learn how links to support article
I saw that the support article included detailed screenshots and instructional content. I thought the screenshots were clear enough that even without text directions, users would understand how to turn on this shortcut.

I decided to show the screenshots as a slideshow from within our application, instead of taking users out of our app and into a web browser.
Report a number shortcut slideshow
Round 2 prototype

Validation test round 2

It was time to test these improvements. We wanted to see if these design refinements resolved some of the usability issues found in the first round of testing.

We asked 10 users to perform 3 main tasks:

Web protection:
• Switch between different levels of web protection and explain their actions 

Call protection:
• Turn off scam call warning (using toggles)
• Thoughts on the screenshots slideshow for shortcut to report a number - whether they caused confusion or distraction

Test results

Web protection
Participants understood each level of web protection and the segmented control.
Call protection toggles
Participants understood each level of web protection and the segmented control.
Call protection: shortcut to report a number
Participants understood each level of web protection and the segmented control.

Hallway testing

Using toggles for call protection options still proved problematic. It wasn’t very clear that the toggle on under Call Protection options meant users would get a warning screen and that the toggle off meant all fraudulent calls were automatically blocked.
Toggles signifying warning on or ff
The UX Researcher and I decided to conduct a hallway test with 8 Malwarebytes employees who rarely interacted with our products. 

I designed two prototypes. Both start with a warning screen users would see in the event of a fraudulent or spoof call. Then, we asked users to turn off this warning while still having Call Protection enabled. We wanted to observe how users interacted with both options and which was their preferred design.

Version 1 Toggles

In this updated version, we decided to change the option to Block and it would default to being off. Explanatory content underneath the choice explains what turning on block means.

Version 2 Checkmarks

We also tested a check marks version. Users have two options, with the flag incoming call option being defaulted to. I also added simple imagery here to accommodate the microcopy.

Test results

The results were a toss-up.

• 4 participants preferred toggle because of less content.

• 4 participants preferred the checkmarks because it was clearer which was the default setting and the difference between the two choices. These 4 participants also liked the imagery.
Splitting up fraudulent and spoof call settings

The final decision

We decided to go with the check marks version because it was clearer than the toggles version. There would be less room for confusion as users saw both choices - warn and block - at the same time.

Also, it seemed contradictory that users can toggle on Call Protection but then toggle off the warning. Using toggles to control both Call Protection objects and attributes was problematic.

To shorten the length of the Call Protection Options page, I decided to break Fraudulent Call settings and Spoof Call settings into two separate screens.
I started to work on the high-fidelity mockups - partnering with the illustrator to find concepts that would lend themselves to simple animations - when I decided to leave for another position. 

I ended up finishing the UI work for this case study. The illustrations and colors chosen are my personal preferences and not a reflection of Malwarebytes’ design system.

Metrics of success

Although I wasn’t able to see the product through its beautification process, I am confident our rigorous user testing and iterative process produced an improved design.

But metrics speaker louder than feelings.

We can gauge whether Advanced Web Protection was effectively integrated by measuring an increase in conversion from free to paid users.

We can gauge whether fixing the navigation and other usability issues were effective by measuring:

• The rate of user-reported fraudulent numbers remains the same or is higher than the existing 4-item navigation
• An increase in app rating on the Apple App Store (link to listing)
• A decrease in customer support cases

Lessons for the road

What was supposed to be an easy fix turned out to be much more. The lessons I learned from this project are ones that I will continue to learn. I have never been unsurprised by usability testing results; often times, better designs surface from those awkward moments when the user has no idea how to accomplish what you, as the designer, thought was a really simple task.

Also, sometimes a horrendously long Slack thread is worth it.

Looking for more reading material?