Skip to content

Latest commit

 

History

History
103 lines (83 loc) · 9.94 KB

FRAMEWORK.md

File metadata and controls

103 lines (83 loc) · 9.94 KB

Gamification Design Framework for a Wiki

References

Define business objectives

Why are you gamifying? How do you hope to benefit your business, or achieve some other goal such as motivating people to change their behavior? As you state your objectives, emphasize the end goal or goals of your gamified design rather than detailing the means through which you'll achieve this goal. Basically, if your gamified system does what you intend, what specific positive results will it generate for your organization?

  1. Increase participation in viewing, contributions, discussion pages, and reviewing wiki content
    1. 100% for those in CX by _____ date
    2. Increase by those outside CX - 20 more active users from EC/XX/MER/OneEVA by _____ date
  2. Improve validity of data in wiki (how can we quantify how much we trust data in the wiki?)
  3. Increase user awareness of why their contributions are important (revisions, discussion, pending reviews). This isn’t a direct benefit to the group or to the wiki, but this will indirectly support the wiki through intrinsic motivation -- giving our users more reasons to spend their time contributing.

Delineate target behaviors

What do you want your players to do? And what are the metrics that will allow you to measure them? These behaviors should promote your business objectives, although the relationship may be indirect. For example, your business goal might be to increase sales, but your target behavior could be for visitors to spend more time on your website. As you describe the behaviors, be sure to explain how they will help your system achieve its objectives. The metrics should in some fashion provide feedback to the players, letting them know when they are successfully engaging in the intended behaviors.

  1. General Usership
    1. Increase wiki page views in general (Wiretap)
      1. 100% of CX views wiki x times in y days by z date
      2. 20 more active users from EC/XX/MER/OneEVA view wiki x times in y days by z date
    2. Increase contributions in general (Watch Analytics?, Contribution Score, new extension?)
      1. 100% of CX contributes (edit, new page, etc) x times in y days by z date
    3. Increase discussion page usage (Watch Analytics?, Contribution Score, new extension?)
      1. 100% of CX contributes to discussion pages x times in y days by z date
      2. 20 more active users from EC/XX/MER/OneEVA contribute to discussion pages x times in y days by z date
    4. Increase use of Meeting Minutes (Meeting Minutes)
      1. 100% of CX creates Meeting Minutes x times by z date
    5. Increase use of Related article (Meeting Minutes)
      1. x% of Meeting Minutes topics have at least one valid Related article by z date
  2. Validity of Data
    1. Document SMEs (CX custom)
      1. 100% of ORU/Tool/EMU Component/Generic Hardware pages have SME assigned by z date
    2. Document CX personnel qualifications (CX custom)
      1. 100% population of user page info (certs, cadres, EVAs and missions worked) by z date
    3. Increase page watching (Watch Analytics)
      1. Increase number of CX watchers of every page to at least 2 by z date
      2. Increase number of EC/XX/MER/OneEVA watchers of relevant hardware pages to at least 2 by z date
    4. Improve page review cycle (Watch Analytics - Pending Reviews)
      1. Reduce average number of pending watches for every CX user to x by z date
      2. Reduce max pending time for every CX user to x by z date
      3. Reduce average pending time for every CX user to x by z date
      4. Every page is viewed (and thus briefly reviewed) every x days (by CX)
      5. Increase pages marked “Update after” by CX people
      6. Pages marked “Update after” are reviewed by x CX people
      7. Phase 2 should extend these target behaviors to EC/XX/MER/OneEVA
    5. Increase citations of references (Cite, Citoid?, new extension?)
      1. Every “factoid” should either have “citation needed” or a citation
      2. Opinions should be noted as such using Template:Opinion
  3. Demonstrate Value
    1. Thank/acknowledge others’ contributions (Watch Analytics?, Echo?)
      1. 100% of CX recognizes another CX user’s contribution that benefitted them x times by z date
      2. 100% of CX recognizes contribution by EC/XX/MER/OneEVA that benefitted them x times by z date
    2. Acknowledge when a page answered a question (New extension)
      1. 100% of CX clicks a button to acknowledge when a wiki page has answered a question they were looking up x times by z date

Describe your players

Who are the people who will be participating in your gamified activity? What is their relationship to you? For example, are they prospective customers, employees at your organization, or some other community? And what are they like? You can describe your players using demographics (such as age and gender), psychographics (such as their values and personalities), Bartle’s player types, or some other framework. You should show that you understand what sorts of game elements and other structures are likely to be effective for this population. For example, you might discuss whether a more competitive or cooperative system would be better for this player community.

While targeted at CX, the framework should be implemented to target any enterprise wiki user. This approach might also serve public wikis like Wikipedia, but there are some significant differences between public and enterprise wikis. The core target of this framework (CX employees) interact with other organizations, all in support of ISS operations. In some relationships, CX is the customer. In other aspects, CX is the service/goods provider.

Individuals in this target group range from young professionals just out of college to the seasoned career worker who used to do everything on paper. Some people gravitate toward using a wiki while others reject it and avoid it at all costs. There is approximately a 50:50 gender ratio. Some users are type-A extroverts and some are more introvertive. Most if not all of the people in this group have a strong allegience toward mission success. So use of the wiki must be worth their time and effort.

Player Types

There will likely be people in each of these four groups, with some overlap.

Acting on Players - Competing (challenge, showoff, compare)

While we can include some competitive features, we should be careful to over-do it. The emphasis in this environment needs to be working as a team. Either the team wins or the team loses. It's not about a single individual. So some competition between sub-groups within the org might be better.

Acting on Content - Self-Expression (create, build, design, customize)

While templating is used heavily in our wiki, we need mechanisms to allow creative people to express themselves.

Interacting with Content - Exploring (view, collect, review, curate)

Features for exploring are critical in this environment. We want to encourage each person to discover content they have not yet seen. We want to stimulate conflict in order to settle otherwise unrealized discrepancies. We want everyone to share the workload of reviewing revisions.

Interacting with Players - Collaboration (share, comment, help)

For those people less technically inclined, this might be their niche.

Devise your activity loops

Explore in greater detail how you will motivate your players using engagement and progression loops. First, describe the kinds of feedback your system will offer the players to encourage further action, and explain how this feedback will work to motivate the players. (Remember: rewards are only one kind of feedback.) Second, how if at all will players progress in your system? This includes how the system will get new players engaged, and how it will remain interesting for more experienced players.

Make sure these activity loops appear to providy autonomy. People will be more likely to play if they believe they control their destiny. The activities should also be obviously related to our work. Most people will not participate if it does not advertise a value-gained for the organization.

There should be smaller loops intended for individual actions nested within larger loops focused on individual progression.

Don't forget the fun

Although more abstract than some of the other elements, ensuring that your gamified system is fun remains as important as the other aspects. In order to fully explore this aspect of the design process, consider how your game would function without any extrinsic rewards. Would you say it was fun? Identify which aspects of the game could continue to motivate players to participate even without rewards.

Kinds of fun:

  1. Sensation
  2. Fantasy (an abstraction of wiki pages as a game, like Egress)
  3. Narrative (the story of a person's progression)
  4. Challenge (obstacles, increasing difficulty)
  5. Fellowship (social framework)
  6. Discovery (explore)
  7. Expression (soap box)
  8. Submission (mindless pastime)

Deploy the appropriate tools

By this point, you've probably identified several of the game elements and other specifics of your gamified system. If you haven’t already, you should explain in detail what your system would look like. What are some of the game elements involved and what will the experience be like for the players? What specific choices would you make in deploying your system? For example, you might discuss whether the gamified system is to be experienced primarily on personal computers, mobile devices, or some other platform. You might also describe what feedback, rewards, and other reinforcements the players could receive. Finally, think about whether you’ve tied your decisions back to the other five steps in the process, especially the business objectives.