In the world of gamification one of the key questions is how to motivate people and how to keep them motivated. I recently did an online course on gamification, in which this topic was explored in quite some detail. The course was instructed by Kevin Werbach, an Associate Professor of Legal Studies and Business Ethics at Wharton School, Pennsylvania.
In his lectures, Kevin talked about motivation a lot since it’s such a critical part of gamification. “What motivates people?” “Is it the right kind of motivation?” “Is it enough?” Answers to such questions aren’t straightforward, but it’s fair to assume that gamification is most likely to work if one is motivated to do something (see this great talk by Tom Chatfield in Fig. 1 below).
Gamification examples such as Recyclebank, eBay and SAP all try to find ways to motivate their users. Kevin highlighted two different theoretic approaches to motivation in gamification: behaviourist and cognitive. He also outlined the differences between intrinsic and extrinsic motivation. I’ve learned the following things about these different approaches:
- Behaviourism looks at what people actually do – Behaviourism is highly empirical and it focuses solely on those things that can be tested. In other words, trying to get into a person’s head is off-limits under the behaviourist model. ‘Observation’ and ‘feedback loops’ are two tangible artefacts of the behaviourist approach. A good example of a feedback loop is LinkedIn’s progress bar, which shows users their progress with respect to completion of their LinkedIn profiles (see Fig. 2 below).
- Reinforcement through rewards – In the behaviourist approach, rewards act as a kind of behavioural feedback. Rewards are all about motivating users to play a game or to keeping playing it. Rewards are based on the notion of “The Dopamine System” which neuroscientist Jaap Panksepp describes as the brain’s “seeking” circuitry and which propels us to explore new avenues for rewards in our environment. In the lecture, Kevin outlined some useful reward structures to consider (see Fig. 3 below).
- Pitfalls of the behaviourist approach – The risk with a purely behaviourist approach, as Kevin explained, is that of looking at the person involved as a black box, ignoring the inner thoughts or feelings of that person. We’re, however, dealing with players of flesh and blood and we have to account for players’ feelings and thoughts. For example, the hedonic treadmill is a concrete risk in a sense that once you’ve got people only responding to rewards, you’ll have to keep putting in rewards to keep things interesting.
- Cognitive behavioural approach looks at intrinsic motivation – The cognitive approach to gamification takes into account player motivations which are independent from (tangible) rewards. In contrast with the behaviourist approach, the focus is on a person’s inner thoughts and motivations. One can distinguish between intrinsic and extrinsic rewards in this respect. Intrinsic rewards are those things that people want to do just for the sake of the thing itself. Extrinsic rewards are all about the reward and not about the thing itself. Gamification expert Gabe Zichermann has created a nice mnemonic to capture the key reward schemes, called “SAPS” (see Fig. 4 below). These SAPS address both intrinsic and extrinsic motivators.
- Factors of intrinsic motivation – Whereas I struggled a bit to fully understand the distinction between behaviourist and cognitive theories, the thinking which underpins “intrinsic motivation” really resonated with me. In 2000, Richard Ryan and Edward Deci wrote an influential article on intrinsic and extrinsic motivations in which they outlined a motivational spectrum. This spectrum includes “amotivation” (i.e. no motivation) to “extrinsic motivation” (i.e. external motivators) and “intrinsic motivation” (i.e. doing something just because it’s fun) (see Fig. 5 below). Ryan and Deci have also studied the three common factors of intrinsic motivation: (1) competence (a sense of ability) (2) autonomy (a feeling of control) and (3) relatedness (activities being related to something beyond yourself).
Main learning point: I didn’t find the topic of motivation and rewards in gamification the easiest to understand. The psychological theories which underpin players’ motivations can be quite hard to fully grasp. Also, there’s a motivational spectrum to bear in mind, with most people likely to fluctuate across this spectrum. The difference between intrinsic and extrinsic motivators resonated with me the most. This distinction urges people involved in gamification to think constantly about the appropriate motivators and rewards.
Fig. 1 – Tom Chatfield: 7 ways games reward the brain (at Ted Global 2010, July 2010)
Fig. 2 – Screenshot of LinkedIn progress bar (taken from: http://www.socialmediaexaminer.com/26-elements-of-a-gamification-marketing-strategy/)
Fig. 3 – Some gamification reward structures to consider (from Kevin Werbach’s Gamification Course, January – April ’14)
Questions to consider when creating and offering rewards:
- Which behaviours can/should be rewarded? Provide people with meaningful choices and reward accordingly
- Tangible / Intangible rewards – Offering money is an obvious example of tangible rewards. A digital badge is a good example of an intangible reward.
- Expected / Unexpected rewards – Does the player know that he/she will receive a reward or does the reward come as a surprise?
- What are the rewards contingent on? Rewards can be automatic (‘task non-contingent’), which means that players will get a reward regardless. In contrast, rewards can be related to actually doing a task: ‘engagement contingent’ (starting the task), ‘completion contingent’ (finishing the task) and ‘performance contingent’ (related to how well a player performs the task).
- When is the reward offered? There are four basic ways to schedule rewards: (1) continuous rewards – these rewards are somewhat automatic (2) fixed ratio rewards – a player will receive a reward at a set number of times (3) fixed interval rewards – these rewards are based on time (and not on what a player does) and (4) variable rewards – these rewards aren’t based on a fixed schedule.
A good example is Samsung Nation’s Quest Badge, which is intangible, expected and completion contingent:
Fig. 4 – Gabe Zichermann’s SAPS (adapted from: http://www.gamification.co/2010/10/18/cash-is-for-saps/)
- Status – Example: being on top of the leaderboard
- Access – Example: access to new content (as a reward)
- Power – Example: the ability to moderate a game (once you’ve earned a certain amount of points)
- Stuff – Example: receiving a tangible reward
Fig. 5 – The Motivational Spectrum (taken from: http://valerielyl.wordpress.com/2012/11/19/the-motivational-spectrum/)
Related links for further learning:
I recently started doing an online course on “Gamification” which was lectured by Kevin Werbach, an Associate Professor of Legal Studies and Business Ethics at Wharton School, Pennsylvania. In his first couple of lectures, Kevin concentrated on the meaning of gamification and its value.
Let’s start with a good definition of what gamification is: “The use of game elements and game design techniques in non-game contexts.” Good examples are Nike+, which aims to make the experience of running more game like, and the Pain Squad app which makes it easier for young cancer patients to complete daily reports on their pain levels (see Fig. 1 below).
Kevin highlighted the following things with respect to the meaning and value of gamification, :
- It isn’t just about game components – Gamification is more than just putting together some game elements (e.g. badges or leaderboards). It’s important to think like a game designer (without having to become one) and to treat gamification as a way of thinking, as an experience.
- Game thinking also applies to non-game contexts – With gamification the spectrum is broader than just the goal of being successful in a game. Kevin mentioned a number of gamification examples with objectives outside of the actual game; think areas such business, social impact and education. I’ve listed some sample categories in Fig. 2 below.
- Gamification isn’t about just making everything a game – Kevin was quick to point out that gamification isn;t just about turning everything into a game, as you’re still in the real world. Nor is gamification about a collection of ‘PBLs’ (i.e. points, badges and leaderboards).
- Gamification is a way of thinking – Gamification brings concepts together from a range of disciplines. Concepts from fields such as psychology, marketing, economics and management all feed into gamification. It’s therefore much more than just playing a game or combining some game (like) components. I found the boundaries that Bernard Suits puts around games and gamification in his book “The Grasshopper“ to be very helpful (see Fig. 3 below).
Main learning point: I’ve learned that gamification is more than just sticking some game components together. Neither is gamification a case of just treating everything like a game. I’m looking to learn more about how one can apply gamification as a way of thinking to help resolve real-world problems and opportunities.
Fig. 1 – Promotion video of SickKids’ ‘Pain Squad’ app by Cundari Group
Fig. 2 – Sample categories where gamification can add value by Kevin Werbach
External (to the organisation)
- Customer engagement
- Human Resource
- Productivity enhancement
- Health and wellness
- Personal finance
Fig. 3 – How is the concept of a ‘game’ bounded? (taken from Bernard Suits in “The Grasshopper”)
- Having a pre-lusory goal – A game needs to have an objective
- Having constitutive goals – A set of rules and limitations that make up a game
- Encouraging a lusory attitude – The game player voluntarily follows the rules of a game
Related links for further learning:
One of the last lectures of my online Human-Computer Interaction (‘HCI’) course by Scott Klemmer was all about “mental models” and their role within HCI. The proposition that people rely on mental models was first introduced by Scottish psychologist Kenneth Craik who wrote that the mind constructs “small-scale models” of reality that it uses to reason, to anticipate events and to underlie explanation.
In a HCI context, a “mental model” is a set of beliefs of a how a system works. User act with systems based on these beliefs and develop a mental model based on these interactions. This definition came from Don Norman in his book “The Design of Everyday Things”, which was published in 1988 (see Fig. 1 below). Fig. 1 illustrates the tension between a the mental model of a designer and the mental model of a user.
In the lecture, Scott talked about keys to good design in this regard: (1) understanding what makes a design learnable and (2) understanding what leads to errors. Slow performance, errors and user frustration are common signs of a mental model ‘mismatch’. This topic seems to tie in neatly with that of direct manipulation and I noted the followed things in relation to both subjects:
- What’s an error? – Roughly speaking there are two types of common errors: slips and mistakes. A slip tends to occur in those cases where the user does have the right mental model but accidentally does the wrong thing. For example, putting a finger on the wrong key can lead to errors. Designers can prevent these slips through improving ergonomics. With a mistake, the user has the wrong mental model. Designers can prevent these mistakes from occurring by providing better feedback and by clearly outlining the options available to the user.
- How to prevent errors? – In the lecture Scott talked about design consistency as a way to prevent the aforementioned human errors from occurring. A good example is the seat user interface (‘UI’) which is used in most Mercedes Benz models (see Fig. 3 below). This UI is a good example of providing the user with a clear mapping of actions and results; the interface makes it apparent what happens when you press certain buttons. Similarly, direct manipulation helps in clarifying how each object works and how to control it. In other words, a good interface discloses how to use it. Another great example is Final Scratch. Final Scratch provides DJ software, which its users perceive as being very close to the ‘real thing’ (i.e. turntables) with intuitive controls and the right amount of ‘sensory richness’ (see Fig. 4 below).
Main learning point: We all know how much errors – whether they are human or system errors – can create frustration. Thinking about mental models helps in preventing such errors. Looking at a designer’s mental model and that of a user can help in identifying ‘gaps’ and the best ways to reduce those gaps. Following my understanding of “direct manipulation” and “mental models”, I have started incorporating multiple views (e.g. designer vs user) and have conducted user testing session to explore some of the ‘gulfs’ that can exist between views.
Fig. 1 – The problem of ensuring that a designers mental model corresponds to a users mental model (adapted from: Don Norman – The Design of Everyday Things, p. 15 and taken from: http://www.interaction-design.org/encyclopedia/mental_models_glossary.html)
Fig. 2 – James Reason’s “Swiss Cheese model of human error causation” (taken from: http://tc.gc.ca/eng/civilaviation/standards/sms-faq-general-q8-629.htm)
Fig. 3 – Mercedes-Benz S500 Seat Controller
Fig. 4 – Final Scratch DJ Software
Related links for further learning:
The ‘iBeacon’ is Apple’s recent product which uses location-sensing technology to help extend location services within the iOS operating system. For example, with the help of an iBeacon an iOS device or other hardware can alert its (location based) apps when a user leaves or enters a certain location. Also, when a user is getting closer to a specific location (e.g. a store checkout) a user’s app can work out the proximity to that location.
Currently, a large number of devices still use latitude and longitude to work out a location. The iBeacon uses bluetooth signals instead. More specifically, the iBeacon works on Bluetooth Low Energy which means that the power used is considerably less compared to ‘traditional’ bluetooth signals.
The question arises how this location-based technology can best be used. Let’s look at some potential use cases:
- Enhancing your shopping experience – Companies like Sonic Notify and Estimote specialise in so-called “proximity based marketing”; people will get targeted alerts on their smartphones whenever they enter a certain area (see Fig. 1 below). Another great example in this respect is shopBeacon which can welcome a shopper when he/she enters a store and show the shopper location-specific deals, discounts, recommendations, and rewards, without the shopper having to remember to open the app. Equally, if a shopper likes a specific product in the app, shopBeacon can remind him/her when she enters the store that sells it (see Fig. 2 below).
- Linking digital content to the physical world – You won’t need an iBeacon every meter or so to figure out where a person is located. As explained in this great article in Wired, you can have a number of beacons quietly triangulating your position at distances anywhere from 100 feet down to just a few inches. This technology opens the door for a range of new digital experiences based on so-called “microlocation”. A good example is the “Bar Kick” pub in London where certain magazines will become available automatically and for free via Apple’s “Newsstand” as long as you’re in range of the pub’s iBeacon.
- Seamlessly connecting all your devices – Perhaps this use case is one that it’s a bit further down the line, but one can envisage iBeacons facilitating a smooth linking of all your gadgets and accounts. Gone will be the days of having to use lots of different logins, passwords or WiFi credentials. Instead, iBeacons will automatically pick your device and link to your account.
Main learning point: Personally, I find the iBeacon one of the most interesting and promising innovations that I’ve seen in a while. It might take some time but I do believe that these beacons will transform they way we do everyday things such as shopping, using public transport or connecting with other devices. I can foresee a range of new applications popping up, all making content and interactions a lot more targeted, contextual and personalised.
Fig. 1 – Promo video of Estimote Bluetooth Smart Beacon by Beacon
Fig. 2 – Promo video of “shopBeacon” by Shopkick
Fig. 3 – “iBeacon Demystified” – CapTech Webinar on 3rd March ’14 by CapTech
Related links for further learning:
The book “Collaboration Explained” by Jean Tabaka was published in 2006 and had been on my ‘books to read’ list for quite a while before I finally got my hands on it. Jean Tabaka specialises in Agile software development and has worked closely with a host of businesses and teams to implement Agile methodologies. In “Collaboration Explained” she describes how to best run projects in an iterative and collaborative fashion.
The key focus of the book is on working with self-organised teams, empowering teams to make their own decisions. Tabaka’s core point is that this ’empowerment approach’ requires a different leadership style; a ‘servant’ leader whose role is to facilitate instead of the ‘command-and-control’ leader who leads the troupes and tells them what to do.
The book explains in great detail some of the ways in which one can help create self-organised teams and foster a culture of collaboration:
- What makes a collaborative leader? – In “Collaboration Explained”, Tabaka explains the core aspects of facilitative leadership: “as a profession, facilitators work as guardians for teams. They manage a collaborative process that guides decision-making, consensus building, and productive team outputs (…). A facilitator owns the process, not the decisions for which the process paves the way.”
- Collaborative teams that are self-organising – Naturally, in order to create a collaborative culture one needs a team that feels confident and empowered to work in a collaborative and self-organised way. The book contains references to Agile authors such as Pete McBreen and Jim Highsmith who introduced a shift in thinking about the role of project managers; instead of prescribing tasks for the team to execute, their role should be much more focused on defining a ‘mission’ and on building relationships within the team.
- Defining project collaboration events – A lot of the chapters in “Collaboration Explained” are dedicated to the artefacts of collaborative project and product management. Good examples are planning meetings and Scrum sprint planning meetings (see Fig. 1 and Fig. 2 below). At times I felt that a large part of the book was spent on how to best prepare and manage meetings, but I can imagine that many readers will find these practical pointers helpful.
Main learning point: “Collaboration Explained” wasn’t exactly the book that I hoped it would be. I hoped for more practical advice on empowering teams, giving the team the confidence to make decisions and on how to best create one project or product team. Too often I see occasions where managers are prescribing tasks for others to execute on whereas I really believe in shared responsibility, feeling accountable for the same mission in equal measure. I was therefore hoping for more suggestions on how to nurture such a mindset on an ongoing basis.
However, “Collaboration Explained” is great for readers who are fairly new to Agile development or who wish to learn more about effective meetings. On those aspects, the book provides a great deal of detail on concrete Agile artefacts and on how to get the most out of team meetings.
Fig. 1 – Planning Meeting Cautions (from “Collaboration Explained” by Jean Tabaka, p. 55)
- Avoid extended status sharing
- Make sure information sharing is specific to the purpose of the planning
- Plan, don’t build
- Don’t finish a plan without defining actions to support it
Fig. 2 – An example overview of a Scrum Sprint Planning Meeting (from “Collaboration Explained” by Jean Tabaka, p. 57)
- Who is the product owner for this Sprint’s Product Backlog?
- Who is in the project team for this Sprint?
- What other stakeholders maintain “skin in the game” of this Sprint?
- What is the full set of items in the Product Backlog to be considered for this Sprint?
- What is the length of this Sprint?
- What concerns does the team have about the Product Backlog and the length of the Sprint?
- Based on these concerns, what changes must be made to the Product Backlog?
- What is the final priority of the items in the Product Backlog?
- What priority items from the Product Backlog are being placed in the Sprint Backlog?
- Given the items placed in the Sprint Backlog, what are all the risks to be managed during the Sprint?
- How shall the project team report its progress and risk management during the Sprint to the Stakeholders?
Related links for further learning: