Blog

Podcast 15: Reality in Gamification Project

Welcome to A Question of Gamification, a podcast where gamification expert An Coppens answers your questions.

Welcome to a question of gamification. My name is An Coppens. I’m the show host and chief Game Changer at Gamification Nation. And this week’s question is a build on on last week’s question of what are the processes that we use? What are the deliverables that we have? And this week is what about project reality? Because last week, we went through the five step phases, so business specific user research, gamification, design, development, and support. And this week, I want to delve deeper into what is the reality like in a gamification project.

Now, we just finished a major project took us nine months to get where we are today. And I have to say, I’d love to say it was a smooth and easy process and everything worked according to plan. But hey, that’s not reality. In fact, we had from day one, a delay of a number of months, actually, in terms of contract negotiation and setup negotiations. So that’s what that was one. So that’s something that in a lot of cases, and a lot of projects is forgotten that, yes, procurement typically, has I say about everything, commercial terms, we may have a say about too, because in gamification and game design, what we aim to do and how we work is we aim to retain the IP so that it’s a win win for everyone so that we’re not because of one game design that we used for one client, that we’re tied down to never ever be able to use that, again. It would be crazy for us to sign away. Let’s say the intellectual property for a crossword or an unlocking of content game mechanic, and then to never be able to use that again with future clients.

So obviously, we’re kind of tied to what we want to create, when we are looking at game design and intellectual property, obviously, anything like branding, graphics narrative that we take from the client or that the client already has, even content that the client already has, obviously, that is retained by the client. We just put that into different shapes and formats.

So there is always negotiable there. So that was one thing. So the reality of a project may mean that you spend a lot longer in the procurement and negotiation of terms phase. Then we do before we start to the fact that we had, like, originally, we had nine months, and then that got shorted down to five months. That meant some of our design processes had to really work concurrently and in very rapid succession.

I remember doing the business scoping phase in two weeks, at the same time, we launched the user research phase, which had already been started, but because nothing had been signed off, we didn’t have access to the clients people. So yeah, there is a lot of factors in there. So did it compromised the level and depth of research? Absolutely. And, you know, that’s reality. You know, I’d love to say for every project, we do user research with 10% of the target audience, or idealistically, that’s fantastic. In reality, we may only get a fraction of that because of time, because of budget, because of due date.

I come from the broadcast sector and in broadcast sector, you often have a go live date where already promotion has started for a program or a movie or a production to go live on a certain date, even a channel at times. And you know, everything else has to backward fit into that timeline. And that’s not very dissimilar in a lot of our game design processes and project. Often the client has a very definite time. So I recall one of the board games we designed, there was a definite conference date. So we had to work backwards from there and say, okay, which printer can still deliver on what time? How far can we push the deadline before it has to go to print? And how quick can we work then to make sure that we deliver, so it’s fine. And it’s a great achievement when we do deliver in those very sharp deadline situations, but sustainably over the long run, we can’t do that for every single project. Plus we’d burnout our people, the client may be compromised in quality as well.

So because, for example for the board game, although it won us awards, the first version of the game still needed to be tweaked. And I think we had, if I recall correctly, we had two more or three more iterations before the the final box that the client is now happy with. And they are still building extensions to the existing pack, which is not unusual for board games, for example. And the same with most of our designs, they go live and then new snags are spotted or new feedback comes back and we may iterate we may add on or we may take away parts. So the reality of you know, all our five processes running smoothly and consecutively. Reality is different. So the other side of reality is that certain things come up.

I’ve had in the middle of user research, the the survey server go down. I’ve had, in the middle of our graphics experience the graphic designer going missing in action. I have to say, we have the graphics covered with in-house graphics now. So unless something seriously happens to our guys, at least we have coverage there. But it doesn’t always be the case. With developers, we have had developers saying they can do stuff and then finding out that they can’t. The same with platforms. We’ve worked with platforms who sold us “Oh Yeah, we have all these bells and whistles. And then we wanted to use the bells and whistles. They weren’t actually ready yet, or they weren’t actually there at all. They were just oh no, no, it doesn’t work like that it should work like this, where we had to adapt our designs.

So in any given realistic projects. And in any given real experience, there will be things that don’t run so smoothly. The process whilst we still actually stick to the five key headlines of business specifics, user research, gamification design, development and support, what they still happen and the deliverables attached to them it typically still happen.

The timeframes could vary. The level of access we get to do user research may vary. The level of time we have available to actually do the whole thing may drive, how quick things are done, and how low our good enough bar has to be set. Because, you know, I’m a slight perfectionist, and people that work with me will know that ask anybody on the team. You know, there are certain points that I’m not willing to compromise on. There are others that I would say, yeah, this is good enough, it has to be like this to be accepted. And good enough is a variation of Will it be accepted by the client? Is it playable? Is it delivering on what we set out to do to deliver on the business objective? And then the iterations would come for, “Okay, how can we make it from good enough to better ?” And budget will decide some of that. Tools will decide some of that. And then availability of the client is the one components and one of our corporate clients asked me one, one point during the proposal phase, they said, Okay, so how long will this process take? And I said, Well, we can get everything you want to get them done in this space of six months. But that means you are ready to make decisions when we present you with the documentation. She looked at me, and she said, Yeah, add three months.

So realistically, the decision making cycles also play a part. For the nine month project that ended up being a five month reality, we have to fast track some of the items and also go back to the client and say, Well, sorry, we cannot accept any further input for now, because we have to move forward. And you know, we had to set deadlines as to Okay, if there’s no feedback in that we move forward with what we’ve got. Because some of the time, the feedback loop between client and design and development is also where a lot of time is lost. One thing I’m always recommending against is designed by committee or development by committee, because the more people that have to look into something, the more I suppose, variety of inputs you have. What I do recommend in most projects, is to have a core project team that has access to the decision makers who can then decide “Yes, we could work with this or no, there’s there is a bit bit more to do”. And, you know, or this is not acceptable based on our influencers or decision makers.

If you have a decision maker, one of them on the team that can group all the other decision makers ideas together, that’s an ideal situation. Some of the time what we know is that decision makers don’t want to be part of the project team with them.

In those situations, the person and the people on the team need to have access to them in order to confirm, validate, and make sure that you get decisions out of them. So slippage is something to be mindful of. From day one, everything and slippage with that means time slippage, but also budget slippage, and scope creep.

You know, usually when people start to see high level concepts and storyboards, then people get excited. “Oh, could it also do this? or Ah, yeah, maybe we can use it for that too. But then it would need a little.” And that’s where our Moscow scenario is, well, it must have this, it should have that, it could have that. But it won’t have such. Those things are important before you even touch the vision and the storyboard because yes, everything’s possible. But typically, the everything’s possible happens with more budget, more people, more time. And in any given project, delivering on time, on budget and for the project to do what it’s set out to do is more critical than to have a scope that is so vast that you have no idea where it might end up.

So from my perspective, I always think project reality. And you know, the recent project, we had a demonstration of it yesterday. The night before one of the guys pulled an all nighter, the guys in development, pulled several working weekends, bank holidays were forgotten about. I was testing. I had my family testing. You know, my partner is his core, and most of our projects, bless him is he’s fantastic. He does love games, thankfully. And he’s also a very patient man.

So, the reality of a project, how I best best describe it, it’s like you see the duck sliding over to water and below it, there is a whole bunch of people treading water like crazy to stay afloat. Because that is often reality doesn’t have to always be best.

In every given project, there’s always a snag, there is always something that pops up that you said how that could have been better, or this, this should have been this. And you know, when you look back over a project, when you look back at it, and you’re satisfied to say, Wow, we pulled it off. And this recent demonstration was one which was 10 games in the quest for recruitment to showcase employer branding, recruitment and an experience of what a real role would look like for an organization. You know, when I look back and say where we started nine months ago, and where we got to, I’m actually mega proud that we got that far. And that it looked that good, given all of the constraints that we were dealing with, under budget that we were given, because we were still working on a very tight budget to deliver the level of delivery that we made.

So from one perspective, that is something to always consider. So when you’re a client, looking at the reality of the project, what you see in the proposal, yes, it is, what the phases are like and what we strive towards. Also know that your budget, if you can find more, you can get more done. If you have time to start as early as frickin well possible. No incorporate that story, always easy to say. But given off feasible deadlines, three months from start to finish can be done. But it’s tight. Nine months for a big employer branding, recruitment exercise is doable, but take it down to five and it becomes a stretch.

So, you know, be realistic in the possibilities. And the keep on dreaming up projects and looking for budgets, we’d love to help you achieve those visions.

So I hope this gives you an insight into what is reality on a gamified project like. And yeah, love to talk to you more about our experiences. And I hope you’re enjoying the show. And if you do do give us a good rating and share it forward with friends and people who you think may benefit from hearing this. I love speaking to you and I hope to meet you soon in either real life or on social media. So thank you for listening,.

The post Podcast 15: Reality in Gamification Project appeared first on Gamification Nation.

Podcast 15: What it the reality of a gamification project?

Welcome to A Question of Gamification, a podcast where gamification expert An Coppens answers your questions.

Welcome to a question of gamification. My name is An Coppens. I’m the show host and chief Game Changer at Gamification Nation. And this week’s question is a build on last week’s question of what are the processes that we use? What are the deliverables that we have? And this week is what is the reality of a gamification project? Because last week, we went through the five steps in our process phases: business specifics, user research, gamification design, development and support. And this week, I want to delve deeper into what is the reality like in a gamification project.

We just finished a major project which took us nine months to get to where we are today.  I’d love to say it was a smooth and easy process and everything worked according to plan. But hey, that’s not reality! In fact, we had from day one, a delay of a number of months, thanks to lengthy terms and contract negotiations and setup negotiations. That’s something which in a lot of cases, and a lot of projects is forgotten about. Procurement typically has a say about everything. Commercial terms, we may have a say about too. In gamification and game design, what we aim to do and how we work is that we aim to retain the IP which is what makes it a win/win for everyone. That way we’re not limited because of one game design that we used for one client, which would tie us down to never ever be able to use that again. It would be crazy for us to sign away. Let’s say the intellectual property for a crossword or an unlocking of content game mechanic, and then to never be able to use that again with future clients.

When we are looking at game design and intellectual property, obviously, anything like branding, graphics narrative that we take from the client or that the client already has, even content that the client already has,  that is retained by the client. We just put that into different shapes and formats.

Always expect to have negotiations in terms. That is one thing. The reality of a project may mean that you spend a lot longer in the procurement and negotiation of the terms phase.

Originally, we had nine months, and then that got shorted down to five months thanks to the lengthy procurement process. That meant some of our design processes had to really work concurrently and in very rapid succession.

I remember doing the business scoping phase in two weeks, at the same time, we launched the user research phase, which had already been started, but because nothing had been signed off, we didn’t have access to the client’s people. So yeah, there is a lot of factors in there.

Did it compromise the level and depth of research? Absolutely. And, you know, that’s the reality. You know, I’d love to say for every project, we do user research with 10% of the target audience, or idealistically, that’s fantastic. In reality, we may only get a fraction of that because of time, because of the budget, because of the due date.

I come from the broadcast sector and in the broadcast sector, you often have a go-live date where the promotion has already started for a program or a movie or a production to go-live on a certain date, even a channel at times. Everything else has to backwards fit into the timeline. Sometimes that’s not too dissimilar to a lot of our game design processes and project. Often the client has a very definite time.

I recall one of the board games we designed, there was a definite conference date. So we had to work backwards from there and say, okay, which printer can still deliver in what time frame? How far can we push the deadline before it has to go to print? And how quick can we work then to make sure that we deliver, so it’s fine. And it’s a great achievement when we do deliver in those very sharp deadline situations, but sustainably over the long run, we can’t do that for every single project. Plus we’d burnout our people, the client may be compromised in quality as well.

For example for the board game, although it won us awards, the first version of the game still needed to be tweaked. And I think we had, if I recall correctly, we had two more or three more iterations before the the final box that the client is now happy with. And they are still building extensions to the existing pack, which is not unusual for board games, for example. And the same with most of our designs, they go live and then new snags are spotted or new feedback comes back and we may iterate we may add on or we may take away parts. So the reality of all our five processes running smoothly and consecutively… Reality is different.

The other side of reality is that certain things come up.

I’ve had in the middle of user research the survey server go down. I’ve had, in the middle of our graphics experience the graphic designer going missing in action. I have to say, we have the graphics covered with in-house graphics now. So unless something seriously happens to our guys, at least we have coverage there. But it doesn’t always be the case. With developers, we have had developers saying they can do stuff and then finding out that they can’t. The same with platforms. We’ve worked with platforms who sold us “Oh Yeah, we have all these bells and whistles. And then when we wanted to use the bells and whistles. They weren’t actually ready yet, or they weren’t actually there at all. They were just oh no, no, it doesn’t work like that it should work like this, where we had to adapt our designs.

In any given realistic project and in any given real experience, there will be things that don’t run so smoothly. The process whilst we still actually stick to the five key headlines of business specifics, user research, gamification design, development and support, they still happen and the deliverables attached to them typically still happen.

Timeframes could vary. The level of access we get to do user research may vary. The level of time we have available to actually do the whole thing may drive, how quick things are done, and how low our good enough bar has to be set.

I’m a slight perfectionist, and people that work with me will know that, ask anybody on the team. You know, there are certain points that I’m not willing to compromise on. There are others that I would say, yeah, this is good enough, it has to be like this to be accepted. And good enough is a variation of “Will it be accepted by the client? Is it playable? Is it delivering on what we set out to deliver in the business objectives?” And then the iterations would come from, “How can we make it from good enough to better ?” And budget will decide some of that. Tools will decide some of that.

The availability of the client is another component where reality may throw a spanner in the works. One of our corporate clients asked me at one point during the proposal phase, they said, “Okay, so how long will this process take?” And I said, “Well, we can get everything you want to get them done in the space of six months. But that means you need to be ready to make decisions when we present you with the documentation or shortly after. She looked at me, and she said, “add three months.”So realistically, the decision making cycles also play a part.

For the nine month project that ended up being a five month reality, we had to fast track some of the items and also go back to the client and say, Well, sorry, we cannot accept any further input for now, because we have to move forward. We had to set deadlines like if there’s no feedback in that, we move forward with what we’ve got. Because some of the time, the feedback loop between client and design and development is also where a lot of time is lost.

One thing I’m always recommending against is designed by committee or development by committee, because the more people that have to look into something, the more I suppose, variety of inputs you have. What I do recommend in most projects, is to have a core project team that has access to the decision makers who can then decide “Yes, we could work with this or no there, there is a bit more to do”. “Or this is not acceptable based on our influencers or decision makers.”

If you have a decision maker, one of them on the team that can group all the other decision makers ideas together, that’s an ideal situation.

Some of the time what we know is that decision makers don’t want to be part of the project team. In those situations, the person and the people on the team need to have access to them in order to confirm, validate, and make sure that you get decisions out of them. Slippage is something to be mindful of.

From day one, keep an eye out for slippage with that I mean time slippage, but also budget slippage, and scope creep.

Usually when people start to see high level concepts and storyboards, then people get excited. “Oh, could it also do this? or Ah, yeah, maybe we can use it for that too. But then it would need a little.” And that’s where our Moscow scenario comes in: it must have this, it should have that, it could have that, but it won’t have such. Those things are important before you even touch the vision and the storyboard because yes, everything’s possible. But typically, the everything’s possible happens with more budget, more people, more time. And in any given project, delivering on time, on budget and for the project to do what it’s set out to do is more critical than to have a scope that is so vast that you have no idea where it might end up.

From my perspective, I always think about project reality. In the recent project, we had a demonstration in front of the client for it one day.  The night before one of the guys pulled an all nighter, the guys in development, pulled several working weekends, bank holidays were forgotten about. I was testing. I had my family testing. You know, my partner is his core to most of our projects, bless him is he’s fantastic. He does love games, thankfully. And he’s also a very patient man.

The reality of a project, how I best best describe it, it’s like you see the duck gliding over to water and below it, there is a whole bunch of people treading water like crazy to stay afloat. Because that is often reality.

In every given project, there’s always a snag, there is always something that pops up that you said how that could have been better, or this should have been like this. But when you look back over a project, when you look back at it, and you’re satisfied to say, Wow, we pulled it off!

This recent demonstration was one, where we had 10 games in a quest for recruitment to showcase employer branding, recruitment and an experience of what a real role would look like for an organisation. When I look back and see where we started nine months ago, and where we got to, I’m actually mega proud that we got that far. And that it looked that good, given all of the constraints that we were dealing with, under the budget that we were given, because we were still working on a very tight budget to deliver the level of delivery that we made.

From one perspective, that is something to always consider.

When you’re a client, looking at the reality of the project, what you see in the proposal, yes, it is, what the phases are like and what we strive towards. Know your budget may have limitations, if you can find more, you can get more done. If you have time to start as early as frickin well possible and in the corporate world that always easy to say. But give feasible deadlines, three months from start to finish can be done. But it’s tight. Nine months for a big employer branding, recruitment exercise is doable, but take it down to five and it becomes a stretch.

Be realistic in the possibilities. And the keep on dreaming up projects and looking for budgets, we’d love to help you achieve those visions.

I hope this gives you an insight into what reality on a gamified project is like.

I love to talk to you more about our experiences. I hope you’re enjoying the show, if you do do give us a good rating and share it forward with friends and people who you think may benefit from hearing this. I love speaking to you and I hope to meet you soon in either real life or on social media. Thank you for listening!

The post Podcast 15: What it the reality of a gamification project? appeared first on Gamification Nation.

What it the return on investment of gamification?

On occasion, we are asked what the return on investment (ROI) is for gamification. The majority of our work is inward facing towards employees and in some cases towards customers or on top of apps or platforms which could be either. I have to say I don’t always get the question of ROI in the HR and learning space and maybe they are aware that some of the benefits are much softer in nature than hard numbers.

Calculating ROI

The formula to calculate ROI is simple in accounting terms:

ROI = (Gains – Cost)/Cost

So the formula is typically not the hardest thing to measure, but rather quantifying the gains is the typical stumbling block on most projects. To know whether you have gained anything you must have a baseline figure. If you don’t have a baseline before picture, at best we can give a rough estimation of gains based on other benefits.

Deciding on how gains are calculated for any given gamification project may open the debate on what would be considered adding value. From an HR perspective, an increase in confidence or higher retention of staff may be a great measure, but for a sales manager if they are not hitting the target objectives it is still not enough. Each case and project may be different and it may also be different for each organisation. That’s not to say that you shouldn’t invest time and effort into going there, The process alone will throw up some interesting value discussions and one would hope that you know the answers to these rather innately based on what your company stands for.

An example

Let’s drill this down a level to a boardgame project we did a few months ago. The original problem was that salespeople were not very comfortable talking about cybersecurity to business owners because they didn’t understand the potential impact. We didn’t have concrete numbers and if we did we probably wouldn’t be allowed to share them in any case. If we wanted to quantify this we would have to set up a base survey before anyone played the board game and a post-play survey. We could also look at sales figures in cybersecurity both before and after. Most sales directors will argue not any one thing will impact sales and that is true, so measuring how a learning intervention of any kind is impacting numbers is a bit of a subjective measure in my opinion. But you can ask salespeople at the end of the month how many additional conversations they had on this topic thanks to increased confidence and better knowledge and then look objectively at the conversion rates.

So let’s make up some fictitious numbers then. Let’s imagine sales numbers were on average £20,000 per sales agent per month in cyber-related products. We expect the gamification to increase confidence and help them retain more information which can illustrate the benefits of their cyber products. Let’s also imagine that the project cost £20,000 to make the numbers easy. We implement the gamification project and salespeople report in the post play survey that their confidence in talking about cyber has gone up by 80% and their retention of useful information to talk to clients with by 40%. The learning team could say that this is a fabulous outcome, however, sales management probably wants to know the figures. So they go and look at the number of conversations held about cyber products and their conversions before and after. Here they notice a 40% increase in conversations and a 20% increase in conversions so the average now edges up to £24,000 per sales agent. So you could argue that the net ROI gain here is £4000 or 20%.

Not every area in the business has hard numbers to calculate against unless they operate with key performance indicators and the net impact on overall business performance. Also, I kept the example a bit simplistic without ongoing costs and other potential conditions that have an impact on an employee actually doing anything.

Value of investment or VOI

Because of the labour intensiveness and complexity of getting to these calculations, many organisations won’t actually do the work to find out the true value add of internal facing programs. In some learning circles, the term ROI is occasionally replaced with VOI or value of investment to reflect the softer benefits a learning piece may bring to the equation. Now, this becomes a sellers’ paradise as long as they can introduce benefits that are perceived value adds this number will go up. I would err on the side of caution here and still aim to quantify exactly what values and what they are in your organisation before implementation and then after.

Whilst I think it is important to understand the value, unless gamification impact the bottom line of hard numbers whether that is in staff retention numbers, increased attendance, project completion on time and on budget or sales figures, it ought to be measured. Knowing the additional softer values may give you a qualitative input perspective, but in my humble opinion, it should not be the replacement of measuring ROI.

As someone who has held various internal roles as well as external ones in learning and development in the corporate sector, a lot of interventions are not always done with key outcomes in mind. The question why is often not answered and in gamification I see similar behaviours in some parts of our industry.

How to build a business case for gamification?

 

 

The post What it the return on investment of gamification? appeared first on Gamification Nation.

What is the return on investment of gamification?

On occasion, we are asked what the return on investment (ROI) is for gamification. The majority of our work is inward facing towards employees and in some cases towards customers or on top of apps or platforms which could be either. I have to say I don’t always get the question of ROI in the HR and learning space and maybe they are aware that some of the benefits are much softer in nature than hard numbers.

Calculating ROI

The formula to calculate ROI is simple in accounting terms:

ROI = (Gains – Cost)/Cost

So the formula is typically not the hardest thing to measure, but rather quantifying the gains is the typical stumbling block on most projects. To know whether you have gained anything you must have a baseline figure. If you don’t have a baseline before picture, at best we can give a rough estimation of gains based on other benefits.

Deciding on how gains are calculated for any given gamification project may open the debate on what would be considered adding value. From an HR perspective, an increase in confidence or higher retention of staff may be a great measure, but for a sales manager if they are not hitting the target objectives it is still not enough. Each case and project may be different and it may also be different for each organisation. That’s not to say that you shouldn’t invest time and effort into going there, The process alone will throw up some interesting value discussions and one would hope that you know the answers to these rather innately based on what your company stands for.

An example

Let’s drill this down a level to a boardgame project we did a few months ago. The original problem was that salespeople were not very comfortable talking about cybersecurity to business owners because they didn’t understand the potential impact. We didn’t have concrete numbers and if we did we probably wouldn’t be allowed to share them in any case. If we wanted to quantify this we would have to set up a base survey before anyone played the board game and a post-play survey. We could also look at sales figures in cybersecurity both before and after. Most sales directors will argue not any one thing will impact sales and that is true, so measuring how a learning intervention of any kind is impacting numbers is a bit of a subjective measure in my opinion. But you can ask salespeople at the end of the month how many additional conversations they had on this topic thanks to increased confidence and better knowledge and then look objectively at the conversion rates.

So let’s make up some fictitious numbers then. Let’s imagine sales numbers were on average £20,000 per sales agent per month in cyber-related products. We expect the gamification to increase confidence and help them retain more information which can illustrate the benefits of their cyber products. Let’s also imagine that the project cost £20,000 to make the numbers easy. We implement the gamification project and salespeople report in the post play survey that their confidence in talking about cyber has gone up by 80% and their retention of useful information to talk to clients with by 40%. The learning team could say that this is a fabulous outcome, however, sales management probably wants to know the figures. So they go and look at the number of conversations held about cyber products and their conversions before and after. Here they notice a 40% increase in conversations and a 20% increase in conversions so the average now edges up to £24,000 per sales agent. So you could argue that the net ROI gain here is £4000 or 20%.

Not every area in the business has hard numbers to calculate against unless they operate with key performance indicators and the net impact on overall business performance. Also, I kept the example a bit simplistic without ongoing costs and other potential conditions that have an impact on an employee actually doing anything.

Value of investment or VOI

Because of the labour intensiveness and complexity of getting to these calculations, many organisations won’t actually do the work to find out the true value add of internal facing programs. In some learning circles, the term ROI is occasionally replaced with VOI or value of investment to reflect the softer benefits a learning piece may bring to the equation. Now, this becomes a sellers’ paradise as long as they can introduce benefits that are perceived value adds this number will go up. I would err on the side of caution here and still aim to quantify exactly what values and what they are in your organisation before implementation and then after.

Whilst I think it is important to understand the value, unless gamification impact the bottom line of hard numbers whether that is in staff retention numbers, increased attendance, project completion on time and on budget or sales figures, it ought to be measured. Knowing the additional softer values may give you a qualitative input perspective, but in my humble opinion, it should not be the replacement of measuring ROI.

As someone who has held various internal roles as well as external ones in learning and development in the corporate sector, a lot of interventions are not always done with key outcomes in mind. The question why is often not answered and in gamification I see similar behaviours in some parts of our industry.

How to build a business case for gamification?

 

 

The post What is the return on investment of gamification? appeared first on Gamification Nation.

Podcast 14: What is involved in the gamification design process?

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.