Malwarebytes  for  iOS

UI/ UX            JAN-JUN 2018       Lead Designer

UI/ UX            

JAN-JUN 2018       

Lead Designer

In June 2018, Malwarebytes launched its very first iOS product. We didn't think it would be doable; by its very nature, Apple products do not allow scanning. And if Malwarebytes is known for anything, it's scanning and cleaning.

Below is our journey taking a product from a list of features to a living, breathing, and ever-changing application in the App Store - from my perspective and contributions as a designer. It was no easy feat and it was often a balance between what's ideal and what's realistic, with features and fixes added to an evergrowing list of backlog items. 

In June 2018, Malwarebytes launched its very first iOS product. We didn't think it would be doable; by its very nature, Apple products do not allow scanning. And if Malwarebytes is known for anything, it's scanning and cleaning.

Below is our journey taking a product from a list of features to a living, breathing, and ever-changing application in the App Store - from my perspective and contributions as a designer. It was no easy feat and it was often a balance between what's ideal and what's realistic, with features and fixes added to an evergrowing list of backlog items. 

Meet Anthony

You'll  happen upon the name Anthony throughout the case study. Anthony was the Malwarebytes Senior UX Researcher at the time of this project. We worked hand-in-hand throughout the entire project. 

The BETA application

Before I started on the project, the product owners decided there should be 4 main features. There are many existing apps that focus on one or two features at a time; our differentiation was that our one app can do everything. 

The Malwarebytes for iOS project started with 4 features:

Web protection (premium):  Block malicious and phishing sites
Call protection (premium):  Flag or block spam and spoof calls
Ad blocking (free):  Stop ads and trackers on Safari
Text message filtering (free): Filter out junk or spam messages

To ensure the backend was ready to go, the engineers built a beta app and released it through Test Flight. 

MB for iOS_original beta
MB for iOS_original beta
MB for iOS_original beta
Start with Users

Even though the features were set, the application still needed to be designed. 

Every design starts with the users. At thetime, we didn't have mobile personas, but Anthony had already collected and analyzed user insights from interviews with Malwarebytes for Mac and Malwarebytes Android users.

He knew our mobile users the best. Thus, we turned to him for insights on mobile users' behaviors and needs. 

curiosity by Bing Han

USERS ARE CURIOUS AND PARTICIPATORY

Users value their own curiosity. When it comes to scam calls, users want visibility and guidance. They might not want us to make decisions for them by automatically blocking scam calls; it's pretty important to give users the option of being warned about or automatically blocking such calls. 

By the same token, users might be curious about a blocked web page even though it's blocked. To address this curiosity, we might display the block category on the web block page. 

Users are also curious about what others think; they mentioned whenever they get a call from an unrecognized number, they would look up that number and see what others have to say. 

Finally, users see it as their civic duty to report scammers. So, we should give them an easy way of reporting numbers we missed.

"Users value their own curiosity."

- Anthony, UX Researcher

DESIGNING FOR CUSTOMIZATION 

Some users don’t want to customize protection levels; they want us to take care of everything.

Other users want advanced options. For example, for call protection, some users want to know the difference between scammers, spoofed numbers, reported numbers, etc.

To accommodate for this spectrum, we should offer definitions for each call protection category so users can make informed decisions.

User customization by Patrick Fore
Information Architecture

To ensure that we started off with the right system hierarchy, Anthony and I decided to do an unmoderated open card sort. We came up with 30 different terms and recruited 100 participants using Amazon Mechanical Turk. 

Items more commonly grouped together were given a higher similarity rating (from 0 to 100). Overall, at the 50% similarity rating, four categories appeared to form:

  • Dashboard, which includes the 4 main features of the product
  • A block lists area
  • Help features
  • Application settings 

To ensure that we started off with the right system hierarchy, Anthony and I decided to do an unmoderated open card sort. We came up with 30 different terms and recruited 100 participants using Amazon Mechanical Turk. 

Items more commonly grouped together were given a higher similarity rating (from 0 to 100). Overall, at the 50% similarity rating, four categories appeared to form:

  • Dashboard, which includes the 4 main features of the product
  • A block lists area
  • Help features
  • Application settings 
card sort categories
Dendogram of card sort results

From the card sort results, we came up with the bottom navigation.

DASHBOARD: 4 protection feature, database updates, upgrade, notifications 

LISTS: White lists and black lists

HELP: Forum, report a problem, send feedback, rate this app, protection setting instructions

SETTINGS: About, notifications, share  telemetry, my account, profile, subscription

1_Dashboard free_very initial design
Heat map of usability test of lists

TESTING THE BOTTOM NAVIGATION

We ran a few tests on the bottom navigation. 

For us, lists meant white list (allow list) and black list (block list). We presented 20 users with a wireframe of the dashboard and asked "How would you report a scam phone?" 

Lists did not test well at all; none of the participants tapped on lists. Most users tapped on the “call protection” module. 

After viewing the results of this test, Anthony and I decided to rename lists as block/allow.

TESTING BLOCK/ALLOW

After deciding to rename lists to block/allow, the next quandary was to determine whether to break out block/allow into two separate navigational items or combine them as one.

I quickly wireframed both solutions and we tested them, asking the question, "How would you report a scam phone number?"

Solution 1: Combine block and allow

To combine block/allow into one navigational item, I used tabs. Then, I had to design a way to allow users to switch between web and phone allow lists within the allow tab. I opted to add a button at the bottom to switch between web and phone.

Block and Allow_scam
Block and Allow_phone allow
Block and Allow_web allow

Solution 2: Separate block and allow

The second, more straightforward, solution was to break out block and allow into separate navigational items. Then the allow screen itself can utilize the tab pattern for web and phone. 

Allow list_Phone
Allow list_Web
Block list

Breaking out allow and block into separate navigational items had a higher success rate (35%) than combining them (25%). 

The 35% success rate was still quite low but Anthony and I assumed it was because the wireframes were too low-fidelity, lacking needed affordance. We hypothesized that high-fidelity screens would have tested better.

Happy Happenstance

Although we didn't intend to test for this, some users had problems finding the submit button at the bottom of the report form.

Realizing this, Anthony and I decided that an additional submit button at the top of the form would allow for easier reporting.

The submit button would turn from disabled to enabled once the phone number field was filled in as the rest of the fields are not mandatory.

Report a scam number wireframe

Original report form

Report form_in app_Phone number_done

Revised report form

Visual language

At the time of designing this application, our visual identity was not cohesive; consumer products looked different from enterprise products, which is also different from our Android product, and none of them matched our website.

In 2016 (2 years prior to this project), Malwarebytes went through a rebrand and commissioned illustrations by Brian Edward Miller. These illustrations were peppered throughout our website.

I decided to align the visual identity of the iOS app to the website, because the website has the highest amount of traffic of all our various platforms. I leveraged the illustrations as  a visual backdrop for the application.

 

Malwarebytes digital landscape
Brand illustration

The app consisted of 5 main tabs - dashboard, allow, block, help, and settings. I sectioned off the digital landscape shown above into 5 sections and used each section as the backdrop of each of the 5 main tabs.

Users progress through the landscape by progressing through each of the tabs.

The main call-to-action buttons were colored blue and coral, to match our web style guide, and because they paired well with the illustrations.

Dashboard with visual language
Allow tab
Block tab
Help tab
Settings tab

For secondary screens, I chose to go with a very stark white background to differentiate it from the main architecture of the application.

This image is a secondary screen under call protection. User research showed that users wanted the option of being warned about fraudulent calls or blocking them outright. 

customize call protection

TESTING FOR DESIRABILITY

Because the application featured such impactful visuals as backdrops, we decided to run a desirability test of the dashboard using Usability Hub. Desirability tests gauge attractiveness and ease of use. 

Usability Hub - testing for desirability-top
desirability_2
desirability_3

VISUAL CLEAN-UP

From the test results, we saw that a lot of users liked the visual background but also found it distracting. So, I took out a few of the graphic elements near the top and bottom of the screen to decrease visual clutter. Bye bye glowing worms and flying bots.

Dashboard after visual cleanup

After clean-up

dashboard_before

Before clean-up

Challenge of constraints

Contraints can be limiting to a fluid experience; but they can also force designers to be creative in solving to stay within them or deliver inspite of them. 

Throughout the project, I dealt with platform challenges, challenges of conversion, aggressive but needed feedback, and even submission challenges which ultimately changed the features of the application.

PLATFORM CONSTRAINTS: TELEMETRY

One of the goals of any product is to show value; this is especially true for a security application that mainly runs in the background.

At first, I had envisioned a data-rich dashboard showing how effective our app was - filled with stats of websites, calls, ads, and messages blocked or filtered. 

Initial dashboard idea with lots of telemetry
Revised dashboard without telemetry

But this wasn't possible because the insfrastructure of our application was dependent on native features within the iOS platform - specifically, the phone, message, and Safari apps.

Apple is very hesistant to share user data with developers; hence the dashboard became a simple on/off status indicator. 

PLATFORM CONSTRAINTS: ACTIVATION

Apple has restrictions on how protection features can be enabled. Users must go to Settings, and go several layers deep, to enable each of the protection features. 

We studied competitive apps to see how they provided directions and decided simple directions, coupled with easily identifiable icons such as Settings and Safari, was the best way to go. 

Using Usability Hub, we conducted an unmoderated remote test with 100 participants and asked, "How would you enable Ad Blocking?"

click through test

The results were pretty insighful. Most of the users were able to complete the task of activating Ad Blocking, despite the numerous steps. 

Some users viewed the placeholder icons (the circles in the first screenshot) as actionable buttons. This made us realize that we should make that section a part of the touch target.

For the final mockups, I decided to take out the placeholder image on the instructions screen; the test proved successful enough without the need for an image. I also left aligned the icons so they would act as landmarks and be easier to scan. 

WEB PROTECTION

Web Protection blocks malicious websites on all major browsers. The explanation screen is followed by native iOS alerts.

Original web protection explanation
native iOS VPN alert

CALL PROTECTION

Call Protection blocks or warns users about suspected scammers and spoofers. 

The activation steps for this protection module has a few extra steps, as we need users' phone numbers and contacts to protect them against spoof calls while not flagging legitimate calls.

Call Protection explanation screen
Call protection - asking for users number
asking users to verify number
asking users for contacts list access
call protection activation instructions

AD BLOCKING

Ad Blocking blocks ads and trackers on Safari.

Ad blocking explanation
ad blocking activation directions

TEXT MESSAGE FILTERING

Text Message Filtering filters spam texts to the junk tab in the native Messages app. 

Text Message Filtering Explanation
Text message filtering activation directions

DESIGNING FOR CONVERSION

The Malwarebytes for iOS app is a free product with in-app purchases.

  • Web and Call Protection are premium features
  • Ad Blocking and Text Message Filtering are free features

As a freemium product, it's important to show the difference between free and premium features.

In initial mockups, I used a crown icon to differentiate between the two tiers of features. After stakeholder input about grouping features together more, I was able to append text labels "free" and "premium" and take away some of the visual striations. 

original dahboard

Original dashboard

revised dashboard

Revised dashboard

We ran another desirability test after this change. It tested a bit better. But like I told Anthony, the graphic visual background was a reflection of the brand and a gamble I was willing to take. 

new desirability test
new desirability test
new desirability test

Stakeholder feedback also mentioned that the upsell wasn't strong enough; thus, we appended an upgrade button to the top of the free dashboard and changed the "Learn more" to "activate". 

We emphasized the free trial by calling out the free 30 days. This was also reflected in the subsequent upgrade screen. We wanted to make sure users knew they had to start a subscription to receive the free 30 days fo trial.  

Free dashboard with revised free badge

Revised dashboard with badge

Upgrade screen

Upgrade screen

When the user converts to Premium, the dashboard badge changes to reflect database updates. There is no more need to upsell. 

 

Premium dashboard

Premium user dashboard

The settings screen also reflects the change in user state. For Premium users, we deep linked the "Manage subscription" button to iTunes. We wanted to make it easy for users to cancel their subscriptions should they wish to do so.  

Free user_settings

Free user settings

Premium user_settings

Premium user settings

The most challenging part in designing for conversion were related to allow and block. These two functionalities spanned both free and premum features.

The first-visit states, empty states, and explanation states of both tabs had slightly different copy to accomodate for both user states. 

ALLOW

  • Free users can use the allow function to unfilter text messages erroneously filtered to the junk tab.
  • Premium users can use the allow function to unflag/unblock calls and unfilter messages.
  • Premium users can also use the allow function to allow websites. 
Web allow-free user

Free user web allow

Allow - premium user

Premium user web allow

BLOCK

  • Free users can use the block function to filter text messages from unwanted numbers that isn't on our database.
  • Premium users can use it to flag/block calls from unwanted numbers and filter their messages.
Block explanation for free user

Free user block explanation

Premium user block explanation

Premium user block explanation

DESIGNING FOR RETENTION

When free users do convert to premium, we want them to remain premium users. To do so, it's especially important to show value. 

With a security app that runs in the background, without the need for much user interaction, and for which user telemetry isn't readily available, we only have a few specific instances of showing value. 

WEB PROTECTION

With Web Protection, we can show a branded block page, with options to bypass the block by adding the website to the allow list. 

web allow process

CALL PROTECTION

For Call Protection, our value is shown through a Malwarebytes Caller ID. There isn't much design we could add to this screen.  

call protection warning screen

Web and Call Protection are premium features. Their value is contingent upon them being on.

Through a combination of onboarding, in-app dashboard messages, and carefully cadenced push notifications, we urge premium users to activate these features and turn them back on if they were turned off.

web and call protection push notifications

RETAINING FREE USERS

It's perhaps even more important to retain free users so they don't uninstall the application. This is especially challenging.

For Ad Blocking, it's the absence of ads that shows the functionality of the app, but without telemetry into how many ads and what ads are blocked, it's hard to show the value.

For Text Message Filtering, the user would see value from the messages that populate the junk tab, but it's not branded.

text message filtering in action screen
Feedback

No one likes getting feedback, but I have never had a design get worse because of feedback.

To me, feedback is multifacted. It can come in the form of design critiques, usability testing, and stakeholder feedback, etc. 

NATIVE versus CUSTOM

The CEO really wanted to save development time and use native iOS elements wherever possible. 

One such area was the allow tab. The original design featured a custom tab pattern but the CEO urged us to go with the native pattern.

Allow Phone native iOS control

Native iOS segmented control

Native iOS component

Allow Phone tab

Custom tab pattern

Anthony and I tested both designs, asking 20 users, "How would you switch over to the web list?"

Test results indicated that users were able to switch over to the web list using the custom tab pattern almost twice as fast as the native iOS component.

I shared these results with the CEO and got the okay to proceed with the custom tab pattern. 

BOTTOM NAVIGATION REVISITED

When the design was nearly finished, we had a big meeting to go over submission details and go-to-market strategy. During this meeting, there were some pretty loud objections over two tabs - allow and block.  

dashboard with allow and block objections

ARGUMENTS AGAINST ALLOW

The allow tab lets users to white list or permit sites that Web Protection deemed malicious and permit phone numbers flagged by Call Protection as spam or scam. 

  • Some argued that having an allow tab made it too easy for people to whitelist possibly harmful sites, or even make users think they have to whitelist every site they want to visit.
  • Some argued that most people would just whitelist from the deep link on the web block page.

ARGUMENTS AGAINST ALLOW

The allow tab lets users to white list or permit sites that Web Protection deemed malicious and permit phone numbers flagged by Call Protection as spam or scam. 

  • Some argued that having an allow tab made it too easy for people to whitelist possibly harmful sites, or even make users think they have to whitelist every site they want to visit.
  • Some argued that most people would just whitelist from the deep link on the web block page.
Allow Phone tab
Allow Phone tab explanation
Explanation for web allow

ARGUMENTS AGAINST BLOCK

The block tab lets users report fraudulent numbers outside of our database to us and we would block their calls or filter their messages to the junk tab.

This is especially important as we rely on our community of users to organically grow our database of fraudulent numbers. This is also why we elevated block to the main navigation.

  • Some argued that the title "block" was confusing as users would expect to see a list of calls we had blocked and NOT a list of fraudulent numbers reported by the user. Anthony and I conceded this point.
  • Some argued that reporting a number would not be a commonly used feature and thus do not need to be so elevated in the IA.

ARGUMENTS AGAINST BLOCK

The block tab lets users report fraudulent numbers outside of our database to us and we would block their calls or filter their messages to the junk tab.

This is especially important as we rely on our community of users to organically grow our database of fraudulent numbers. This is also why we elevated block to the main navigation.

  • Some argued that the title "block" was confusing as users would expect to see a list of calls we had blocked and NOT a list of fraudulent numbers reported by the user. Anthony and I conceded this point.
  • Some argued that reporting a number would not be a commonly used feature and thus do not need to be so elevated in the IA.
Block tab
Block tab explanation (premium users)

I was urged to move allow and block into settings and redesign the navigation to feature only 3 items: dashboard, help, and settings.

Anthony and I still felt that allow and block were extremely relevant and should not be deemphasized. We cited several arguments:

  • The card sorting exercise showed that users categorized block and allow as separate from settings.
  • Per Anthony’s research, users don’t understand terms such as permissions, exclusions, white/black list. Hence, allow and block were the most user-friendly terms.
  • Anthony also mentioned that not giving users an easy way to whitelist sites was what made users uninstall MB3 (our desktop application) on their machines. When users couldn’t advance to a site they wanted to visit, they opted to uninstall the product.

Ultimately, were were outranked. I moved allow and block into settings. 

Updated settings with allow and block
Manage allow list drop down open
Submission to App Store

Any application that wants to be in the App Store is subject to Apple's strict guidelines.

There were quite a few changes we had to make to finally make it into the App Store. Some were easy. Some were very hard. 

FINE PRINT

In late May 2018, we were finished with the MVP and submitted the application to the App Store. It was rejected several times.

The first rejection was about subscription terms. We weren't clear enough about how Premium subscription worked. Apple asked us to insert a large chunk of fine text to clarify to the user exactly when he or she would be charged. 

Original upgrade screen

Original upgrade screen

Revised upgrade screen with more details

Revised upgrade screen

GOODBYE VPN

At the time of the submission, Apple was no longer accepting apps with DNS technology. In fact, Apple was cracking down on existing applications using DNS technology. 

Our Web Protection, a premium feature that leveraged DNS redirect technology, was one of the best features of the entire app. We could protect users across all major apps, even when malicious sites are called without the user's intention. 

Frustrated man by Tim Gouw

The Product Manager and engineers decided to turn Web Protection into a premium Safari content blocker. 

To give users more control, we thought about introducing different rules that users could control from within the app. Users can customize Web Protection by tapping on the Customize protection button under the Web Protection module. 

The Product Manager and engineers decided to turn Web Protection into a premium Safari content blocker. 

To give users more control, we thought about introducing different rules that users could control from within the app. Users can customize Web Protection by tapping on the Customize protection button under the Web Protection module. 

different rules that can be toggled on/off by users

Depending on the size of the database of each content blocker, the app would hang for a few seconds.

To ensure users didn't think the app has malfunctioned,  I designed a loading animation, using Invision Studio. 

content blocker loading

Ultimately, because of time constraints, we decided to make Web Protection just one content blocker. Even then, we still had a few design changes to make to accomodate for this change.  

The original Web Protection featured a block page whenever users visited a malicious site. The new version only works on Safari and we couldn't feature a branded block page. 

Original block page

Original block page

Safari block page

Native Safari block page

The original Web Protection explanation screen leveraged the branded block page. I had to redesign the revised Web Protection explanation using an abstract image indicating protection.

Original web protection explanation

Original explanation screen

Revised web protection explanation

Revised explanation screen

Web Protection versus Ad Blocking

Both Web Protection and Ad Blocking work through Safari content blockers. Both of them need to be enabled through Safari settings.

But Ad Blocking is free and Web Protection is a premium feature. To solve this problem, we were thinking of appending a crown or money emoji to the Web Protection content blocker within Safari settings.

However, because we support down to iPhone SE, it would push out the "web protection" text too far. 

Web Protection versus Ad Blocking

Both Web Protection and Ad Blocking work through Safari content blockers. Both of them need to be enabled through Safari settings.

But Ad Blocking is free and Web Protection is a premium feature. To solve this problem, we were thinking of appending a crown or money emoji to the Web Protection content blocker within Safari settings.

However, because we support down to iPhone SE, it would push out the "web protection" text too far. 

Safari settings_iPhone 8

iPhone 8

iPhone 8

Safari settings_iPhone SE

iPhone SE

iPhone SE

When free users activate Ad Blocking within Safari settings, there is nothing to prevent them from activating Web Protection. But they wouldn't actually be protected from malicious sites until he or she upgrades to Premium.

To solve for this, I designed a modal that free users would see once they returned to the application after having activated both content blockers within Safari settings.

free user modal

Third time's the charm. Apple approved our third resubmission. See it on the App Store. 

Apple-App-Store-CTA-black
Next steps

The product has now gone through several iterations. There was significant user push back against hiding the report functionality in the settings tab. In version 1.2, I explored different ways of elevating it. 

THANK YOU FOR VISITING

THANK YOU FOR VISITING.

THANK YOU FOR VISITING