At the beginning and working on our first projects, we also believed that building highly participatory engagement architectures based on game techniques would certainly work. And, through different methods, we tried to conceptualize and design the best game-based solution for a particular challenge.
Eventually we came to realize that reality was different, and that until a player decides to engage in our solution, it was little more than a hypothesis, even though created with our best intentions and experience.
It was at that point when I thought it would be interesting to adopt the lean method for Gamification Model Canvas to build gamification solutions. In the world of game design using lean is more difficult, since the production of a video game is quite complex – you almost always have just one chance to create a single concept which you risk all the investment.
But in the case of gamification, especially in the field of interaction design in UX, we have the opportunity to validate our hypothesis largely without large investments, rather make small changes to the original model aligned with the other hypotheses on the canvas.
Therefore, when each section of the canvas tries to resolve the various contexts and design elements, and we try to come up with the best ideas based on game, each and every one of them are just hypotheses until our player decides to play or not, or until our revenues do not work out as we had hoped.
With the lean method in these types of projects, we should also think about the current state of the trend itself. In principle, gamification is an interesting and viable option to solve engagement problems in our products or processes, but time will tell if it is effective in any environment and for any company or for any product or process.
Hence, the format recommended by the canvas is a continual process of learning and improvement, rather than gambling all our effort and investment to create the best highly participatory solution on project launch.
All hypotheses on the canvas have two fundamental characteristics. The first is that if it is not the first hypothesis on the canvas it should be linked or based on a previous one. If not, we must come up with another idea in the previous section of the canvas.
The second characteristic is that all hypotheses have a state that can and should change over time:
- Defined hypothesis. In the early stages of a project and during the creation of the concept, every idea automatically becomes a defined hypothesis. This means that they are assumptions that may turn out to be false, but initially must be supported by information or previous experience of the designers and project managers.
- Hypothesis in progress. When creating the concept of the project the best ideas or defined hypotheses must be selected, considering how they integrate into the overall model. From there, and with the closed model, all these hypotheses are in progress and pending validation, whereby some members of the project will be responsible for reviewing its status during deployment and continually improving it throughout the learning process.
- Validated hypothesis. During project deployment and as players come up with a solution, there will be decisions made in the conceptualization and design of the project that work. These hypotheses are automatically proved and validated by our player. For example, if we decide to adopt a narrative as part of our solution and the selected topic connects and engages the players, then that narrative hypothesis will be validated.
- Invalid hypothesis. The opposite can also occur. Decisions that in principle were good, original and fitted in with the rest of the model, may not work after deployment. These hypotheses are invalidated, i.e. they did not work in that case. Invalid hypotheses offer as much to a project as validated ones, as they bring us a step closer to achieving a highly participative solution in the next iteration.
This process of validating or invalidating hypotheses is known as iterating over the model, and our goal should be to validate or invalidate hypotheses in the shortest time possible. Only then will we find a highly participatory solution for our players without having to rely on luck as to whether our project will work or not.