HFID :: Heuristic Evaluation

External 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.

Click here to download the heuristic evaluation report

Revised Prototype

The revisions completed on our prototype can be seen in the User Testing section of our website, as we implemented them all before running our informal usability study on saving paradigms.

Click here to view our user test plan and revised prototype

Redesign Description

In response to the feedback we received during the Heuristic Evaluation with other class members, and reacting to some of the prototype flaws that we had wanted to fix, we made significant changes to a number of interactions for our prototype going into user testing. The major areas we investigated were Saving, Exceptions, Post Visibility, Discoverability of concept and of selectability, as well as minor flaws and bugs in the design and code that runs the prototype.

Our Heuristic Evaluators indicated that one of their concerns had to do with the concept of auto-saving, which we had built in to our site aiming to increase user confidence by showing them a screen that confirmed their changes were being saved. This screen, however, is distracting and slow, and only appears between changes on the page - there is no confirmation of saves when the user leaves the page. Following our evaluators' advice, we brainstormed a number of potential fixes to this but were not confident in making a single decision without more data. We have flagged this as an important issue and are planning on running our usability test on our concepts, which are explained on their page.

Exceptions were an area where, unfortunately, we did not get a great deal of HE feedback because our prototype lacked full functionality. We are not modifying the Add Exception dialog to allow the user to select either lists or persons for the exception in addition to the current ability to name it, simply because we do not have time and this is not crucial to our current goals. Exceptions can now be deleted from the pivot group selector however, so they are no longer immutable static entities on the page after having been added. This will give users the level of control we intended to customize their settings extensively to fit their own model of personal privacy on Facebook.

Our representation of the Facebook wall changed from a more contextual (left) to a settings-based paradigm (right), based on heuristic evaluation feedback.

Post Visibility was the largest area where our evaluators found significant flaws in our design. Because they could not deduce that our posts were merely samples, they were incredibly confused about what settings would be changed by clicking on the fake content - and were unsure if real content would be displayed in a fully functional prototype. Because the verbs behind these actions were what seemed to be causing the most friction with them, we decided to change our "sample representative wall posts" to be descriptions of the kinds of posts you might control, and the kinds of actions you might control. The revised controls separate between visibility and permission to post, and use representative icons and descriptions to make it clear what a user is selecting. It uses questions as descriptions to cue the user into thinking about whether or not the current group ought to have permissions for a given item, and we have been receiving positive feedback on this concept.

Discoverability of our concept, as well as discovery of the selectability of elements, is something we continue to try to improve upon. We changed our heading text to further imply how the prototype functions, and modified the styling that appears when hovering over profile elements. Although in an ideal world the page would present a quick, interactive, and immersive walkthrough of how the prototype functions on first load, this is outside the scope of our available time. Based on HE feedback we did decide to add a small toolbar to the page that allows a user to select all / deselect all / undo changes on a pivot. This gives them a chance to make sweeping changes on any single pivot rather than start with Facebook's default settings, and lets them roll back if they weren't sure about what they just did.

Note: In the final prototype we removed the selecting toolbar based on user feedback that it was very obtrusive

Finally, in addition to the minor bug fixes of design and underlying code, we also added a very small acknowledgement in the corner of our prototype. When clicked on, it presents inherent assumptions about our conceptual model of Facebook so that people viewing our profile can understand some of the things about Facebook we are taking to be inherently true. Without this information hinting at the design of our prototype, we fear that people assessing our work without our background would be lost.

Unfixed Heuristic Evaluation Issues and Justifications

"The same as above goes for likes and interests. Maybe I'm fine with letting everyone know the music I'm into, but not that I put (for instance) "Cuddling" in my favorite activities."

This references another inconsistency which was fixed: "Not all employers are the same. The user might want to allow some past jobs to be visible, but block others."

Because this is not functionality currently offered by Facebook, we chose to omit it. Many Facebook users like a lot of pages, and offering an interface to allow them to individually cull this list for a number of different groups of people is burdensome. Although restricting employers or contact info is a logical and sensible action, if someone truly wishes to dissociate with an interest it might be in their better interests to remove it from their profile. We did not want to significantly extend the functionality of facebook by offering this feature.

"No ability to select what info goes in your small summary information bar. I think you can do this currently in facebook, and is a desirable feature."

This is already an existing feature in Facebook, and is controlled from viewing one's profile and clicking the edit button on any of the boxes in the left hand summary pane. Because this is controlled on an overall basis, and all of the information in that pane which can be hidden can be displayed elsewhere, we decided to leave it off of the privacy page as it does not deal with individual privacy.

However, based on this we have a new assumption of our prototype as to how it relates to a real, full interface. When viewing the preview of one's profile while setting privacy settings, the left hand pane will only display the pieces of information they have set elsewhere. Thus, it will match what their profile does look like, not what their profile could look like, which is a departure from how we control actual privacy settings in showing everything and selectively greying things based on visibility. We do feel that this is intuitive to users, however.

"Doesn't seem like any of your personas would chose to hide "Send me friend request." Should this option exist?"

This is functionality that currently exists on Facebook which we wanted to retain, as a number of users would like the ability to hide themselves that extensively on Facebook. Although none of our personas imply that they require this functionality, it is possible that one might desire it. It is also a more accurate representation of the content available on a profile, and just as with searching and sending messages we wanted to represent control over all of the verbs other users can initiate on your profile.

"I'm pretty sure that facebook allows you to send anyone a message, regardless of other settings, as long as you can see they exist on facebook."

This setting does exist, although the default which most people do not change is "Everyone." We chose to retain the setting for very similar reasons to why "Send me a friend request" was also incorporated.

"For the about me, contact information, and education sections on the Info page there is no way to select all of the category, the user has to go down the list selecting each one."

We feel that it will be misleading to users to be able to individually select elements as well as entire groups of elements, but more importantly, there is no intuitive way to reflect selectability of groups. We are concerned that users would accidentally discover it as a non-obvious interaction, and then think that they had made a mistake and lose confidence in the process.

In response to this desire to deviate from the default Facebook settings drastically we have added a global select all/none for the entire profile visibility of a given group. This will help with users who want to make a very large and comprehensive settings change.

"Starting an exception doesn't carry over the preferences from the group you were just in. This requires you to re-enter almost all of your preferences into the new group."

When adding exceptions we think that users will expect the settings to appear similar to the users that are contained in the setting, not whatever page they are viewing. Presumably they are thinking of a user in a group when they are adding an exception, which is why our evaluators expected that currently visible page - which sparked the exception idea - to be the settings.

However, the way we intend this is that the exception's default settings on first creation will be the most universally permissive settings of all members of the exception. Essentially, whatever information all of the users in an exception can universally definitely see will be the default, and the user will work from there to create the exception. This only applies on creation - not on modification of an exception.

"Doesn't differentiate between different personal information in terms of commonly perceived sensitiveness. For instance, most (not all, of course) people are quite fine with letting strangers know their gender, but many would be uncomfortable with broadcasting their relationship status, political views, etc. to the greater internet. Someone is more likely to accidentally censor some info they are comfortable telling others instead of something they don't want others knowing."

In order to increase user confidence, we chose to sacrifice some of the possibility for portraying the sensitivity of different types of information for a live profile preview. We know that there might be different ways of grouping information, but they might be more confusing to users in understanding that they are exactly controlling visibility for.