Privacy Manager

Privacy Manager is a DARPA funded project which helps users protect information on their mobile devices.

Opportunity Space

The Brandeis Project is funded by DARPA, BBN, and Invincea, advised by Professor Jason Hong with the aim to achieve an order of magnitude improvements for mobile privacy.

With the prevalence of sensor-based smart phone apps, mobile data privacy is getting more and more complex. Every moment in every day, our mobile device collects our data, and it is for sale. So our opportunity space becomes:

How might we protect our data on smartphone devices and
make privacy vastly transparent in sensor-based smartphone environment?

Design Solution


Privacy Home

The Privacy Home interface presents users their Privacy Data Overview of the week.

Users can get a brief view of their current privacy understanding including "Typical" vs "Atypical" data access filtered by the most frequently used data category, such as Camera, Location, and Contacts.


Installation UI

The Installation Interface allows users to see detailed permission breakdowns, including "what" data is requested, "who" is accessing the data, and "why" is the data being accessed" from permission requests.

Based on the specific app category, the Install UI categorizes all data permissions by "Typical" vs "Atypical". Users can tap on to expand cards and easily configure privacy setting by swiping "On", "Ask", and "Off" three options.


Runtime UI

The Run Time Interface appears when an app tries to access data, but users set this specific app or data permission on "Ask".

It follows the same card format design and shows users transparency of the permission by identifying detailed permission requests by "who is using the data", "what the data is used for", and "why is the data being accessed".


Quick Setting

Quick Setting allow users to turn ALL app permission on hardware for a specific data setting "On" or "Off" at simple one click.

This feature serves well for those privacy-sensitive individuals who want to cut off their data and when not in use. It also fulfill needs for users who need to go to a confidential meeting or place and prefer to turn all permissions off for a specific data type such as "Microphone".


Configuration UI

In Configuration Interface, users are able to see all current permission setting for a specific data category.

Users can configure all current settings for this category by tapping on "All Permissions" feature. Users can also configure individual permission settings for a specific purpose.


Privacy Profile

Users can set up their personalized "Personal Mode" or add and activate their "Work Mode" via Privacy Mode Setting. Users can easily switch between profiles by tapping on "Activate" button.

Settings in "Work Mode" will be in view mode only and not changeable if users' organizations do not want certainly data to be used during work time or location.

Background ResearchLearn from UsersDesign IterationsIteration Round TwoFinal DesignsReflection



In the current mobile operating systems, apps usually tell users what permissions they are using (e.g. location, camera), but they would not tell users:

  • Why they are using these permissions (e.g. for advertising purposes)
  • Where they are sending the data to (e.g. to third-party libraries like AdMob)

In this project, we are building a future in which users would know all those information. ​After background research and heuristic evaluation on the current Privacy Manager system, we found the following opportunity spaces from the current Privacy Manager design:

We realized that if the apps users download had clearer purposes (inferred or declared by devices), we could create better predictive models of privacy concerns, which can scale to millions of apps and users.

Hence, what we propose to Android and iOS operating systems is to ask the app developers to break down privacy requests, help users recognize typical versus atypical data requests, and give users recommended privacy suggestions.

Since we are redesigning the entire privacy management experience in Android and iOS OS for vast majority users, we tried to break down the OS into five parts and listed our goals for each section: the Privacy Manager Home Pages, Install Interface, Configuration Interface, Run Time Interface, and Quick Setting Interface.

Our ultimate goal was to make privacy data permissions transparent to the vast amount of users, help them configure appropriate privacy settings base on their preferences, and at the same time, create intuitive user experience with our system complexity.

In order to achieve these goals, I initiated my design processes for Privacy Manager with these following seven steps: Heuristic Evaluation, User Research, User Interview/Card Sorting, Sketching & Wireframing, Medium Fidelity Design, and Usability Testing.

I started approaching the problem by understanding problems with heuristic evaluation in the current privacy OS, and then dived into user and background research where I could further understand users need and their pain points.

After several rounds of research, I conducted interview with target users in different demographic groups to dive into users' heads, so the products could better serve users’ needs. We also used methods such as Card Sorting to find out information hierarchy of the product details. All the brainstorms of sketching and wireframing are followed by usability testing, and then repeat the steps of iterations for the final round of prototype.


User Study

In order to better understand our customers, we divided our target users into four groups: the young millennials, the working professionals, the elders, and the privacy highly-sensitive groups for our client DARPA: the military.

    We found interesting contradictions among our users after research and interviews. While 87% of the users stated that they rarely configured privacy settings, surprisingly, they still remained sensitive about their privacy data. In fact, more than half of them didn't know that their information was used or sold to third-party advertisers. Most notably, users felt they didn't have control over their privacy.

    While most users care about their privacy and how their details being used, on the other hand, they stated that the current privacy system forced them to agree to privacy requests that they didn't want before they even download any apps.

    Users were worried that the apps would not function properly if they denied the data access. Some other users indicated that they had no idea what their information was sent or sold to third party companies.


    Design Iterations

    To help us better understand the flow between each parts of the privacy settings, I led the team to draw out the flow diagram which demonstrates the information architecture of the privacy system, including the triggers that will activate each part of the flow, and the connections among those sections.

      Detailed information architecture is presented below. After the information architecture is laid out, we started brainstorming on the prototype which captured users' needs and our complex information architecture. The prototype would include the Install Interface, notification, and quick settings. For each section, there are several iterations behind the finalized version.

      As an example. three different versions of the Install Interface are illustrated below. The first iteration considered only to display all the information, but the second and third iterations brought up the new concept: "Typical " vs "Atypical" requests based on user research feedback. The third version considered circumstances when privacy permission scales up and exceeds the current container box.

      My initial prototype focused only on detailing privacy settings for different purposes and defining what data is being accessed , why the data has been requested, and who is trying to access the data.

      Instead of directing users to another page, we designed pop-up box on the same page, so users will have a less obtrusive transition. We broke down the problems into categories by listing out the Atypical Settings on the top, and collapsed Typical Settings for this app categorization.

      First version categorizes permissions by “typical” and “atypical” settings. We wanted to add an “ask” option for users so the users can set permission settings only when the data is accessed at the moment. Users can click on the downward arrows to view more details regarding the specific permission.


      Iteration Round Two

      Since we are designing the Privacy Manager which will be used for all mobile users, we strived to make the interactions as seamless as possible while delivering all the necessary information users want to know.

      We wanted to make our design simple to use and easy to adapt for all age groups. Hence, we experimented the Card Sorting research method after the first round of design. The purpose of Card Sorting was to understand what information users care about the most when they configure a privacy setting.

        After five rounds of Card Sorting exercises, we realized that 80% of users payed more attention to the “purpose” and “data type” of a privacy request. Users also inclined to look at all the privacy information together to judge if their data was used properly.

        After users interacted with Privacy Manager in the Install UI, We also wanted to allow users to come to Privacy Manager home Screen to gain more knowledge about their privacy standing. They will have access for more detailed configurations at Privacy Manager Home Page.

        We examined the previous design for Privacy Poliy Home Page, and found the following problems that we could improve on:

        • Information is too overwhelming for users who have multiple privacy settings to consume under the privacy same category.
        • Data from Privacy Overview is not clear enough to users to grasp critical information at the first glance. Feed forward for interaction is not explicit enough.
        • Privacy Yearly Report is not a common feature that users access. The top section is usually utilized to position the most important feature or information.
        • The purpose of the data trend on the home page is not clear. Six-month is too long for users to grasp their privacy overview.


        Final Iterations

        From the previous user testing results, one of the big improvement opportunity we found out that our design might be too overwhelming for users to see at the first place. Aggregating results from previous Card Sorting rounds: users care more about data type than data purpose. We decided to adopt expandable cards which brings data type as the first layer of information.

        Expandable & Collapsable Cards

        (Previous vs. Now)

        The expanded cards will firstly give users an overview of the privacy request. At the same time, the progressive disclosure strategy helps users to reduce their cognitive load by allowing them to grasp an overview of the privacy permissions before diving deeper into configuration.

        Privacy Overview Visualization

        (Previous vs. Now)

        From previous research rounds, another critical opportunity space we discovered was that some users experience a hard time consuming their privacy data on home page. Hence, we decided to show our users a more direct way in grasping Privacy Overview. The new design not only gives users a brief view of their current understanding, but also the proportion of Typical vs. Atypical accesses. Users can browse through different data types and see the trends by clicking on the taps on the right.

        Allow Configurations at One Click

        (Previous vs. Now)

        We further realized that when there are multiple privacy settings under the same category, and it became a hassle for users to configure individually. To solve this pain point, we introduced "All Permissions" feature, which allows users to configure all privacy settings under the same category at simple one click. It simplifies privacy configuration for all end users.

        Other Explorations

        More Ideas

        Privacy Rating

        Privacy Rating is a new idea that I came up with to encourage users configure their privacy setting.

        After Think Alout testing with users, we realized that users are more motivated to change or find out what's wrong with their privacy when they see the score is not perfect.



          Our project has not ended. We are in the process talking to many sponsors and partners, such as Google and Apple. If I were given more time, I would conduct user testings with more diverse groups, such as the seniors and users with disabilities on current design to make sure that our design is inclusive enough for all user groups.

          In the meanwhile, I would love to explore the admin version of the Privacy Manager system. For DARPA users who would have a fixed privacy settings for a group, I would love to explore how Privacy Manager could scale up for this user scenario. In addition, I would love to build on-boarding screens to walk users through Privacy Manager flow and introduce critical features for each section which will help to reduce learning curve users might encounter coming to the new interface.

          If you are interested in learning about our progress, I am always happy to chat more details!