In this series, I’ll be punching holes in the myth that game design UX is just "common sense." It's time we gave UX the space (and respect) it needs to thrive in your game.  

Let’s state the facts: UX is vital to the success of any game.

Ship a game with glaring UX issues and you put your game at risk of damage it can’t come back from. Turning off players. Frustrating fans. Losing its standing in the market. 

So: UX has the power to make or break a game. But with the endless list of myths surrounding UX in game design, our industry hasn’t exactly been acting like it. But today? That changes. Today, we finally give game design’s UX the attention it’s due.

In this series, I’ll be punching holes in myth after myth – helping you understand the importance of UX and helping you give it the space (and respect) it needs to thrive. First up on the docket? The myth that, when it comes to game design, UX is “just common sense.”

If you’re ready to join me on this myth-dispelling journey, let’s go. 

The context

It goes without saying that the average game developer is skilled. They know their stuff. And while it usually takes them years of experience to hone their intuition, most are well-versed in a set of core principles – deemed universal design principles (as coined by professor/author William Lidwell) – from the beginning. 

But the thing is, knowledge of those principles – even when in combination with intuition – isn’t enough to offset mistakes. Nor can it be single-handedly relied on to guard against flaws. 

You could have the smartest developers who’ve borne witness to the widest range of wins and losses, but if all you’re depending on is their foundational instinct… you’re not protected. I’ll repeat that: 

If all you’re depending on is their common sense, you’re not protected. 

Understanding and producing top-notch UX requires developers to adhere to the right principles and conduct the right research, sure, but it also requires them to ask the right questions. It also requires them to have the systems in place that defend them from the issues that they – for whatever reason – couldn’t see. 

Because what we’ve seen time and time again is that it’s common practice for games to launch with ‘common sense’ problems:  problems that should’ve been found and fixed long before. Problems that should’ve never been allowed to cross the finish line. 

So then: how can experienced, esteemed, insightful practitioners let that kind of thing happen? How can those ‘common sense’ mistakes occur not just here and there, but over and over again – regardless of game type or internal process?

The answer is not because the developers in question “lacked common sense…” which would be the instinctive logical explanation. So, if these pitfalls are surfacing even with developers’ common sense in-tact, then what’s causing them? If common sense isn’t enough of a safe-guard, what is?

The issue

Let’s look beyond common sense. What’s responsible for the ‘common sense’ problems that rush to the surface in games that are post-release? Well, there are a few culprits – and no, they’re not mutually exclusive.

Knowledge, A Hidden Curse:

While competence and dexterity are invaluable to any line of work, it’s possible that a developer could simply be too close to the problem. Their UX expertise and familiarity with the game might actually be working against them, keeping them from experiencing (or thinking about) the game like a new player would. The result? They’re exposed to issues and imperfections they never even considered.

Awareness, A False Comfort:

Then there are the developers who are juggling too many tasks on their to-do list. They might be aware that there are issues requiring their attention; they might have even planned to correct them. But when push came to shove, they didn’t take action – because their awareness lulled them into a false sense of comfort. It allowed them to forget… until it was too late.

Time, A Fleeting Case:

Maybe the developer can see the problem. Maybe they’re aware they need to act. But maybe, with a list of tasks a mile long to execute before launch, they simply don’t have the time to implement the fix. Without having time on their side, their recognition of the issue – or knowledge of how to fix it – doesn’t matter. There’s no worse culprit than a ticking clock. 

The solution

So, where does that leave us? Well, it leaves us dispelling the myth that productive UX solely comes down to common sense. Sure, having proficiency and experience makes for a solid foundation, but when those pesky ‘common sense’ problems still rush to the surface, you need something else to protect your efforts.

And that something else is a strong UX process. 

See, each of our brains is overrun with biases – social, cognitive, perceptual, you name it, we’ve got it. That amalgamation of biases, unique to every individual, makes adhering to one ‘common sense’ outlook nearly impossible… because what each of us is able to expect, recognize, and interpret will be different. And that means there’s no one straight perspective – or track to perfection.

Instead of relying on their own common sense abilities, smart developers protect themselves with system over instinct. Not only does system solve for the three issues outlined above – which I’ll demonstrate for you in a second – but it also solves for the inherent biases every practitioner has. 

What does a sturdy process look like in practice? Obviously, specifics depend on the developer’s game, team size, and daily task list, but the key elements remain constant:

• Identification: Here’s where you carve out time to take stock of your work and look for any issues – before it’s time for release. The more time you allot to investigating and locating, the cleaner the finished (and launched) product will be.

• Assessment: You’ve located the problems, now it’s time to assess them. What are they? How did they happen? What subset of your audience will they affect (if they don’t get fixed)? Taking the time to break each issue down will help you move through this process, but it’ll also help you avoid finding the same issues in your next production cycle.

• Prioritization: Based on your assessments, it’s time to prioritize which issues you’ll fix first. Here’s an example: 

• You have two fixes to make. The first isn’t as intense a problem for players – they can work around it without too much hassle. But, the scope of who it affects is huge. Like, impacts-a-core-game-pillar huge. 

• The second is a more intense problem for players, visibly affecting their gameplay experience, but the population of who it affects is much smaller in scope – because it only impacts a higher-level feature (irrelevant for the majority of the game). 

So which takes priority? In this scenario, the first issue does – because even though it’s less impactful as a standalone problem, the number of players who’ll face it (and have to adjust their play accordingly) is greater.

• Solution: Now it’s time to fix…and fix some more. Following the prioritization order you settled on, attend to the first issue and then work your way down, systematically crossing off each one. The beauty of prioritizing ahead of time? If you run out of time pre-launch, you’ll still have fixed the most pressing problems.
• Identification: Wait a second, didn’t we already cover the identification phase? That we did – but surprise: this process isn’t a straight line. It’s a loop. And just like you can work your investigative lens in the pre-launch phase, so too should you work it after your game’s been released. In fact, it’s easier to critique a game – and uncover its issues – once it’s live than it is to identify flaws in development. 

One more time for the people in the back? That’s Identify, Assess, Prioritize, Solve, Identify. And on and on.

The conclusion

Now, let’s back up. Remember those three reasons I laid out for you earlier – the three reasons for why those pesky ‘common sense’ problems can make it into your players’ field of vision? 

• Knowledge: being too familiar with your game. 
• Awareness: recognizing but forgetting to act. 
• Time: setting out when the clock’s already timed out. 

Each of those reasons exists even when a UX practitioner possesses common sense – and each of those reasons can be solved for by simply implementing a process, like the one above, into your day-to-day. By setting aside time to look for, understand, and fix issues methodically, what you’re really doing is outsmarting your biases. You’re outsmarting the risk of seeing and then forgetting, and you’re outsmarting the tick-tick-tick of that ubiquitous operational clock.

Now look – it’s not like I’m proposing something that’s never been discovered or promoted before. Take any field and you’ll find established methodologies for proving hypotheses. Why? Because the human brain can’t be trusted to catch every detail or evade every bias – but more often than not, systems can. More often than not, processes can.

And that takes us back to where we started. At the foot of the myth. UX is just common sense. If a developer possesses common sense, they’re good to go.

If I did my job, you now have the knowledge spear necessary to poke holes in that claim. But more than that: you now have the guidance necessary to overcome the problems that common sense doesn’t solve for. You now have an actionable process.

And that wraps us up for today. But this is a series, which means I’ll be back – dispelling myths, uncovering truths, and helping developers near and far get the attention (and respect) they deserve. 

UX matters. It can make your game, or it can break it straight in two. Join me back here for Myth #2 – There’s just no money or time for UX – for more insight, advice, and old-school claims debunked. Because UX deserves its time in the spotlight. And outdated myths shouldn’t hold their practitioners back any longer.