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.
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.
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.
.png)
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.
.png)
2
Advanced Web Protection
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.
.png)
3
Adding another dashboard module
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.
4
Previous usability test
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.
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.
.png)
.png)
5
Existing objects, actions, 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.
.png)
6
Existing versus new dashboard
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 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.
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.
7
Existing grammar model versus new grammar model
Container objects
The dashboard houses 4 container objects - the 4 protection modules. All associated actions and attributes are respectively nested within each container object.
The Web Protection object holds the option to toggle on and off the various levels of 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 live within the Call Protection container object.
Call Protection attributes - choosing warn or block for different types of calls and setting spoof call sensitivity - lives within the Call Protection 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.
12
Prototype tested
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
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.
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.
.png)
13
Web Allow options
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.
14
Revised prototype
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
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
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
1 passed with prompting
Task 2
Allow a number we flagged
Results
9 passed without prompting
1 passed with prompting
1 passed with prompting
Task 3
Turn off scam call warning
Results
9 passed without prompting
1 passed with 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.
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.
Instead, we could use “All apps” to indicate Advanced Web Protection being on and “Safari only” to indicate the regular web protection being on.
15
All apps = Advanced Web Protection
16
Safari only = Safari Web Protection
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 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
.png)
17
Web Protection’s segmented control
18
Tool tip indicating more options
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.
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.
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.
19
Revised labels for allow list options
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.
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.
20
Existing Call Protection options
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.
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.
.png)
21
Revised Call Protection options
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.
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.
.png)
22
Support article opens up in a browser window
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.
.png)
23
In-context instructions to enable iOS 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
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
24
Round 2 prototype
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.
25
Toggles to control the warning screen
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.
To save time, the UX Researcher and I decided to conduct a hallway test with 8 Malwarebytes employees who rarely interacted with our products.
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 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 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.
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.
28
Splitting up fraudulent and spoof call settings
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.
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:
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
