Welcome to this week’s Question of Gamification. My name is An Coppens and I’m the show hosts for a Question of Gamification.
And this week’s question is one that on occasion crops up more from our competitors if nothing else. Occasionally, also from clients, but it’s something we do always answer for clients in proposals. And that is: what is involved in our gamification design process? How does it work? What are the components? What are the deliverables? It may be one question split into a few elements. And I want to tackle that from the ideal project perspective in an ideal world where everything runs smoothly, where you have unlimited resources and unlimited timeframes, etc.
Because the reality of any given project may be different. And I’ll come back to that next week. The official steps in our process are understanding the business specifics. Now in this business specifics phase, we want to know, why do you want to gamify this project or this process? Why do you want to do this now? What else have you tried? We want to understand the reason behind it. Then we also want to understand the success measures. How will you know that the project achieves what you wanted to do? How will you know that the project has been considered successful? Does that mean higher numbers recruited? Does that mean
higher numbers in sales? What is it that you want out of it? Are there soft measures? Is that increasing confidence, increasing retention of knowledge, deployment in reality? Whatever the success measures are, we want to unlock those in our business specific phase.
The other exercise we occasionally do, maybe not all of the time is the Moscow exercise and Moscow. It’s a city, but it’s also an acronym. And the M stands for: what must be included in the gamified process? What should the gamify process include? What could it include? And what Won’t it include? So MSCW and the o’s are the bits in between that make it Moscow: what must it have? What should it have? What could it have? And what won’t it have?
That sort of outlines the scope of a project, because not every project will need everything. Sometimes we also need as a measure of how we can get to good enough? How can we get to a project that will deliver but maybe not, you know, a project that has everything, all bells and whistles on it? Often budget may drive this but also constraints of software that we have to work together with. That’s sometimes gamification tools, sometimes it’s actually existing software already in place. It could be existing constraints within a business.
We recently quoted for something where people were hired and needed to be on-boarded very quickly into service and it needed to be done remotely. People had no access to the internet, but they did have access to some standalone computers, and it could be envisaged to have maybe some tablets without Wi Fi access, with the games uploaded on it, so that they could still onboard and learn the processes. There is an example with a lot of constraints to it. So in those cases, the must have, the should have, could have and won’t have is absolutely essential.
The other measures in the business specifics are key performance indicators, the current processes and the current experiences people have, then the as-is process and the to-experience. Because if you want it to be vastly different, we want to map that out. It comes from good process mapping and process analysis.
Knowledge, I learned in my consulting days, are sort of to blame for this type of work. But we do want to understand, how does it currently work? Because if we’re going to make changes, are we making changes that are so far removed up, we are potentially hitting rejection, or are there maybe processes that could be improved, and we should just go with the process. And in those cases, we also need to buy-in, of the users engaging with those processes.
Finally, in the business specifics phase, we also want to understand the meaningful touch points. Now we’ll come back to meaningful touch points in the next phase for you in our user research, because what we consider meaningful, like, for example, in the recruitment process, how the invite for an interview sent out is a meaningful touchpoint and can give a potential wow-factor to the candidate where they say that organization really wowed me with how they invited me. They, you know, were super efficient, the whole process was smooth.
This sort of sums up everything that we do on when we’re looking at business specifics. This then translates into a business specifics document and project scoping documents. In terms of deliverables, what the client gets is usually a word based or PowerPoint based description of this is what’s included, that’s what’s excluded. These are the measurements. This is the process as we understand it.
For their review, we might iterate that document once or twice, if we missed out on parts. And then we agree well, that’s the way forward.
So that’s in the ideal process. Often this phase runs concurrently with the next phase, which is user research. So user research is the phase where we delve deeper into the users, like why do they use the process that we’re gamifying? What is it that they use it for? What motivates them? What de-motivates them? We want to have both sides of the motivational coin.
How do they perceive the current process?
What is in it for them? What should be measured according to them?
What do they like? What do they dislike?
And we often at that point, run design thinking workshops with the end users. This allows them to co-create what the new process and a new experience should look like and feel like.
From our perspective, in user research, we come out with a persona or a user profile. And that persona then becomes the basis for what we design and who we design for. And we often at this point, ask, do you want to be involved in a pilot test? Would you be available for prototyping, testing? Quite frankly, once you get people excited about what we’re aiming to do and explain the rationale. It’s rare that you then have people say, you know, what, not for me, just show me the end result. In a lot of cases, people, once they have given a little bit of input, they also have a sense of, I own a piece of this.
So they have a sense of all Yeah, I like it would like to see what this turns into, what this becomes etc. In a funny way, the buy-in process starts as early as this. And for me, that comes from my change management days in large consulting companies, the earlier you can get people involved, the higher the likelihood that they’ll accept the end result. But also that they feel a sense of ownership of the product, the process because they helped to co-create it. So I think in this day, and age, co-creation is big for corporate.
Why not do it for a gamified process, or a game that you want to roll out towards your employees and towards your users. Your customers, your potential customer. Customer focus panels could be very useful for this. The tools, we use are surveys, design thinking workshops, and focus groups. And then the end deliverable, as I said, is typically a persona, a profile, and then an ideal process in the view of the users.
Then, the next phase is our gamification design phase. And that really feeds off the previous two. If anything, the first two are non-negotiable for us, in order to hit the target audience. Because if we’re doing game design blindly, without those previous two phases, then any guarantee of a level of success is a lot harder, guaranteeing the level of engagement and getting it right the first time is also a lot harder. If we have to work blindly, we have done it once or twice, it has been hard. And we’ve had to iterate more at gamification design and production level, which is also a much more costly way of doing it.
Whereas if you do include the previous two phases, it’s actually more cost effective. And it’s actually typically also less iterative, in the sense of the design. So what do we do in the gamification design phase?
We choose the storyline or the theme of the design, whether that’s an in house theme around somebody or a ritual that’s effective in the organization. Or a completely made up one, it can be either. We choose a story arc because we know gamification, and good stories engage more, and people retain more information that way.
Then we map the journey that builds on the map from the first two phases, we add in the win conditions, we add in the game elements. And then we prototype. Our first prototype is always paper based or PowerPoint based in a lot of cases and will become a high-level concept, then a storyboard and the description of the flow.
I suppose, from a deliverable perspective, the three deliverables are a high-level concept, which is the first thing. That’s the first thing that goes to the client that we get feedback on. If we have approval and agreement on that, then we go into storyboard mode, where we go to that next level of granularity and detail.
And then we go into a detailed gamification design document, where we look at, you know, this is what x behavior gets, that’s the reward, they get. That’s the points they get, that’s the outcomes they get, the consequences and the feedback loops that need to be built.
Really, that becomes a very large Excel sheet most of the time, where, the developers can see, right in this piece, I need to make sure we have points for actions, the narrative, that’s the trigger for that’s the message they get on failed and that’s the message again on success,, it really does become a very detailed document.
What’s then also included in the user design, or the gamification design phase is a user test, to make sure that a user can understand it. Because in design, what sometimes happens is that, as a game designer and a team working on the game, you can see quite a mile off, or Yeah, this is how it should work. But you also, in some ways, become blind to the problems that it may cause for the end user. So something that’s obvious to us, because we work on the tools and we work on the game may be baffling to the end user.
You need to observe them looking at the screen as well, I really don’t know what to do here. So there are always some things like once you have a totally fresh pair of eyes looking at it, they say, no, that’s not the way it works. Or they figure out ways of using your tools that you never thought of. also account for that. user testers are absolutely essential to the process. And then we iterate the design until it is a fully working and a good enough version in order to launch.
Yes, you may still be doing tweaks in the background. We typically have issues logs where you basically define things based on high priority because it’s a showstopper, it will affect gameplay and navigation. Then medium level items, they are serious, but not showstoppers, and then the low level items are things that I would see because I know about them. Or let’s say somebody with a trained eye will see. We had one recently on a project where an emblem for an officer was wrong. And whilst that’s not a high priority, it will impact some of the players in the know. We obviously want to change that and get that right.
The development phase we work in sprint’s so that means that we usually breakdown the project in sprint format session. A number of objectives for each sprint, so that the developers are clear. Okay, this is what we need to achieve this week. We review at least once the end of the week.
How far did we come? What worked, what doesn’t work? And you know, this process is repeated. Then we test, we bug fix.
The issues log becomes from small to usually a few hundreds of lines long. And then we keep working towards up until go live, until finished. And yes, it’s iterative in its nature, because it is an agile process.
At the end of the development phase, you want to see a working model coming to life, whether that’s in board game situation, an actual physical board game that you receive, or in digital solution, obviously, the playable version of whatever process that we needed to gamify.
And then we typically have a support phase. Not all gamification agencies would do that. We include support and support means we analyze the behavior of the users, we look for feedback of the users and see if what we designed works?
Are they engaging with it as intended? If not, then what, what should we change?
I always advise the first six weeks, eight weeks don’t change too much, especially not in the first two. First two weeks, you probably get the most complaints and unless they are serious in nature, not it’s actually stopping people from performing the work and completing parts, we would hold off because there isn’t getting used to phase.
Just think of it.
If any of your social media platforms, changes buttons or adds new things, there is a bit of a getting used to involved. So that has to be covered.
People have to get used to it. But if it’s not a getting used to issue, then obviously it’s important to listen, and then look for Okay, is this the way it should be?
When we do analyze behavior and interactions with the actual systems, there is a monthly feedback forum and monthly reports. And then we tweak based on that data or design. If they’re big tweaks they’re are obviously additional costs, if they’re small tweaks, then often that could be just in the support fees.
So those are the five steps in our design process. So first one was business specific. Second one was user research. Third one gamification design. Fourth one, development and fifth one, support.
So I hope that that answers some of the questions, it gives you an insight in how we work, it mentions the deliverables that we’re after. I can’t be more transparent about our processes. And they will always be different for each organization. Because of our bespoke work we cannot share other people’s deliverables for the very reason that they typically also include very, I suppose secretive information about how they work around there. That’s why there are non disclose clauses in place.
Saying that there are things that we show in our design tool kit course where we work with fictitious little dummy projects. If you’re interested in delving deeper that is something we are working out putting together.
I hope you enjoyed this session of a Question of Gamification, a very theoretical one, and next week, I’ll delve deeper into the realities of a real project. Whilst we have a fantastic process and I think that’s also what wins us awards. In some sense. We also have realities of process, I suppose shortcuts to deal with when it’s a real project.
Thank you for listening. Do give us a good review or a like when you enjoyed the show, and keep your questions coming to us. We love answering them and I hope to hear from you in the next few weeks.
The post Podcast 14: What is involved in the gamification design process? appeared first on Gamification Nation.