Before we get started, I’m going to be upfront with you. I think both of these terms, Gamification and Design Thinking are utterly hyped to a point that, in many cases, they are detrimental to actual progress and innovation in the field.
Despite this belief, hang in there, I do believe the fundamental insights these terminologies are based on are valuable.
Hype is a double-edged sword. Hype can be necessary to push forward meaningful concepts into the mainstream. At the same time, once it has made it there, hype can take meaningful concepts and turn them into a — pardon my language— pissing ground of ownership in a land of false and over-promises.
All teams are on a mission to find ways in which we can successfully design amazing, engaging experiences for our products or services. It’s natural we look to hypes for inspiration. The goal isn’t to avoid or disown hypes, but rather wipe away the smoke and mirrors to find, and use, the real value.
For this reason, I want to explain how I approach these two terminologies to try and help you ground them in the bigger picture.
Starting with Semantics
I know this sounds a little academic, but, like any good design, it’s important to have a good foundation built before you continue development.
In short, like many others, I see Design Thinking as a human-centric iterative problem solving philosophy. Design Thinking, in pretty much all of its iterations, is about designing for the user, and finding ways to test solutions to their problems in a low effort manner.
And Gamification? Well, it’s kind of the same. Gamification is also a human-centric iterative problem solving philosophy.
Ultimately, all design philosophies, regardless of type of experience, is about the user, solving their problems, and benefiting from iterative design. These are not different in the core, rather, they are different in their base observations and perceived output, e.g. the reason we are attracted to it.
Let’s start with Design Thinking. I see Design Thinking as an observation that teams that center design decisions on testing assumptions on how to solve problems create products and services that provide value.
This is also what most designers want to achieve with their design process. Thus, Design Thinking is a decision to use a design process that keeps design teams centered on the problem
Design Thinking is a human-centric iterative problem solving philosophy, based around testing assumptions — this is the observation — with the goal of creating a design process that keeps teams focused and cost effective.
And Gamification? I see Gamification as an observation that games are extraordinarily good at bringing players into a state of engagement and flow. Flow is a mental state where the person is totally immersed in an activity. It is, as according to acclaimed researcher Mihály Csíkszentmihályi “being completely involved in an activity for its own sake.” That’s the highest level of engagement possible.
This is what most designers want to achieve with their experiences. Whether this is realistic or not is another topic, but let’s continue on this thought. Thus, Gamification is a decision to design experience the same way we design games to achieve similar level of engagement.
Now, there are many definitions for game design, but I will use one that focuses on the output: Game Design brings worlds to life (makes them interactive) to engage players in structured play for enjoyment.
Why “enjoyment” and not pleasure, entertainment, or fun? Pleasure is a feeling of contentment we achieve when we feel that expectations have been met. It’s a more passive stance. Enjoyment, on the other hand, is a feeling of forward movement and accomplishment where a person’s abilities are stretched.
I avoid fun — often defined as lively or playful enjoyment — because not all moments in games are fun. Their outcomes are enjoyable but not always the in-between process. This is often why games are called Entertainment - the act of providing or being provided amusement or enjoyment.
So, then let’s say Gamification is a human-centric iterative problem solving philosophy, based around play — this is the observation— with the goal of bringing users enjoyment — this is the perceived output.
Still, even with these expanded definitions, it’s important to consider another semantic decision: I refer to these as Philosophies, not Methodologies or Processes as many consultants and agencies do.
What’s in a name?
It’s important to ground these terminologies as Philosophies and not Methodologies or Processes to manage our expectations.
A philosophy is a system of beliefs that influences someone’s decisions and behavior.
Design Thinking (and Gamification) are Philosophies because they are beliefs that designers are inspired by in their design process. However, they are not concrete methodologies — there are so many ways to do user research (Empathize) or create prototypes (Prototype).
A methodology is the methods and principles that are used for doing a particular kind of work.
An Empathy Map is a methodology because it is a concrete method that can be used for understanding the user.
And I want to lightly touch on processes. A process is a series of actions of steps taking in order to achieve a particular end.
Scrum is an example of a process.
So what’s the takeaway.
Gamification and Design Thinking are philosophies that have made observations about the way certain approaches generate outcomes.
At their core, they all have three main aspects:
- Know the user.
- Find their problem.
- Test solutions (assumptions).
It’s important to remember that absolutely nothing can produce reliable innovation. There is no magic fix. This is why treating these concepts as philosophies manages expectations. Ultimately, it’s the methodologies and processes that help you achieve the goals of these philosophies.
Keep your user close.
Everything you design should be to help them solve their problem and should fit their communication style.
Here’s some methodologies and tools that can help you explore the user.
Fall in love with the problem.
Know their problem & make it your everything. You’ve got to resist the temptation to immediately jump to solution. If you don’t, you’ll end up designing a solution you may love, but your users may not.
“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.”
For this, I recommend making sure to have a problem statement. Here’s a few examples below (complied from this wonderful article on problem statements from Toptal).
#1 I am a PERSONA trying to VERB but BARRIER because CAUSE which makes me feel EMOTION.
Use this if you find it easier to phrase your problem in terms of what is getting in the way of what your user is trying to do.
#2 PERSONA needs a way to NEED because INSIGHT.
Use this if you find it easier to phrase your problem in terms of what is the reason behind the user’s desire to complete an action (verb/need).
#3 Our WHO has the problem that WHAT when WHERE. Our solution should deliver THIS because WHY.
This is a bit of a mix between #1 and #2 and is good if you like to frame in a big picture way. This is my go-to problem statement structure.
Map out the steps of your solution in a user’s journey.
First, I like to start out by high level mapping, either using a collaborative whiteboard tool like miro, or post-its on a physical board, the user’s actual journey.
Flowcharts show the journey of the user in the experience, with meaningful touch points highlighted. These flows are the foundation from which later gamification can be applied, adding extra (game) elements to make an impact on user engagement.
There’s no real right or wrong in how to map this out, but I like to use simple formatting. Here’ a few examples of things I consider in these higher level flows:
- Where there is a trigger to start the flows
- Where there is an action
- Where there is an decision to be made
- Where there is an exit to another flow
- Where there is a condition
In some cases I might add in important variables (like a user’s email) that are collected or manipulated (like a score), but it depends on the project. I like flow charts because they’re much easier to keep up to date than tons of documentation and easy to read.
Gamification comes after the skeleton of your experience is fully defined. What games are really good at is having completely, fully thought through designs, that consider aspects of the experience and environment that those of us designing in the “real world” make assumptions and take for granted (like gravity). Thus, we don’t think through all interactions.
This quote I feel is at the core of the magic of games as well:
“Sometimes magic is just someone spending more time on something than anyone else might reasonably expect.”
When you’re thinking to add additional structure and play to your experience, ask yourself: What are your objectives for using gamification? Why did you think you wanted to use it? Gamification is really system design. It’s thinking about feedback, constraints, and adding artificial aspects that would not just exist in the real world to try and increase enjoyment of the experience.
Be sure that the objective isn’t to manipulate. When we look to design to manipulate our users into doing something, we’re really saying that we’re afraid we don’t provide value. We don’t trust them to realize this, and if this is the case, the design is flawed at the core, or there is not a real problem we are solving.
Drill-in to the user journeys you choose to prioritize and add-in Gamification.
When I’m ready to explore a user flow (journey) in greater detail — whether it is a pre-existing flow I’m going to help improve, or a brand new flow I want to take to the next level — I break down the flow in relationship to the user.
This is just a methodology I use, so feel free to adapt it to your needs, but it can help you get started.
What you want/need the user to do in this step.
What the user need to do to complete this step.
What is the user feeling in this step.
What motivates or how motivated is the user to do this step.
What is the user unsure about in this step (why).
- Mechanics (LAST STEP!):
How to resolve any problems or give this step a boost. This is “Gamification”.
Remember, when you are doing user flows or journey mappings, even though you may feel like you are designing the USER’S EXPERIENCE, you’re not. We’re always designing the user’s INTENDED EXPERIENCE.
“As Liz Sanders set me straight on over a decade ago, there is no such thing as UX Design. An experience is a personal moment felt by people; something we don’t own as Designers. However, we can design for it.”
Build prototypes of elements of your user journeys you want to test.
Finally, once you understand your user, are obsessed with their problem, started brainstorming ideas to solve this problem, and have mapped out what those ideas look like, it’s time to build prototypes and test your assumptions and solutions.
Like Design Thinking proposes, iteratively designing is the best approach, because you can take what you learn from your tests and apply it to future designs.
If you start with too many features, a menagerie of solutions, you may get lost in your product roadmap and overview, struggle to build it within budget, and even understand which features or parts are effective.
Because at the end of the day:
“Which would you rather do — talk to customers now and find out you were wrong or talk to customers a year and thousands of dollars down the road and still find out you were wrong?”
- Nathan Furr and Paul Ahlstrom
There’s also a ton of articles out there on how to set up MVPs and prototypes, but here’s a few tools I like to use to create prototypes or MVPs in my own projects:
If you don’t prototype, and test aspects of your design iteratively, you will lose time and money building what you love, rather than what your users actually need.
Measure real user behavior.
The only way you will ever know if a design is working is by testing with actual users, and measuring their interaction with or use of it.
There’s also a ton of articles out there on how to set up effective measurement, but here’s a few tools I like to use to measure user activity in my own projects:
One final note.
I want to wrap everything up with a short note on an aspect that crucial to the success of every single project. That’s co-creation, or, in other words, who the team is and how the team works together.
Startups, in pre-seed, seed, or early stage funding, get this capital, in most cases, not only because of the idea, of course an idea often has to be there, but because of the team and the investors feeling on how well the team will be able to execute, or pivot, the idea. This is the same for every project, regardless of whether it is trying to, or needs to, receive external funding.
If you do not have a strong team, with a good culture of collaboration, and the right mix of skill sets, your project will struggle, regardless of the tools you apply. Establishing a positive culture of trust, room for experimentation, and space for failure with celebration for success, will propel your project forward faster than any methodology, philosophy, or process alone.
Based on my presentation for the 2020 BASE conference on how to Build, Advance, Sustain and Elevate businesses. A contribution to the Create Converge project which is supported by the European Union North Sea Region Programme.