Malwarebytes for iOS 4.0

CATEGORY
Product Design
ROLE
Lead Designer
TIMEFRAME
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 the app's Web Protection feature. With DNS-redirect, we can protect users when they browse or connect to the web from any iOS application. The existing Web Protection feature only worked 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 semantic conceptual model to simplify the entire information architecture. We also worked out  other usability kinks along the way.
Final designs in device mockups
Dashboard final designWeb protection final designFinal call protection design
Left text. Right centered -image. Side by side on tablet. Left text. Right centered -image. Side by side on tablet. Left text. Right centered -image. Side by side on tablet. Left text. Right centered -image. Side by side on tablet. Left text. Right centered -image. Side by side on tablet.
Left text. Right centered-image. Stacked on tablet and below. Natural order. Left text. Right centered-image. Stacked on tablet and below. Natural order. Left text. Right centered-image. Stacked on tablet and below. Natural order. Left text. Right centered-image. Stacked on tablet and below. Natural order. Left text. Right centered-image. Stacked on tablet and below. Natural order.
Left text. Right image. Natural order. Left text. Right image. Natural order. Left text. Right image. Natural order. Left text. Right image. Natural order. Left text. Right image. Natural order. Left text. Right image. Natural order. Left text. Right image. Natural order.
text left. image right. reverse order. text left. image right. reverse order.text left. image right. reverse order.text left. image right. reverse order.text left. image right. reverse order.text left. image right. reverse order.text left. image right. reverse order.text left. image right. reverse order.text left. image right. reverse order.
Left image. right text. side-by-side on tablet. reverse order. Left image. right text. side-by-side on tablet. reverse order. Left image. right text. side-by-side on tablet. reverse order. Left image. right text. side-by-side on tablet. reverse order. Left image. right text. side-by-side on tablet. reverse order. Left image. right text. side-by-side on tablet. reverse order.
Left 1/3 - text. Right 2/3 - image. Natural order. Left 1/3 - text. Right 2/3 - image. Natural order. Left 1/3 - text. Right 2/3 - image. Natural order. Left 1/3 - text. Right 2/3 - image. Natural order.

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

What’s the challenge?

How do we add a new feature that’s similar to an existing feature? We 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.

An opportunity arises

As I was thinking about how to incorporate this new feature, 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.
These heat maps indicated an opportunity to leverage object-oriented (conceptual grammar model) design; users perceive objects as an entry point to actions and attributes.
If “advanced” and “normal” protection are attributes of the web protection object, we can append the new Advanced Web Protection feature to the existing Web Protection object.

Grouping objects, actions, and attributes

There was an opportunity to extend object-oriented design to also address the inefficient information architecture.

The main navigation on the bottom separated out objects, actions, and attributes into different places. It held a mixture of objects (nouns: dashboard and help) and actions (verbs: allow and report).

The dashboard itself featured a mixture of objects and attributes.
Using call protection as an example, 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.
Simplified dashboard and navigation
We can take away the complexity by grouping objects, actions, and attributes together.

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 actions and attributes of each protection object would move from the dashboard and the bottom navigation into its container object on the dashboard.

For each protection object, instead of using toggles, I opted to use a text label to indicate protection module status. I appended a chevron to signify more content (actions and attributes) within each protection object.
The bottom navigation can now be simplified into 3 items - dashboard, help, and settings.

Container objects

The dashboard houses 4 container objects - the 4 protection modules. All associated actions and attributes are respectively nested within each container object.

Validation Round 1

I had planned on getting feedback on this new design from the product manager and engineers. However, I had enough time to run a quick test. With the help of the UX Researcher, we set up a quick round of testing to validate the designs.

Tasks and participants

Using Zoom, the UX researcher and I conducted moderated tests 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

Web allow list

If a web page is blocked by Advanced Web Protection, users can use the deep link on the block page [fig 2] to advance to the blocked site. They can also manually add the website to the Web allow list to avoid being blocked next time.

When a site is allowed, the application defaults to only allowing the non-suspicious portions to load. Users can change this behavior and load the entire site.
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. Regardless of where they initiate the allow action, users will land on the Web Allow List page and see the newly allowed site drop in from the top.

Round 1 results

🌐 WEB PROTECTION
Task 1
Understand the meaning of  “partial” protection
Results
1 passed without prompting
5 passed with prompting
4 were not asked
Task 2
Add a site to the web allow list
Results
9 passed without prompting
Task 3
Configure web allow list options (partial allow to full allow)
Results
3 passed without prompting
3 passed with prompting
3 were not asked
☎️ CALL PROTECTION
Task 1
Report a number we didn’t flag
Results
9 passed without prompting
1 passed with prompting
Task 2
Allow a number we flagged
Results
9 passed without prompting
1 passed with prompting
Task 3
Turn off scam call warning
Results
9 passed without prompting
1 passed with prompting
Based on test results, 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.
My conceptual model did not match users’ mental model.
From follow-up questions, we realized 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.

Refine, refine, refine

To address some of the issues discovered in first round of testing, I thought about changing the approach 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.
Only one or the other
But this solution was still not ideal. There wasn’t an apparent connection between the labels “All apps” and “Advanced Web Protection”.

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 decided to use a segmented control component to indicate the different levels of Web Protection.
I don’t see a case where both being on is meaningful...only one or the other would be on at a time.
Thomas, Product Manager
17
Web Protection’s segmented control
Improving Web Allow List options
From the first round of testing, we saw Web Allow List options were not discoverable. Landing users on the list of allowed websites with the newly allowed site 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, indicating more customization options.
On the customization page itself, the labels were problematic.

The options are 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.
I decided to change the choices to “some” and “everything”.
Improving Call Protection options
Users can configure Call Protection options to their liking, for both fraudulent and spoof calls.
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 explain this, we relied on very detailed copy, adding to the length and visual complexity of this page. Users complained about this in the first validation session.
To reduce the amount of content, the UX researcher suggested toggles instead of check marks.

By default, the app would show warning screens for incoming fraudulent and spoof calls. Users can still choose to answer these calls. Toggling off means all fraudulent and spoof calls would be automatically blocked.

Elevating shortcut to report a number

Call protection relies on matching the numbers of incoming calls against a list of fraudulent numbers, maintained by Malwarebytes. Some numbers fall through the cracks and we don’t flag them as fraudulent. As such, we ask users to report missed numbers to us so that we can grow our list of fraudulent numbers.

There are two ways users can report a fraudulent number we missed to us.

One way is by opening up the app and manually typing in and submitting the number. Another way is through a native iOS phone app shortcut. The problem was that this shortcut had to be enabled first, which is somewhat complex.
The existing design featured a “Learn how” link that directed users to a support article with directions on how to turn on this shortcut. This link did not have much engagement.
The support article included detailed screenshots and instructional content. The screenshots were pretty self-explanatory. So, I decided to show the screenshots as a slideshow in the app. When users manually report numbers to us, they can browse through the screenshots to learn how to enable the shortcut.

Validation round 2

It was time to test these improvements. We wanted to see if these design refinements resolved some of the usability issues discovered 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 the difference
☎️ CALL PROTECTION
  • Turn off scam call warning (using toggles)
  • Thoughts on the slideshow on shortcut to report a number - whether it caused confusion or was a distraction

Round 2 results

🌐 WEB PROTECTION
Task 1
Switch between different levels of web protection and explain the difference
Results
All 10 participants understood each level of web protection and the segmented control
☎️ CALL PROTECTION
Task 1
Turn off scam call warning (using toggles)
Results
Some participants were confused about turning off warning to block calls
Task 2
Feedback on slideshow to demonstrate the shortcut to report a number
Results
Most participants naturally noticed the slideshow, did not find them distracting, and said they would definitely use this shortcut to report numbers

Hallway testing

Using toggles for call protection options still proved problematic. It wasn’t very clear that “on” meant users would get a warning screen and that “off” meant all fraudulent calls were automatically blocked.
I designed two options to address the confusion and we tested both prototypes. Both prototypes started with a warning screen users would see in the event of a fraudulent or spoof call. Then, we would ask 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.

To save time, the UX Researcher and I decided to conduct a hallway test with 8 Malwarebytes employees who rarely interacted with our products. 


Test results

The results were a toss-up.
  • 4 participants preferred the toggle because of less content
  • 4 participants preferred the check marks because it was clearer which was the default setting and the difference between the two choices. These 4 participants also liked the imagery

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 the Call Protection object and its attributes was problematic.

To decrease the density of the content, I decided to break fraudulent call settings and spoof call settings into two separate screens.

Finishing touches

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 project through to release, there are several metrics by which to measure success when it does ship.

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
  • A decrease in customer support cases

Looking for more reading material?