A. Further updated task examples

The task examples outlined in Blog Update #2 remain unchanged. Please refer to this link for a comprehensive summary of the task examples.

B. Low-fidelity prototype(s) demonstration

An annotated version of the paper prototype (in PDF format) is visible here.

C. Additional information about the prototype

The prototype was designed to support all three task examples from the outset. We aimed to ensure that the three most salient features, as described in the task examples, were the core of the design; the minimization of bias, the aggregation of multiple news sources, as well as more granular control over the user’s news feed were the guiding principles during the development of the low-fidelity prototype.

To this end, we chose to use a social media news feed/timeline (e.g., Twitter) as our primary design analogy, as many of our participants from the MSII field study expressed a desire for a more real-time way of receiving news. This analogy furthermore allowed us to imitate social media’s core conceit of “following” specific political figures, allowing the user a greater deal of control over the sort of content they would see on their own particular timeline.

In addition, the idea of “user karma” was floated during the brainstorm process as both a means of giving users credibility without compromising their anonymity, and as a guiding framework for user-driven moderation. In this way, many of the issues and concerns regarding user anonymity are addressed. The “notifications” screen now reflects this score in addition to which shared news items are queued for moderation, as well as system messages regarding whether or not a user’s own shared news items were approved/rejected.

In terms of scope, we aimed to communicate a typical user workflow by defining the main screens of the app, but developing the bulk of the interface horizontally without diving into too much detail. As the interface itself was designed from the outset to be a streamlined news aggregator, we didn’t really need an enormous level of verticality to define the aforementioned workflow; the most detail went into defining the process of sharing a given piece of news.

D. Walkthrough report

The purpose of the Cognitive Walkthrough is to figure out how easy it is for new users to use the system, and to determine any issues early on in the design process before starting work on the medium-fidelity prototype. Throughout the cognitive walkthrough, here is the list of questions we ask ourselves as designers:

• Will the user try to achieve the effect that the subtask has? E.g. Does the user understand that this subtask is needed to reach the user’s goal?
• Will the user notice that the correct action is available? E.g. is the button visible?
• Will the user understand that the wanted subtask can be achieved by the action? E.g. the right button is visible but the user does not understand the text and will therefore not click on it.
• Does the user get appropriate feedback? Will the user know that they have done the right thing after performing the action?

Here are the findings from the walkthrough:

• On the ”Landing page”, user could be confused about the news feed with the “Sign in” tab. Specifically, user might directly click the news feed instead of the “Sign in”, and there is no feedback to indicate what user needs to do – Sign in as a new member of the App.
  • Potential solutions:
    • On the landing page, the interface only includes a “Sign in” tab. This way user shall understand that they need to sign in order to use this application.
    • Interface could have both “Sign in” and news feeds, but we as designers need to make sure that there is enough feedback. If user clicks on news feeds on the landing page, there will be an indication, saying that user needs to sign in first.

• On the “Suggestions for you”, user could potentially be confused since there is a filtering system to select user’s preferences.
  • Potential solutions:
    • Designers could take out this page completely as it conflicts with the existing filtering system.
    • Designers could keep this tab, suggesting users what political figures they might be interested in outside their preferences as a supplementary page.

• On “Repost page”, users could think that they need to write a summary in order to repost and there is no feedback to indicate otherwise.
  • Potential solution:
    • Designers could input a sentence in “Summary” that it is not necessary to write it in order to repost.

Beyond these issues, the user had no problem understanding the primary news feed, as well as the design conceit of “following” specific political figures, which was our main concern.

E. Proposed goal(s) of experiment for part B

From the design of the low-fidelity prototype, we decided to proceed with the following experiment goals, reflecting each of the core guiding principles that went into the development of the prototype. They remain relatively unchanged from our brainstormed experiment goals from previous milestones, but are listed below.

• Sharing: is the process of sharing a piece of news intuitive? Can users share pieces of news without making many mistakes?
• Filtering: is following/not following specific political figures a sufficient level of control/filtering? Should users have more control beyond that?
• Moderation: how much consideration do people put into moderating news in their queue? What sorts of news do people tend to rate negatively? Positively? Is this convenient?