What is the difference between user interaction for games as opposed to productivity apps?
closed as unclear what you're asking by Jimmy, Tyyppi_77, Philipp, doppelgreener, Gnemlock Nov 18 '17 at 23:11
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Before my career as a game designer, my training was in industrial design, studying classic interaction design. And at my first studio we spent a fair bit of time building productivity apps as you describe to pay the bills when game work wasn't always reliable. ;)
While most of the same principles of user-centered design apply, there are some useful distinctions I've found:
Your user has to want to be there. Generally speaking, every interaction we design should be as enjoyable and fulfilling as we can make it, of course. But in productivity apps you can get by with a dry or uninspiring user experience as long as you get the job done. The user is there to accomplish a task.
But players come to games for the experience itself - you can't coast on pure functionality. If the means of interacting with the software isn't enjoyable or satisfying (and this includes well-crafted "negative" experiences like feeling fear / sadness / anger if your game is promising horror / drama / etc..), then players won't play the game and will look elsewhere.
This also means conceiving of your users/players and their needs in a different way. I won't go into all the details of player motivation models we use in games here, but suffice it to say that we often need to consider more of the person's emotional situation and preferences to deliver a game experience that will resonate with them, as opposed to a productivity tool they find handy.
Responsiveness is everything. In productivity apps and web design, if a change takes effect and presents visual/audio feedback inside a tenth to half a second, it's considered instantaneous from the user's point of view.
In games, every frame matters. A player input that doesn't trigger a perceptible response until a frame or two later (still 3-6x faster than the web designer's "instantaneous") can cause the game's controls to feel "floaty, sluggish, squishy" in a way that's difficult for players to pin down - it's felt in the texture of the interaction rather than consciously detected. This goes double and triple in VR, where maintaining high framerates and snappy interactions are key to maintaining a sense of immersion and minimizing simulation sickness.
This isn't just a problem for engine programmers to minimize input latency and maximize framerate. It's also in the types of feedback we as designers choose to provide to the player. If a character has momentum and can't turn on a dime to respond to a sudden change in input without breaking the physics or the realism of their animation, we can do things like have the character turn their head to look in the new direction, or change their movement sound to signal back to the player "I heard you" immediately, even if the full consequences of the input will manifest over a few more frames.
Keeping this interaction feedback loop tight and the audio-visual-tactile signals rich can create immense toy-like delight in just operating the controls. For more on the power of feedback in interaction design for games, I recommend checking out "Game Feel," "Juice it or Lose it," "The Nuance of Juice," and "Pizzazz First, Polish Later" ;)
Unique interaction vocabulary. Through iteration in many games, we've developed a shared language of what various controls generally do, at least in the default mapping (customization is important too, but for now I'll focus on the out-of-the-box experience). Your right stick is camera, your left mouse button is main weapon, you move with WASD, the gamepad face button in the "South" position is "Accept" and often "Jump," while "East" is "Cancel," unless you're in Japan where the convention is reversed. etc.
Sticking to these familiar conventions helps a game feel expected / right, and minimizes confusion or error for players with experience from other games. This is in principle the same as following interaction conventions in other disciplines, just specialized to the particular vocabulary we've developed in games.
Note that this can also be a double-edged sword. It's easy as experienced players and game creators to take these conventions completely for granted, and forget that they're not universally known. The first game with dual analog FPS controls that we now consider standard was initially reviewed as "almost unplayably difficult to control" - and those controls didn't get fundamentally easier, we just trained players to get used to them. So some of these conventions can pose a significant barrier to bringing new players into the fold, and it's important to consider how your target audience's past play experience will inform their control expectations.
Friction is fun. In classic interaction design we'd seek to minimize obstacles in the user's path, so they can get to their goal in as few steps or with as little effort as possible.
But a game is at its most fundamental level, as Bernard Suits defines it, "the voluntary attempt to overcome unnecessary obstacles." If we took out every bump in the road and optimized for getting the player to the victory screen in no time, it's unlikely the player would get to feel they'd "overcome" anything!
So effective game design often means making the interactions less effective, as measured in pure task-completion efficiency. A long slow wind-up attack can feel more exciting than one that's instantaneous, and provide more challenge for strategically deciding when to use it / how to react to it, creating more gameplay out of a completely artificial and unnecessary delay. Or if the player needs to drag items together one by one to assemble them manually, this can feel more tactile and satisfying than if the game automated this labour.
Instead of trying to minimize friction and adversity, the challenge comes in tuning its amount, to be approximately proportional to the player's capability and readiness to overcome it, which changes from player to player and over time as they master the game's systems.
Here I haven't even gotten into the design considerations of adversarial interactions, where two users are actively competing to out-perform one another, which I think is just about unique to games.