Comparing computer games with “serious” software applications may seem like comparing apples and oranges if we think of serious software as tools that allow users to achieve mission-critical productivity goals in their working live. In this respect, the two industries couldn‘t be further apart regarding their target audience and the way they rank productivity vs. fun. For this reason, we are oftentimes asked why Centigrade as a “serious” user interface design company collaborates so closely with the game industry and even has a branch office located in a building that’s otherwise occupied solely by game development studios.
Yet, the link between computer games and industrial software is more obvious than one may think. To summarize why we believe computer games can have a positive impact on the user experience (UX) of industrial software applications, this three-part blog post provides a bulleted list of ten arguments we keep on stating in this regard. The first part gives a high-level and process-oriented perspective on the topic, the second part will shed more light on the transfer of aesthetic and interactive aspects found in games to serious software and the third part will have a look at the game industry as a technical driver for innovations that spill over to other software industries.
1) User experience has an emotional factor – games remind us vividly of this
First of all: usability is not user experience. I have to say it loud and clear, because these two terms are repeatedly misused as if they were completely interchangeable. However, while usability is a measurable quality – the degree to which an interactive system can be used efficiently, effectively and satisfyingly by specified users to achieve specified goals in a specified context of use – the term user experience is much fuzzier. User experience brings in an emotional component that cannot be underestimated and that usability due to its engineering-oriented history is not prominently known for. User experience in its widespread meaning does not only put a stronger focus on aesthetic aspects such as attractiveness and joy of use, it also spans a broader scope in a way that incorporates the entire experience of a product from packaging, over its actual usage to support services.
Computer games are perfect examples to explain this difference vividly. You can design a game in a way that makes it really challenging for a player to control. Achieving a goal in such a game (e.g. getting to the next level) definitely is far from being efficient – and for first-time players it is not even effective. I leave it to the reader whether the usability of the game must be regarded as being bad even when this challenging control is well-designed. My point is that the term usability just does not really fit in this context because efficiency and effectiveness regarding the achievement of a goal is not something that would make the player happy. The term user experience fits a lot better here, because it can be positive even though the player is absolutely inefficient and ineffective – of course this goes only when the game fulfills aesthetic demands as well, such as memorable sounds, catchy graphics and a persuasive gameplay. If these conditions are met, people are willing to learn coping with the control, even if it’s challenging to handle.
This doesn’t mean that applications in serious industries should face users with challenges (if they are complex they will do so anyway) – the key thing is that games remind us of the fact that user experience is more than usability and can hardly be put in numbers – and rightly so. User experience even has the power to dilute negative interaction aspects that are just not really fixable. Internalizing this circumstance leads to a much broader thinking about design solutions and eventually results in serious applications that users just like more than others – measurable or not.
2) Computer games require designers and developers to work together – without killing themselves
Let’s not fool ourselves – designers and developers are just not made to work smoothly together – at least not right away. They are like oil and water, requiring an emulsifier to blend seamlessly. It’s the old story about mutual exclusive talents, about engineering and arts, rationality and creativity, left and right hemisphere.
In serious industries, a good and fruitful collaboration of designers and developers is the exception – if designer are involved at all. Unfortunately, a bad designer-developer collaboration most likely leads to a poor user experience as most design concepts don’t survive their way through the entire software development process chain.
Yet, in the computer game industry, a good designer-developer collaboration is standard. And it has to be – otherwise a game that combines engineering and artistic aspects to equally indispensable amounts just wouldn’t come about. Why does it work there and what is the emulsifier that makes designers and developers blend?
In a computer game, visual design or motion design is not an add-on. It is an integral part of the product without which the game would fail immediately. Everyone in the game development team knows it. Design therefore earns quite a lot of respect also from developers. The lack of respect for design activities or even doubting their right to exist is a common source of problems in serious industries. From a functional perspective, the software can be operated without any visual or interaction design whatsoever, so what’s design worth anyway?
On the other hand, designers in the serious industries oftentimes have a poor engineering background. But rather than eating humble pie for their lack of engineering knowledge they wonder why developers are just never satisfied with their specification, constantly uncovering gaps which – to make matters worse – they amateurishly fill with wimpy design-knowledge. But: it is not the developer’s fault to raise unresolved design problems or to question inconsistent design “solutions”. The designer needs to look at himself before pointing the finger at the developer. Software development is a painful and difficult challenge even without any design involved – designers should acknowledge this. Though I am over-exaggerating a bit in terms of wording, it again boils down to a matter of respect. This time it’s just the other way around.
In the game industry, most designers have an adequate engineering background, not least because they have to cope with very complex 3D graphics tools such as 3ds Max or Cinema 4D. They constantly need to care about non-design questions such as “How many polygons am I allowed to use in my model so that my character does not just look nice, but the game as a whole still runs smoothly?”
To keep a long story short: in the games industry, designers do care about engineering stuff and developers do care about design activities. This mutual respect is the emulsifier for their smooth collaboration. Serious software industries can definitely learn and benefit from this attitude and as a result come up with better user experiences.
3) Game development studios mostly have small budgets and tight schedules – but they still move a lot
The number one argument of UX-agnostic software development companies: “We cannot afford the luxury of compensating an external UX consultancy or even an entire UX department just for the sake of making the software a bit more usable.” Number two is: “We already have a very tight schedule. We cannot saddle ourselves further with that user experience stuff!”
Let’s leave a side for a moment the fact that the return on invest is pretty high when UX is solidly established – when comparing game development studios and serious software development companies, I dare say that budgets in the game industry are much smaller and schedules are much tighter in relation to the outcome of a project. This certainly is due to the fact that game designers and developers are burning for their jobs and the things they create. This passion more than once leads to quite a lot of unpaid long hours and of course compensates part of the financial and timing-wise crunch. But that’s just half of the truth. Game development studios are also pretty smart about being efficient – they have to in order to survive in a publisher-dictated market.
Take, for example, the RITE method. RITE stands for Rapid Iterative Testing and Evaluation and is an iterative usability method that was initially introduced at Microsoft Games Studios by Michael Medlock, Dennis Wixon, Bill Fulton and Mark Terrano. Roughly spoken, this method is similar to what Jakob Nielsen refers to as “discount” usability engineering and therefore contains cost-saving elements such as minimizing the number of participants or leveraging “cheap” techniques such as “think aloud”.
Yet, RITE is different from traditional usability methods in that it tries to be as rapid as possible. Defects in the user interface that are uncovered during a test are fixed immediately – sometimes even if the problem occurred just for one single participant. This, in a sense, is very time- and cost-effective as often enough a couple of problems exist for which better solutions are obvious and easily applicable. If, for example, you identify with the first participant that a poor labeling exists in the user interface, why should you proceed testing the UI with 5 other participants when sanity and reason tell you “This misunderstood label will definitely be a problem for the other participants, too”?
Being smart and pragmatic about uncovering usability problems in the user interface and keeping iterations small and frequent definitely is something that serious industries can learn from. And they already did so: since its official definition, RITE’s use has heavily expanded beyond the games space.
In the next part of the blog post, we will dive a bit deeper into the aesthetic aspects of user experience and shed light on the question why the game industry takes a pioneering role here that should definitely call attention from industrial software companies.
All trademarks and product names used in this article are trademarks or registered trademarks of their respective owners and are used solely for descriptive purposes.