Malwarebytes  for  iOS

Malwarebytes  for  iOS

UI/ UX                JAN-JUN 2018

UI/ UX                NOV 2017

UI/ UX                NOV 2017

UI/ UX                NOV 2017

UI/ UX                NOV 2017

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.

Designing and developing an application actually does take a village - from product managers to engineers, from marketers to writers, from researchers to designers - each word and each pixel was pondered, refined, and reiterated upon. 

Below is our journey taking a product from a list of features to a living, breathing, and 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. 

Check back from time to time as I'll be updating the post with post-MVP challenges and designs. 

Meet Anthony

You'll  happen upon the name Anthony throughout the case study.  Anthony is the Malwarebytes Senior UX Researcher. We worked so closely together that my narrative of the process wouldn't be fair or complete without introducing him. He provided everything from user insights to validation testing to analyses of validation testing (I can't read a dendogram if my life depended on it), often offering insightful critiques on numerous design iterations. 

1 Beta

The Malwarebytes for iOS project started with 4 features:

  • Web protection - block malicious and spam sites
  • Call protection - warn users about or block spam and spoof calls
  • Ad blocking - filter out ads when web browsing on Safari
  • Text message filtering - filter out junk or spam messages

To ensure the backend was ready to go, the engineers built a beta app and released it internal and extra testers through Test Flight. This beta version had no design input whatsoever. 

The beta version consisted of one screen with toggle options for all four features. Because Apple forces users to go to Settings to enable most of these features, most of the toggles bring up instructions on how to enable the feature.

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

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

Every design starts with the users. Even though we didn't have mobile personas, Anthony had already collected and analyzed user insights from  interviews and contextual inquiries with Malwarebytes for Android users. He knew our mobile users the best. Thus, we turned to him for insights on mobile users' behaviors and needs. 


  • Users think iPads are more secure than iPhones; they would prefer to travel and bank on iPads
  • Users are concerned about public networks and use VPN to provide a secure connection
  • Users are concerned about malware on their phones; they just want to know we are going to prevent and stop infections on their phones


curiosity by Bing Han

In Anthony's words - users value their own curiosity. When it comes to scam calls, users want visibility and guidance. They might not necessarily want us to make decisions for them by automatically blocking such scam calls. Thus, 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; several users mentioned that 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. 


Users want to know we are providing them with the latest updates - the most current signatures and databases. 

Scammers/spammers are going faster than people can keep up with, and we need to emphasize that we are going just as fast by delivering frequent updates.

But more importantly, although we can automatically deliver updates without any user interaction, users like the control of being able to check for new updates. Thus, we need to design a sense of control for the users. 


User customization by Patrick Fore

Some users don’t want to customize protection levels; they just want to 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.

3 Information Architecture

To ensure that we started off with the right system hierarchy, Anthony and I came up with 30 different terms with which to conduct an open card sort. 


100 participants, from the general population, took part in the study. Anthony used Amazon Mechanical Turk for recruitment and Optimal Workshop as the remote usability tool. All participants had an approval rating of 90% or higher on Amazon Mechanical Turk.

Participants had to sort the 30 different terms into categories that made sense to them. And then they were asked to name these categories.

Items more commonly grouped together were given a higher similarity rating (from 0-100).

card sort image


Overall, at the 50% similarity rating, four categories appeared to form:

  • Dashboard, which included the 4 main features of the product
  • A block lists area
  • Help features
  • Application settings
Card sort dendogram

From the card sorting exercise, Anthony and I derived the overall information architecture.


4 protection feature, database updates, upgrade, notifications


White lists and black lists


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


Version #, database #, EULA, Privacy policy


Notification settings, other app settings, share anonymous telemetry, my account, phone number, subscription level, renewal date, cancel subscription, upgrade subscription

4 Wireframes

Armed with the overall information architecture, I started to ideate with some very basic wireframes. During this phase, Anthony and I tested numerous wireframes. I would then reiterate based on test results. 

The team and I decided to design on an iPhone 8 screen size, as it was a happy medium between iPhone SE and iPhone X. At the end of project, I worked with the engineering team to conduct a UI quality check on all the device sizes spanning from iPhone SE to X. 


In order to limit the number of main navigational items, we decided to combine About and Settings. In the very first iteration, there were 4 main items: Dashboard, Lists, Help, and Settings.

1_Dashboard free_very initial design


We ran a few tests on the bottom navigation. The "lists" label test had the most interesting results. 

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

"Lists" did not test well at all; none of the 20 participants tapped on lists to report a scam number. Most users tapped on the “call protection” module because it seemed like it had something to do with calls.

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

Testing the lists label


Apple has restrictions on how protection features can be enabled. Users must manually go to Settings and follow a series of steps. 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. 

In one of our initial iterations, we tested how users would enable features such as Call Protection, Ad Blocking, and SMS Filtering. Web protection had different enablement steps. 

Using Usability Hub, we conducted an unmoderated remote test with 100 participants and asked questions like, "How would you enable ad blocking in this application prototype?"

Dashboard wireframe
Ad blocking explanation
Ad Blocking Directions

The results were pretty insighful:

  • Some users viewed the placeholder icons (the circles in the first screenshot) as actionable buttons. This made us realize we should make that section a touch target. I also realized I should have provided some basic iconography for testing purposes. 
  • In the example shown above, we asked users to enable Ads and tracker blocking. From the dashboard, the test continued on to the iOS Settings page, Safari settings, and finally to the Safari content blockers. Most of the users were able to accurately click on the correct list item within these pages to get to the Safari content blockers screen. 


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 the common design pattern of tabs. Then, I had to design a way to allow users to switch between web and phone allow list while on 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 we tested a low-fi wireframe and a high-fidelity mockup would render better results. 

Report a scam number wireframe

Report a scam number

The usability tests mentioned above asked users to actually go through the reporting a scam number task. 

Although we didn't intend to test for this, some users had problems finding the submit button at the bottom of the form. As a result, Anthony and I decided that an additional submit button at the top of the form would allow for easier reporting. 

Malwarebytes digital landscape
5 Mockups

After testing the wireframes, it was onward to colors, imagery, and typography. The above illustration by Brian Edward Miller was commissioned by Malwarebytes in a rebrand in 2016. I used it as an inspiration and visual backdrop for the application.

Metaphorically, the image represents the digital landscape in which an epic battle rages between the Malwarebytes protagonist robot - Zero - and the various threats faced by our users.

What can I say, I have a flair for the dramatic. 


The app consisted of 5 main tabs - dashboard, allow, block, help, and settings.

I sectioned off the digital landscape 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.

Free dashboard

Free user dashboard with 4 protection modules

Free Dashboard with 4 protection modules

Free Dashboard with 4 protection modules

Free Dashboard with 4 protection modules

phone allow list

Phone allow list for users to add numbers to their white list

Phone allow list for users to add numbers to their white list

Phone allow list for users to add numbers to their white list


Explanation of phone allow list, accessible through question icon on top left (also open by default on first visit)

Explanation of phone allow list, accessible through question icon on top left

Explanation of phone allow list, accessible through question icon on top left

web allow list

Web allow list for users to add URLs to their white list. Web protection is a premium feature.

Web allow list for users to add URLs to their white list. Web protection is a premium feature.

Web allow list for users to add URLs to their white list. Web protection is a premium feature.

block list

Report a number for users to report and block scam numbers

Free Dashboard with 4 protection modules

Free Dashboard with 4 protection modules

Free Dashboard with 4 protection modules

block list explanation

Explanation of block list, accessible through question icon on top left (also open by default on first visit)

Phone allow list for users to add numbers to their white list

Phone allow list for users to add numbers to their white list


Help screen with several methods of customer support

Explanation of phone allow list, accessible through question icon on top left

Explanation of phone allow list, accessible through question icon on top left


Free user settings screen with option to start trial

Web allow list for users to add URLs to their white list. Web protection is a premium feature.

Web allow list for users to add URLs to their white list. Web protection is a premium feature.


Each of the 4 protection modules requires users to go into settings and turn them on (an Apple requirement). Thus, the instructions had to be clear and succinct.

I designed an explanation screen followed by directions for each of the modules. Wireframes of the mockups below had tested very well during previous validation testing.


Web protection blocks malicious websites on all major browsers, using VPN technology. This screen is followed by native iOS verification dialogues.

Web protection explanation


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

The activation steps for this protection module has a few extra steps.

call blocking explanation
Ask for phone number
Verify phone number
Contacts permission
Call protection activation directions


Ad blocking blocks ads and trackers on Safari.

Ads and Tracker_Explanation
Ads and Tracker blocking_steps


Text Message Filtering filters spam texts to the junk tab on your messages interface.

Text message filtering explanation
Text message filtering - directions


User research showed that users wanted the option of being warned about fraudulent calls or blocking them outright. Thus, I designed a customize protection screen for premium users who had activated call protection.

customize call protection
6 Testing & reiteration

Test. Test. Test. More times than not, I am surprised by test results. And although they add time to the design process, I am always thankful for having conducted them.


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

Usability Hub - testing for desirability-top

From the testing 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.

original dashboard to revised dashboard


Presenting to the executive stakeholders, including the CEO, was probably the most challenging aspect of the entire process. Well, not really (submitting to Apple and getting rejected was the worst...more on that later).

Most of the feedback was positive. However, the CEO suggested we group Free and Premium features so as to differentiate them more.

I redesigned the dashboard and added labels Premium and Free at the top of the features. Then we ran a desirability test on the revised dashboard design and compared it with previous testing results.  

before to revised

The revised dashboard tested a little bit better. There were still comments about the background imagery being cluttered. But, as I told Anthony, it was a gamble I was willing to take. I stuck with the visual backgrounds for each of the 5 tabs, opting to take out a few details for each of the 5 tabs.

6.3 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. Because the application features web allow and phone allow lists, we needed a tab navigation at the top to differentiate between the two. 

The original design featured a custom tab pattern but the CEO urged us to go with the native pattern. I designed both and we tested both, asking the users, "how would you switch over to the web list". We ran an unmoderated test on 20 participants. 

Allow tab - native iOS component

native iOS segmented control

Free Dashboard with 4 protection modules

Free Dashboard with 4 protection modules

Free Dashboard with 4 protection modules

Allow tab - custom component

custom tab pattern

Phone allow list for users to add numbers to their white list

Phone allow list for users to add numbers to their white 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. 

7 Ch-ch-ch-ch-changes

Changes, in design, as in life, are inevitable. Whenever you think the design is nearly done, something is thrown into the mix. And you have to adapt. This situation was no different. 

Upgrade to Premium


We originally had 4 user states:

  • Free with Premium Trial
  • Free without Premium Trial
  • Premium Trial
  • Premium (paid user)

Because of Apple’s restrictions and some backend limitations, we realized we couldn't tell if a user has already used up the trial. Thus, in consultation with the PM and the engineering team, we decided to only have 2 user states: free and premium.

The Premium Trial would come in the form of free 30 days of Premium, similar to most subscription-based apps. Any Premium users who cancel before the 30 days are up would not get charged.

To make this fact immensely clear, we appended a message underneath the upgrade buttons.


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 raised over two tabs - allow and block.  

allow and block called out


The allow section allows users to white list (permit) sites that web protection deemed malicious and phone numbers flagged by call protection as spam or scam. 



The block section allows users to report fraudulent numbers to us and we would block or flag calls from these fraudulent numbers for the users. 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.



Those opposed to these two tabs argue that if users want to allow or block, then we have failed at our job. In essense, our application would be so reliable that such customization is not necessary, or at least shouldn't be so elevated.


A few people 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. 

Another person argued that most people would just whitelist from the deep link on the block page (we designed a somewhat hidden allow link into the web block page) instead of going into the application and manually typing out the URL. 


web allow process


Two people 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 him or her self. Anthony and I conceded this point.

People also argued that reporting a number would not be a commonly used feature and thus do not need to be so elevated in the IA. 

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

However, 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 of whitelisting 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.

Anthony and I were outranked. 

I moved allow and block to settings. I grouped phone and web allow lists under a manage allow lists dropdown. 

Revised settings - expanded
8 Prototypes

Throughout the design process, I made various prototypes to test out ideas and communicate designs to the engineering team. Some were pretty hackish. Others were more polished. Often times, I just used a narrative format to tell the engineers what should happen. 


Both allow and block lists have lists that will scroll as users add more numbers or URLs. I wanted to ensure the scrolling felt natural and indicated to the users the approximate length of their list.

I took a screen recording of me moving the list group within Sketch file and sent it over to the engineers, emphasizing the header shadow and the scroll bar (although it's not animated in this prototype).

list scrolling
Splash screen


For the splash screen, I wanted to utilize the very visual backdrop of the dashboard and animate in and out various layers such as mountains, clouds, and the main character - Zero. 

I used Principle for Mac to create the animation and sent an exported movie to the engineers. 

Because of time constraints, we ended up not implementing this animated splash screen. 


After Apple rejected our VPN web protection (more on that later), we had to come up with a new way to offer web protection.

One such solution was to offer different content blockers for Safari and allow the users to enable and disable each content blocker from within the application.  

Depending on the size of the database for each content blocker, the app would freeze all other actions for several seconds. I designed a loading animation, using Invision Studio, to indicate app status to the usrs.

We ended up not going with enabling and disabling content blockers from within the application. 

content blocker loading
9 Submission

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

The first two rejections were about copy and App Store metadata. The last rejection asked us to take out one of our biggest selling point - web protection through VPN. 


One of the rejections specified that 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. 

Upgrade screen changes


The third and last rejection was the most heartbreaking. Apple was no longer accepting iPhone apps with VPN technology. In fact, Apple is cracking down on existing applications using VPN. 

Our web protection, a premium feature, relied on VPN and DNS technology, was one of the greatest features of the entire app. We could protect users across all major browsers.  

Frustrated man by Tim Gouw

To address this setback, we decided to turn web protection into a premium content blocker for Safari. The solution was not ideal as we could only protect users using the Safari browser. 

This solution required several changes. 



The original web protection explanation showcased a block page (designed by Anthony). I had to redesign the explanation screen and use the new explanatory text provided by our content writer.

Web protection explanation screen


Both of these protection modules 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 wanted to append a crown emoji (to indicate Premium feature) 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

Free Dashboard with 4 protection modules

Free Dashboard with 4 protection modules

Free Dashboard with 4 protection modules

Safari settings_iPhone SE

iPhone SE

Phone allow list for users to add numbers to their white list

Phone allow list for users to add numbers to their white list

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

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

Free Dashboard_web protection warning dialogue

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



Design is never finished. As I am writing this afterword, we already pushed out version 1.2. Improvements include being able to toggle on and off call protection, web protection, and ad blocking from within the application after initial activation. 

Future improvements include usability fixes. One urgent need is to provide users an easier way of reporting fraudulent numbers. We have received numerous complaints about how hard it is to report fraudulent numbers. We might very well go back to the 5 item nav, with report number elevated in architecture hierarchy - this tested the best amongst all other solutions. 

Our app rating keeps on dropping; it went from 4.0 to 3.8 to 3.6 to 3.2 (as of 8/11/2018). Most of the complaints are about call protection. We had a technical mishap a few weekends ago, which rendered call protection inoperable. And call protection is the main reason why users download our application and convert to premium. Reading negative reviews is never easy, but it's necessary, especially when one wants to grow as a designer. 

This was the first application that I designed end-to-end and shipped! Despite the challenges along the way, the late nights, the back and forths with executives, I am grateful to have been given this responsibility and opportunity. 

Onwards to improvements and versions 2, 3, 4....and so forth. 

On a brighter note, someone pointed out that the use of the QR tag in this project was perhaps the only instance he did not hate.

And on an even brighter note, working on this project not only allowed me to practice the basic tenets of user experience design, but it afforded me the chance to really see the human element behind any design endeavor, no matter how mundane the subject matter.