HFID :: Design Refinement

Revised Interface Design

The Past (UI Redesign)

At the end of the previous phase we made the decision to move forward with the privacy constructor prototype that we had tested, despite mixed feedback from users. Although many users strongly supported the concept, others were skeptical about the degree of effort that they would need to put in in order to get their profile set up the way they wanted, and disliked the complexity. Identifying this, we wanted to modify our prototype to better serve these users by simplifying or clarifying various interactions in the profile constructor model.

Facebook's current directory settings (left) are access from a barely noticeable hyperlink on the privacy settings page. In our re-design (right) directory settings are brought forward into the live profile preview.

One of the largest areas that we wanted to approach was the existing directory settings page on Facebook. It is currently unclear which settings affect directory information and which are standard privacy settings. To improve user access and understanding, we worked very carefully to figure out the correct way to integrate these slightly disjoint settings into a profile. We also encountered these issues with posting privacy settings, as users need to be able to control both who can post to their wall, who can see their wall posts, who can comment, who can check them into places, and so forth. To deal with both of these concepts we introduced analogous sample content - on the Wall tab fictional posts appear that say what they represent in terms of viewing or posting privileges so the user can decide while still having very clear knowledge of what they are controlling - just as they do when they can see their content for individual privacy settings. For actions based settings from the former directory settings screen we added labels for them below the profile picture, where they might normally appear, and a search icon next to the user's name. We made these changes hoping to get feedback on our prototype about how intuitive the interactions and labels are for users, and anticipate making changes to ensure users can decipher settings quickly without needing to think about them.

We also spent a lot of time figuring out how we would best deal with the concept of exceptions. One of the main complaints users had with our dual profile model was the lack of flexibility in restricting friends from seeing content - many felt that they would be impairing who can view what on their profile by fitting within that model. At the same time, the proponents of dual profiles enjoyed the simplicity and liked not being able to add hundreds of individual exceptions which would be confusing to figure out the exact implications and effects of. Our top priority in exception handling and creation is to make it an easy process that helps prevent conflicting exceptions. By linking these exceptions directly to friend lists we were concerned that users would have two different paradigms - friends and lists - to add to their exception groups. In addition, if a friend exists in multiple lists, it would be very easy to create conflicts that cannot be easily resolved. We decided that exception groups would not be linked to lists, so that if a user adds a list to a group it will instead add the names of all of the members of that list to their exception group. When conflicts arise, a dialog box will come up asking them which exception to keep the user in. We hope that this design will make conflicts both unlikely and very easy to resolve.

Another unforeseen concept that we needed to flesh out was the inheritance of permissions. Although it never came up in paper prototyping, we needed a system to determine how changes within privacy groups affect visibility of elements in either broader or narrower groups. Under the current Facebook system it is impossible to create conflicting settings, such as preventing friends from viewing an item while allowing "everybody" to see it, but our prototype would allow such illogical settings without forcing settings to inherit from broader categories. We decided on all exceptions overriding other settings, so as to give users full control over the ability to include or restrict permissions. For settings within networks and privacy groups, though, it is conceivable that a friend might exist within more than one setting (e.g. A friend of friend is in one of my networks, and thus has two groupings of settings applied to their view of your profile). The solution we have for this is "the union of most permissive settings." Essentially, a user is given the maximum amount of permission afforded by any settings that apply to them, even if they mix and match between different groups. This model makes the system easy to manage, and gives users a clear explanation of how inheritance will work rather than leaving it as a complicated and undefined system.

Hovering over profile elements presents a subtle dashed outline. The visibility of each element can be changed on click, resulting in a change in visual opacity.

One of the most fundamental elements of our prototype is the visibility toggle of profile elements, and how users discover and interact with this system. In our paper prototype we used solid vs. dotted borders to represent unselected and selected items, as well as to indicate which elements were selectable at all. Users told us that this was not very intuitive and they didn't feel very confident in it, so we tried to come up with other concepts to expose visibility. Our prototype separates the concept of selected/unselected from selectable, though, in order to make the latter as clear as possible and easy to discover. Our current implementation fades out unselected (and thus unpermissed to that privacy group) items and leaves selected ones at full opacity. We had considered using drop shadows or zoomed boxes for these, but decided against them both for implementation time constraints and because we were worried these might be too intrusive.

To make sure that users could discover what was selectable, though, we added borders to each element when the user hovers over them to expose it as a selectable element. We are considering using zoom to expose these elements - because they are temporary we can use a more invasive indicator.

A key component to our concept's success is the ease by which a user can pick up the interaction paradigm, and understand what various settings actually do - specifically for action based permissions, like sending messages. We briefly considered adding non-intrusive notifications that would appear with help text on what the implications of changing various settings are, but did not have the time to get it into this prototype, and are considering based on feedback we've received whether or not they are necessary.

The Present (Interactive Prototype)

The interface as it exists in the prototype is explicitly designed to mimic the look and feel of a Facebook profile page, with the intention that users will be able to switch quickly between their profile and privacy settings and immediately know the locations of all their content settings. This goal, including preserving the vocabulary of Facebook, was aimed at maintaining a consistent interaction throughout, as we understand that privacy settings form just one part of a larger ecosystem that users work within.

Conceptually, the prototype allows a user to switch between 'pivot' categories and select or deselect content elements in a mock-up of the user's profile to change the visibility of those elements to other users that fall under that category. The prototype is formed from the pivot bar on the left, which allows users to select between editing settings for basic categories such as "Everybody" and "Friends Only" as well as their networks and individual exceptions. The entire right of the page is a preview of their profile which generally contains the same content as their actual profile, although as mentioned earlier the Wall tab uses fake posts to indicate categories of interactions users may have with their Walls. Each editable element has a dashed border appear when a user mouses over it, indicating that it can be selected, and when clicked, fades either in or out to show its visibility to the pivot currently being edited. By scanning the profile preview, users can quickly see which information a specific group may view.

As one of the major goals of the prototype is to improve user confidence in Facebook privacy settings, the system automatically saves settings to its database every time the user changes pivots, and displays a "saved" screen effect briefly to reassure the user that their changes are maintained. The database is currently not persistent between sessions, but in context the design would save these changes as the user edited them.

To create our prototype we used a combination of static HTML and CSS elements with dynamic Javascript and JqueryUI. Our burden of work was eased slightly by the CSS theming that had we had previously created for our project website, but the major issue with the tools used was the amount of work required to create a functioning prototype. JqueryUI functions and effects dramatically sped up the development of our Javascript, but we had to construct an entire database back end essentially from scratch to meet our needs, as well as create all of our visual elements by hand to maintain the consistent look of our interface.

However, with the cost in effort we gained greatly in quality, producing an attractive and functional prototype that meets our design goals and is flexible enough to allow us to add missing functionality and update our design to respond to critiques of the system at the end of this phase. As these tools are ones that Facebook currently uses, this prototype could be updated to create a polished, shippable product without requiring transitioning between technologies.

The Future

After building our first prototype and presenting it to peers for heuristic evaluation, we collected feedback from the evaluators. They provided feedback on numerous problems, and suggested new features. We will proceed by addressing these issues and finishing up left over features we did not include in this first deliverable.

We will explore different ways to solve a number of problems we encountered. This will include considering visual elements to distinguish different wall posts and the effects of changing their visibility. We will also explore the idea to include two new buttons: select all and clear all. This new feature, suggested by our peers, would improve the user experience when using different pivots. For example, default view settings may be either permissive or restrictive. Users may want to build out settings from the opposite condition.

We also did not include certain planned features in this prototype, such as the features of the Exceptions element. When complete, this feature will include the option to choose from a list when typing in names and allow friend lists the user might have created already. Additionally, to show users the various pages on which they change privacy and applications settings, an introduction page that will give some easy and short instructions on how does this new privacy setting work and how to take the most of it.

One of the major systems left out of this prototype was album-level privacy settings controls, in part because of the complexity of the system, and in part because we were not sure during the phase whether photo settings would exist within the same system as other settings or, as it is currently, on the individual albums' pages. In the final system, a Photo Privacy page separate from the other privacy settings will allow users to have more detailed control in managing their photos, photo albums and photos they are tagged in. They will be able to choose to manage them individually or as albums.

Finally, we will clarify the use of the auto save feature by exploring ways to better explain how it works and decide whether or not to include a button or another label element for it. By refining our prototype and adding these necessary features, we can fulfill the design goals we have set for ourselves and provide a richer and more usable privacy settings interaction.

Cognitive Walkthorugh

Our first high-resolution comp, which incorporated all the elements of the updated UI design.

We used the cognitive walkthrough methodology to test the first refined iteration of our prototype, which was modified according to feedback received in the design development phase. We tested this prototype according to the four main task scenarios defined in the previous task, which included: changing directory settings, restricting an individual from viewing specific profile content, restricting different groups from seeing different types of content and adjusting photo privacy settings. We expanded each task into detailed action sequences and analyzed each using the following four questions from Gregory Abowd's cognitive walkthrough methodology:

  1. Will the users be trying to produce whatever effect the action has?
  2. Will users be able to notice that the correct action is available?
  3. Once users find the correct action at the interface, will they know that it is the right one for the effect they are trying to produce?
  4. After the action is taken, will users understand the feedback they get?

Directory settings like "profile searchability" are now included in the love profile preview. This marks a significant paradigm shift to how directory settings are dealt with in Facebook.

The cognitive walkthrough helped us confirm that a number of key interactions in the interface were clearly accessible and understandable to the user. In addition, it highlighted some specific weaknesses that we used a basis for further iterating and improving on our ideas. In the changing directory settings task, for example, we realized that previously experienced Facebook users might actively look for a dedicated directory settings link - we decided to remove this current model from our design after hearing a lot of negative feedback about it in the Needs Analysis assignment. Our new approach involves integrating directory settings, like the ability to search for your profile or for people to send you friend requests, directly into the live profile preview (see image above). For setting searchability, for example, we now require the user to click on his/her profile name (brief instructions highlighting the ability to do this are also featured in the design). This marks a significant paradigm shift in the way directory settings are dealt with. As such, we are still in discussion as to whether we need to provide additional prompting/instructions for the user.

The privacy pivot panel does not clearly communicate the concept of hierarchical privacy settings to the user.

Another issue that may limit user's understanding of our system is the lacking information about how the hierarchy of privacy settings functions. By providing users "pivots" to see and edit what their profile looks like to different groups on Facebook, we have significantly changed the original paradigm of how privacy settings are dealt with on the network. Some of users mentioned concern over the "myriad of overlapping settings" presented by the new prototype - we have to make it clear how settings will prevail and will be inherited between the major pivots ("Everyone", "Friends of Friends" etc.), Networks and Individual Exceptions. We have currently addressed this by including explanatory text at the top of the page, but the walkthrough also raised the possibility of including hints directly in the privacy pivot panel.

The main concern raised for the restricting groups from seeing certain information task was how the profile for a newly added exception should be populated, especially if this exception contained multiple individuals. We decided that we would show the same settings as the user has set for the "Everyone" pivot, as these would theoretically be the most restrictive set. The user can then proceed to modify the live profile preview as desired.

We worked on a number of iterations for the photo privacy settings interface, with one model allowing the visibility of individual albums to be set for each privacy pivot. From what we know about our users/personas, we eventually agreed that this would not be a desirable way to deal with photos. Instead, we would revert to the existing paradigm, where the privacy settings of each album would be controlled, separately from any of the pivots. Therefore, we decided to move the photo album privacy settings on to a separate dedicated page and to have the visibility of profile pictures and of "photos I am tagged in" editable directly within the live profile view. When initially proposing this model, we realized that the original tagged photos settings button was to small and, therefore, we decided to change the labelling of the "Photos" profile block in privacy editing mode to "Photos of me". The photo album privacy settings page would be accessed from an introductory privacy settings page similar to the one currently used by Facebook. Both the photo settings page and introductory privacy settings page were not included in the first interactive prototype and will be mocked up and integrated into the fully functioning prototype in the next design phase.

Prototype & Instructions

Click Here to view our first interactive prototype

Based on the insights gained from the Design Development phase and our paper prototypes, we development our first interactive prototype to be shared for heuristic evaluation with other teams. Developing this prototype was important for testing and fine-tuning of the key interactions within our system, including the toggling of visibility settings, the switching between "pivots" (perspectives of how different groups on Facebook can see your profile) and more. We were also able to test some of the design refinements that we developed at the beginning of this phase including handling of exceptions and directory settings.

For optimal performance, please run the prototype in the following browsers:

  • Mac OS X: Google Chrome, Firefox, Safari
  • Windows: Google Chrome, Safari
  • iPad: Currently not supported

Tasks for Heuristic Evaluation

We are interested in gathering your feedback related to our interactive prototype and have prepared a number of tasks to be used for the Heuristic Evaluation. Please note that the prototype is not yet fully functional and that we are still working to refine some of the technical functionality of the system (see the "Known Bugs" section below).

  1. General profile setup
  2. Change your Facebook privacy settings such that only friends can see your photos, that everyone can see your wall posts, posts by other people on your wall and that can also comment on your posts.

  3. Modifying "searchability"
  4. Make it such that others (everyone) cannot search for you via the Facebook search bar.

  5. Silver bulleting
  6. You would rather that your boss not be able to view posts on your wall. Restrict his ability to view content on your wall.

  7. Settings for multiple groups
  8. Make sure that your family can't see certain content, like your updates, and that your work colleagues can't see other content, like your photos.

Known Bugs and Missing Features

There are a number of known bugs, missing features and incomplete functionality in our system. The items listed below do not include the visual bugs within the system, which will be address and refined as we continue development on the prototype. Instead, the listed items represent interaction limitations that we are aware of. Despite this, we are confident that the system has been developed to a level where meaningful heuristic evaluation can take place.

Some of the known bugs include:

  • Lacking feedback to show the inheritance of privacy settings between privacy pivot groups. The backend functionality addressing inheritance does work, however, such that relevant settings changed in "Friends Only" will be carried through to "Everyone", for example.
  • Interactions are not as obvious as we intended them to be. (We still want feedback on this though.)
  • The auto-save overlay is visible on first load.
  • The revised photo privacy interactions described in the previous section are not included in this version of prototype.
  • Currently, you are only able to add one privacy exception, whereas our system is designed to add multiple.
  • It is currently not possible to edit or delete an exception.
  • We intend to build a "privacy intro page" that the user would encounter when navigating to the privacy settings page on Facebook. This intro page would include three links to profile, application and photo privacy settings (including individual album and default photo privacy settings). Our prototype represents the profile privacy settings page.

Heuristic Evaluation

A comprehensive heuristic evaluation was performed on our first interactive prototype by a team of other students from the class. The insights gained from the heuristic evaluation report and discussions with the team will be considered during design refinement of our prototype in the coming phase. You can view our responses to their most pressing issues on our Heuristic Evaluation page.

Click here to download the heuristic evaluation report

Click here to view our responses to the Heuristic Evaluation

Class Presentation

At the end of this phase, we gave a 10 minute presentation to our professors highlighting our team's progress so far, the development of our design and some of the lessons learned during the first half of the semester.

Click here to download our mid-semester presentation


We've consistently been having difficulties representing true team effort in the effort table model suggested for our write-ups. We don't feel that the percentage system works well in appraising individual effort because a stellar effort by one team member diminishes the efforts of all others instead of increasing the total team effort. We've noticed in this phase more than any other a profound difference between the amount of time spent by a team member and the produced outcome of their work, particularly due to the team's prior knowledge and skills in certain areas. Assigning different levels of effort to tasks of equal difficulty based on whether we completed them quickly or slowly doesn't seem to fulfill the spirit of the assignment.

We suggest a system of awarding Kudos to recognize team members' true standout efforts, as it promotes cooperative achievement rather than competitive one-upping.


  • Xy for building our backend database from scratch and for assisting with code debugging/web development support.
  • Joaquin and Jeffrey for learning Javascript and Jquery in order to build significant components of our design, having had no prior web development experience.
  • Chris for building the high-resolution comp model and implementing pivots.
  • Ollie for constructing the HTML/CSS website layout, providing web development support and completing the Cognitive Walkthrough writeup.