Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Get the latest Education e-news
 
  • Debunking Game Design Myths: UX Is Just Common Sense

    [05.26.22]
    - Michael Moran
  • 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.

Comments

comments powered by Disqus