To start seeing some common ways that gamification can be introduced into the design of an application, you might first ask ‘Why ‘gamify’ business software at all?’.
Here are three reasons why you could consider using features and patterns normally found in games when designing your next business application.
Motivate users to complete tasks
The most common, and perhaps easiest to implement pattern is the points / rewards system. This pattern is at the core of most game systems, and is a powerful motivation mechanism.
Being cynical, there is a fine line between performance monitoring and a motivational points system. A lot depends on the metrics used, and the way the information is presented and used. It’s easy to implement something that might be resented by users, if not careful. The rule here is that the points system should be for fun – no one needs to be sacked for failing to meet their targets.
A successful system can be as simple as using identifying badges in user profiles which are awarded when certain conditions are met. The typical conditions might include things like sales value, number of records processed, time logged in, or almost anything that can be measured within the application. Badges and achievements should be designed so that they convey a users experience level, as well as provide some amusement value.
Many sales tracking and CRM applications already have built in a system to measure various business-related metrics, making this pattern by far the most commonly used in non-gaming applications. Shifting the focus from ‘top-down’ management imposed metrics to something a little more fun can be a big motivator.
Complex applications often end up with many underutilised features, and introducing new features is often a struggle, as business software users are usually less engaged and less keen to discover new features than gamers.
Many applications try to increase engagement, by displaying a ‘Tips’ window either at startup or through a help system – these are even more underutilised than the features themselves. The main reason for this is that they require the user to switch context between the task that they wanted to complete, and learning about a new, probably unrelated feature.
Role Playing Games (RPG’s) use a quest or mission system that increases engagement and promotes discovery. This pattern can easily be adapted to business software.
Going back to the scenario described in the previous post, for a moment, imagine if the developer had not just pulled out all the advanced features, but simply hidden them behind an optional quest system.
This method can then be used to introduce features in a way that can be easily assimilated by the user, where the user always feels in control and not overwhelmed.
The key elements of a quest system are that:
1) Quests must not interrupt the users current task.
2) Quests must be optional.
3) The quest must encourage the user to complete a task in a new or unfamiliar part of the application.
4) The quest ends in a reward.
For example, on rolling out a new feature, it is initially hidden, and cannot be accessed from the regular user interface. The user then has a 10% random chance to receive a notification, either when using a related feature, or when logging into the application.
This notification must not force the user to change what they are doing right there and then, and therefore should be displayed in an unobtrusive, non-modal area set aside for notifications.
When the user has time, and chooses to investigate the notification, they are given the option to ‘unlock’ the new feature in the menu or navigation system. At the same time, the user is given the details of the quest, that is, the steps required to complete the task, and the details of the reward – e.g. points, an achievement or a profile badge. This information should also describe in detail what the new feature does, and how to use it. If the user chooses to accept the quest, they are taken to the screen, and guided through the task. Each completed quest is tracked by the application, and completing multiple quests will reward the user with points or badges.
Sufficiently advanced applications all seem to end up with some kind of ad hoc messaging application built in, usually either email or chat. The driver behind this is that users want to collaborate. While this is often seen as a useful feature, it’s usually poorly implemented and under utilised.
Game design can come to the rescue here again. Like the other points above, there is no single pattern for how games allow gamers to collaborate, however, most games implement one or more of the following:
- Guilds working toward a common goal – simply replace ‘guild’ with ‘department’ or ‘sales team’
- Online discussion/self-help forums for users
- Friends lists with chat and activity feeds