Categories: control • update

Reciprocity

Contents

[Also Known As]

Fair distribution of efforts / Win-win situation

Context

In services where users may either socially or collaboratively contribute, participation may be a foundation for the service's business model. In these situations the quality and frequency of content affects the success of the service, and thus users have a large impact on its survival. Whether any single user contributes, or not, plays a role in profitability, which puts the controller in a position to encourage or enforce equal participation. Users may respond to such ideas negatively, however, especially if they do not see potential gains worthy of their effort and personal risks to privacy.

Problem

Equal participation does not always result in equal rewards. In some cases, participants do not need to contribute at all to benefit from the content generated by the group. Any who feel slighted are then likely to contribute less, eventually jeopardizing results for the group.

Forces/Concerns

  • Users may feel uncomfortable due to unfairly spread workload, and it could generate problems with the overall tasks' fulfillment. Some might decide to leave the group altogether.
  • Inequality may additionally generate a tense work or social environment.
  • Controllers want group dynamics to work so that content generation continues.

Solution

Limit the benefits gained from the group effort to the amount of effort contributed. All contribution should be afforded proportionate gains.

[Structure]

Ensure that all group members' activities result in an improved group result that is beneficial for all group members again. Prohibit people to benefit from group results if they are not willing to help the group in return.

[Implementation]

Prior to completing designs on functionality, determine the benefits as opposed to efforts or costs on all possible user activities. Weigh these, with input from any necessary stakeholders. Any feature which does not affect more than one user does not need to be assessed.

For user groups that are able to affect one another within a feature or functionality, consider them each a case for a collaboration mode. If a user within this group performs an activity, they are expected to reciprocate on any benefits (or gain from costs). This is in proportion to the weighted effort of the feature determined earlier.

The way in which users reciprocate is up to specific implementation. It may include required effort (satisfied by certain activities) before their activity's resulting benefit is realized. Alternatively it may prevent additional beneficial activities until they contribute. It may also make their discrepancy public, allowing the users to determine tolerable thresholds. In all these cases it is useful to keep track of each user's ratio within each collaboration mode they feature.

It is important that any use of user data is done so under the explicit and properly obtained permissions required. Deriving value from participation rewards users for providing personal information, and thus they must be informed about how their data may be used.

Consequences

Benefits

  • Finding the inequalities in the design phase involving all stakeholders can reduce the objections for participating to the system since the benefit is made explicit to the end-user.
  • Using this pattern minimizes reasons for groupware applications failure.

Liabilities

  • The pattern is only needed in situations, where the critical mass of participation can only be reached with most users participating. If the community is very large (e.g. a news group), it can succeed with a small number of active participants and a larger number of inactive participants (free riders, lurkers).
  • Consent given by users needs to be freely-given, which is a requirement easily overlooked as controllers are tempted to coerce participation. As with sunk cost, emotional investment can pressure users into choices they do not truly consent to. Therefore, Lawful Consent should be used in this pattern.

Examples

- Reddit - Gold: those who never 'gild' are set apart from those that do, as this fact is made clear within a profile. - Upvotes: while individual votes are not publicized, the votes received as part of contributing are. - Facebook Friends; LinkedIn Contacts; etc.: these relationships are one-to-one, to have a contact is to be a contact. - TUKAN; - Buddy Lists in Instant Messaging systems; - Bulletin Board Systems

[Known Uses]

TUKAN: The collaborative programming environment TUKAN introduced the concept of modes of collaboration (MoC) to ensure reciprocity. A MoC is a lightweight mode, which defines possible collaborative activities. It combines a specific level of privacy (cf. Masquerade) with the right of receiving information about other users. It thus provides a set of predefined Attention Screens. This combination ensures that a user can only utilize information from other users at a privacy level on which he is also willing to reveal personal information.

This pattern may be used by Incentivized Participation. It is complemented by Pay Back, which compensates without a focus on equal work for equal gain. It is also led to by Masquerade. The application of Masquerade allows users to potentially misuse a system, or benefit from it without contributing. This pattern addresses that issue.

Reciprocity may also complement Buddy List, as often these lists are reciprocal. It must use Lawful Consent, however, as motivating users to provide personal information should be done only along with informed, explicit, and freely-given (uncoerced) consent.

As per Schümmer (2004), it is also complemented by the following patterns which are invasive by design, but introduce useful notions: - Show the Expert (dark pattern), showing contributions prominently; - Who’s Listening (dark pattern), feedback by subscribers.

[Sources]

Based on:

T. Schümmer, “The Public Privacy – Patterns for Filtering Personal Information in Collaborative Systems,” in Proceedings of CHI workshop on Human-Computer-Human-Interaction Patterns, 2004.