This is a new concept that will drive new features meant to achieve goal oriented collaboration & recognition features within Tiki. This will take us much further than the current Score feature.
Badges
Users are able to receive badges for achieving various goals within Tiki.
Examples of badges:
- Master wiki contributor badge
- Super commenter badge
- You have made your first contribution badge
- Highly Active in March 2013 badge.
You can only get a particular badge once. That is not to say that a user can't get many similar badges. For example, if he is "Master Forum Contributor for months Mar, Apr and May". he received 3 badges, but he has also received "3 Master Forum Contributor" badges.
Badges must be configurable
The names of badges will differ from one organization to another, and they map to goals. When someone achieves a goal, they get a badge.
Badges can have levels
Technically once a user gains a badge they keep it forever, but for display purposes, we might have to limit badges if they have too many of the same type.
For example, if I get a Master wiki contributor badge, this shows instead of a "You have made a first wiki edit" badge or Bronze wiki contributor badge (even though I have earned these before).
Goals
Examples of goals:
- Post 10 forum posts
- Write 1 article
- Edit 20 wiki pages and write 3 articles
Configurable and map to actions
Just like how custom activity streams are configurable, goals must be configurable in a custom way. For example, a goal could be "post 5 events", where "events are tracker items in tracker ID 5".
In fact, goals could be based on activities, right?
Limited in time
It must be able to configure "post 5 events before x date" (or more specifically I suppose, between date x and date y).
One might consider also to be able to define a goal as such "post 5 events by 60 days", and then the goal can be left dormant, and then activated at a certain time, then individuals and groups can aim towards that goal within that time frame.
Displaying of goals
There needs to be an easy way to retrieve goals for display in various contexts. A module can be created as a proof of concept for this. Probably a GOALS wikiplugin might be useful. For example, a user profile should show the user himself what goals (well, actually badges) he is currently working towards.
There should be a display of how many percent complete. Where the goal contains compound objects, for example: "Edit 20 wiki pages and write 3 articles", there needs to be a way to determine how much one article is worth to wiki pages. Perhaps they can all be considered the same but that is not so good.
Compound goals
There are 2 possible designs. One is to allow compound goals and map badge to goal one-to-one. The other option is to keep goals all on particular object type definition (like activity streams), but allow badges to be mapped to multiple goals (e.g. you need to achieve goal 1 and 4 to get a certain badge). From a display perspective, you can show percentage completion separately for the goals that are towards a certain badge.
Groups and Individuals
Groups, just as users should also have goals. Whenever a user that is in a group conducts actions, they accrue towards group goals the same way that it accrues towards their individual goals.
If a user leaves the group, what he has earned for the group while he was a member still counts towards the group goals. But whatever he earns after that does not count (obviously).
In this design, it does not matter if only one person in the group does all the work and the rest contribute nothing. This is fine for now.
Rewards
Rewards are what you get when you achieve a certain badge. These can be in the form of Tiki Credits which can then be exchanged for things, or they can be manual rewards that are outside the scope of Tiki.
Since rewards are pretty flexible (and need to be displayed flexibly) perhaps they could be stored in a tracker instead of in a database.
Triggering rewards
The question then is how to trigger a reward? What happens when a user achieves a badge? There needs to me a mechanism to award the badge and trigger the assigning of pre-defined rewards.
User Stories
Use Case Example 1:
Kim is the Knowledge Management Lead of a company that is using the Tiki as its Knowledge Repository. She wants to encourage staff to share knowledge gained from their respective projects and to benchmark the accumulation of knowledge over time.
She goes to the Rewards and Recognition system, sets up “Metrics” as follows for each department:
- Numbers of projects created
- Numbers of documents shared
- Numbers of Likes received (for documents that have been shared)
(Creation of projects and sharing of documents are custom activities that have already been previously defined in the system. It will be nice if the administrator can specify which of these activities can be used as metrics by users of the Rewards and Recognition system, and to provide human friendly names/descriptions for them)
Although Kim knows the key performance indicators specified above, she does not really know what the “Goals” should be. In order to get an idea, she clicks on “Historical Metrics” which allows her to see the top users and top groups (sum of all its members contributions, or as an alternate sorting, average or mode of all its members contributions) and how much they have contributed for each of these metrics over different time periods. She sees that the top 5 groups (*we will need to be able to restrict groups to Admin specified groups so as not to show meaningless groups such as Registered or Admins, but rather groups that represent departments etc...) created about 4 projects, 30 documents and received about 20 likes. So she sets Goals as follows:
Goal A:
- 3 projects created
- 20 documents shared
- 20 documents liked
- goal must be reached within 60 days period
- this is a group goal
Goal B:
- 5 projects created
- 40 documents shared
- 40 documents liked
- goal must be reached within 60 days period
- this is a group goal
Goal C:
- 1 project created
- 3 documents shared
- goal must be reached within 60 days period
- this is an individual goal
Goal D:
- Deliver a WITS presentation (unlike the other goals, this goal is an offline task, and so the system is used to track whether it has been done or not but is otherwise not trackable by the system)
She then sets up “Badges” that are to be given when these goals are achieved:
Goal A: The WITS Team Badge
Goal B: WITS Extraordinaire Team Badge (supercedes The WITS Team Badge)
Goal C: WITS Contributor Badge
Goal D: Successful WITS Presentation Badge
She chooses an icon for each of the badges and can upload her own image as well. Also, she specifies the FROM and TO dates (or no TO date, i.e. until disabled) within which each of these badges can be earned. She Once Kim is sure of all the details, she clicks PUBLISH for each of the badges. An event is triggered creating a new activity (that is shown on the activity stream) announcing the new badge. There could also be a prominent place on the site where New Badges are announced (perhaps a special wikiplugin for this purpose).
Now, Kim would like the badge attainees to be able to get some rewards. She uses the system to assign rewards as follows:
Goals A: The reward is an offline prize, so she describes the reward in the system, and also uses the system to keep track if the reward has been given out or not for each successful attainee.
Goal B: Kim would like the system to provide an automatic reward in terms of Tiki Credits. The system has previously been configured with a points credit called “WITS points”. She specifies that Goal B is worth 2 WITS credits for each group member, which automatically is added to the user’s system when his group attains this goal.
Goal C: Kim would like the system to provide an automatic reward in terms of Tiki Credits. The system has previously been configured with a points credit called “WITS points”. She specifies that Goal C is worth 10 WITS credits, which automatically is added to the user’s system when he attains this goal.
Goal D: Kim can choose either an automatic reward or a manual offline reward
When a user or group achieves these goals (A, B, C), the following happens:
- An event is triggered creating a new activity (that is shown on the activity stream) announcing this achievement
- The user profile of all members of the achieving group (if it is a group goal) or user will have the badge displayed.
- Kim is notified via the notifications system of this event
When Goal D is complete, Kim manually marks the goal as complete for the individual and the reward i(if automatic) is given.
Kim can at any time see on her Rewards and Recognitions dashboard the progress of each group/users towards these goals over time, and see who has achieved the badges.
It is now time for an employee’s annual performance review. One of the review criteria is WITS participation. The reporting manager of the employee needs to retrieve the employee’s WITS participation from the system. He notes in the employee’s profile that he has received the WITS contributor badge, and also 3 WITS Extraordinaire Team Badges and considers this excellent participation in WITS and therefore eligible for a special WITS bonus.
Use Case Example 2:
Henry is the HR Manager of a company that is using Tiki as its Intranet. He wants to make it possible for individual department and team managers to provide ad-hoc recognitions to the staff. He also wants to make it company culture that managers provide these recognitions regularly.
He goes to the Rewards and Recognition system, sets up the following metrics:
- Number of ad-hoc recognitions given out
- Number of ad-hoc recognitions received
(The giving of ad-hoc recognitions are custom events that have been defined previously in the system).
(Nelson: I was thinking that ad-hoc recognitions can simply be a tracker, but if you have a better idea or if you think that this should be a built-in object type I am open to that too).
He sets up Goals as follows:
For managers, he sets up:
- minimum of 5 ad-hoc recognitions given out EVERY 30 day period
- mandatory task
For everyone, he sets up:
- receive 2 ad-hoc recognitions (over 30 day period)
- receive 5 ad hoc recognitions (over 30 day period)
He setups up Badges to match the goal for employees:
- Double-Whammy (received 2 ad-hoc…)
- A Fiver (received 5 ad-hoc…)
As in Use Case 1, when the Badges are published, this publishing enters the activity stream and are also highlighted on the site.
Now for managers, they don’t get badges for having given out the minimum of 5 ad-hoc recognitions. However, the goal is setup as a “mandatory” task. If a manager does not achieve this within the period specified, a notification is sent out to the manager reminding him to do so. A “nag” screen or bar should appear also on the manager’s screen when he is logged into the Intranet. The HR manager who set this up is also informed so that he can take action (e.g. call the manager).
Now a manager who wants to give recognition for a job well done or any such related thing goes to the profile of his employee that he wants to give recognition to, and clicks on “Give ad-hoc recognition”. He writes a custom message for the recognition. An event is triggered creating a new activity (that is shown on the activity stream) announcing the ad-hoc achievement.
The manager can review all the ad-hoc recognitions he has given in the past.
When employees get a Double-Whammy or Fiver, an event is triggered creating a new activity (that is shown on the activity stream) announcing this achievement
Now it is now time for an employee’s annual performance review. One of the review criteria is ad-hoc recognitions received. By reviewing how many Double-Whammys and Fivers, a manager can decide whether to give a bonus etc…
Use Case Example 3:
Susan is the Sales Manager of a company that is using Tiki as its Sales Portal. She wants to make sure certain district sales representatives do successfully download and read a series of new guidelines she has posted.
She goes to the Rewards and Recognition system, sets up a “Goal” for everyone in the District Sales Representative group.
Goal A:
- Read Article X (she selects the respective article)
- Read Article Y (she selects the respective article)
- Read Article Z (she selects the respective article)
- Goal must be achieved before DD/MM/YY
So this is a compound goal, i.e. to read 3 specific articles.
In addition, she sets the goal to be mandatory. She also sets the date the goal is to be achieved by.
She also has a bunch of training materials that she wants the sales staff to read if they have the time, but these are not mandatory, but she wants to encourage it. So she sets up a different goal:
Goal B:
- Read Course Material A (she selects the respective article)
- Read Course Material B (she selects the respective article)
- No time limitation
Goal C:
- Taken and Passed Quiz
- No time limitation
She sets up a Badge that relates to this goal C and publishes the badge:
- Complete Sales Training
This quiz needs to be marked manually and so completion needs to be verified manually.
But for goal B, even though it’s not a published badge, Susan wants to be able to keep track who has completed the course materials so she can send them a quiz that they can complete (for Goal C) via email. She will need to be informed when individuals complete Goal B.
For the mandatory Goal A, if by the due date any of the individuals in the District Sales Representative group have not completed the goal, they receive a reminder to go and complete it. They should also get a nag screen when they logon to the site to go and complete it. The nag screen could also include "encouraging info", such as "x% of your team has already completed this!" as a way to cause peer pressure.
Interesting Articles
Other Suggestions and Comments
Should badges be obtainable only once?
The thing is this depends on how we define "badge" in the implementation. By saying "you can only get a particular badge once", that is not to say that a user can't get many similar badges. For example, if he is "Master Forum Contributor for months Mar, Apr and May". he received 3 badges, but he has also received "3 Master Forum Contributor" badges.
Having "badges" that can only be obtained once encourages performance. For example, if you are training to be a life guard, you get the silver level swimmer badge once. If you use a fitness tracker then you get the 10 000 steps in a day badge once. The goal of badges is for recognition and then to push you to achieve to the next level. This is why badges need to be configured as levels to encourage performance
However, there are valid situations where users could have multiple "similar" or almost identical badges, for example, in the army you can get a Purple Heart or Medal of Honour more than once. However, think having badges that are "more than once" is "old-school thinking" that does not take advantage of new medium. It dates back to physical medals where there is a limitation on flexibility. Specific achievement badges provide more information about what the person is good at, vs generic badges which are really just rewards with no informational value. Medal of Honour? what exactly does that mean? I want to know what he got the Medal of Honour for.
But having said that, I think there could be possible to aggregate badges, for example if I can get "best sales person of the month" 5 times. From a system perspective, it's 5 badges - "Best sales person Mar 2013, May 2013, Apr 2014, ..." each month is a different badge. But we can also say he received 5 "best sales person of the month" badges.
From a display perspective, in order to avoid too much clutter (too many badges on screen) one way might be to gold star (or other image with “4” inside means that the e’ee was awarded the badge 4 times. This keeps it as one icon for that particular R&R and will allow the display of multiple icons representing different achievements without being overwhelming
In the simpler cases, badges could just be items in a tracker or wiki pages, and users obtaining the badge get a relation to it, allowing for listing and filtering.
It could also be a custom activity being triggered. Rewards will be a bit like behaviors on a payment. They happen once confirmed, what they are does not matter much. We will support a few frequent behaviors, such as attributing credits, but how each site decides to handle how badges work is up to them.
What happened to the old points system (score feature)?
The old points system awarded points to users, and users raised levels as they obtained points. There was one main problem with this system.The system penalized new users as they can never catch up to the old users. It might be possible to "fix" this by expiring points, but then this causes problems of its own, therefore the main rewards and recognitions system should focus on badges vs. points.
Nevertheless, we don't want to totally remove the "points" system. After all, the Air Miles concept is valid for many situations. So, the new Rewards and Recognitions feature should also have the ability to assign basic ongoing point accumulations to activities. These activities can be the same ones that are used in goals. But this is really for "backward compatibility" reasons and also as mentioned, the "Air Miles" concept still is valid, even if suffers from limitations.
At the same time, the points need to be "expirable", similar to Air Miles programs to determine the "star level" of the user. So that it can be set that only points accumulated in the past x days are valid for the "star level". We continue to keep track of what the user has accumulated since forever historically, but calculate a separate number of points that are valid for considering their "star level".
The administrator also needs to be able to set the time upon which accumulated points are converted to rewards. For simplicity, we can assume that they are converted to a form of Tiki Credit. For example, every 3 months, all accumulated points since the last conversion result in a reward of x Tiki Credits of a certain type for each point accumulated.
The score system is likely to stick around forever. It should probably reduce and use the events to attribute points, but given how things usually occur, this is unlikely to happen as no one will spend time on it.
Goals are a form of replacement, but do need a larger commitment.
Doesn't Use Case Example 3 seem more about increasing engagement in general rather than Rewards and Recognitions?
Admittedly, Use Case Example 3 is more about tracking if users are reading certain content (in some cases mandatory reading that is tracked), or engaging with the site. But to me (Nelson), it seem that this requires the same goal setting, tracking of completion, or even "nagging of users", "encouragement to users, e.g. x% of the team has already read this", and "reporting back to the user that created those goals" that overlaps with general Rewards and Recognitions. What do you think? Is it a separate feature, or maybe a related feature that can use the same back-end code but have a different UI?
It is important to be able to report on badge achievements over time against preset targets
Badges need to be tracked and logged for historical data as well as being able to be applied to more than one tracking “stream”.
For example, a company might have certain goals for Q1, Q2, Q3, Q4 as well as an overall target for the year. So after each quarter the badges are logged into the tracking system (with the appropriate quarterly rewards/recognition) in terms of separate as well as cumulative targets.
Once logged and banked, the visible counter gets reset for the next quarter (or other relevant time period), even as the historical information for previous time periods are kept and can be reported on.
This would also be useful for tracking purposes, say, for HR - eg to see if someone is a rising star that then falls off the radar, etc
It is important to have public facing leaderboards as well
In addition to the reporting dashboards already mentioned above for reporting of goal achievement status, there should also be a way to easily create public facing leaderboards to encourage users to "get on their game" and to motivate them to achieve their goals, in a spirit of friendly competition. This perhaps can be achieved through a wiki plugin that can display for certain group members the top achievers or "percentage achieved". The way to specify what is to be shown on each leaderboard needs to be flexible enough to define a range of different filtering criteria of what to show and for which time period, e.g. Region vs region; inter-departmental groups, tracking against goals (department, location, quarterly results, etc).
Is it possible to have goals that build up towards a larger target?
Imagine a a thermometer type concept, where there is a big/complex goal that is of critical importance but will take at least 6 months (or very long, or many teams, etc...) to achieve so it’s broken down into components (smaller tasks) that trigger rewards/recognition along the journey to give a sense of achievement, momentum and encouragement towards the end goal.
So you create an overriding "goal/target", and this target consists of individual goals. Or even better, perhaps some of the individual goals are "dual-purpose" or "multi-purpose", if completed they help progress towards more than one target.
This kind of higher level framework will also counter a tendency for individuals to go to the badges that are more the “low hanging fruit” which, while still valuable, may not necessarily having the best impact on some of the bigger issues.
Do you think this is a separate feature, a phase 2 feature perhaps, or part and parcel of the current system?
Can employees recognize each other (i.e. peer to peer)?
Any ideas on how this would work? More details on what this means TBD...
Can employees recognize their managers?
Any ideas on how this would work? More details on what this means TBD...
Can employees or Manager recognize the C-Suite/Executive?
Any ideas on how this would work? More details on what this means TBD...
Can any employee recognize the full company/collective as a whole?
Any ideas on how this would work? More details on what this means TBD...
;){kind=link}
;){kind=link}
;){kind=link}