Lessons Learned in Games Development: Open Communication
By: Cian Mcnabola
Tags: Leadership, UX, Game Development, Teamwork, Communication

In my career as a UI/UX designer in video games I’ve learned many valuable lessons which you can use as a UI/UX designer, a producer, an artist or anyone in games development who is interested in seeing their project succeed. Sometimes these lessons have to be internalised the hard way, through experience, but hopefully I can at least help you prepare for when certain problems inevitably afflict your team.

In this article I’m going to discuss the importance of clear and open communication with your team, using personal examples from my own experience. I’m also planning on following up on this article with other vital topics, such as ownership and incentives.

Complication

Working on video games is complicated. There are many interlocking parts, many plates which must be kept spinning. Roughly — when working to deliver a new feature on a live-game, an overall goal is set for the feature (for example increasing DAU and bookings by some percentage), what kind of feature it will be is brainstormed and then settled on by production and game design. After this decision is made 4 questions must be answered — As Peter Drucker writes in “The Effective Executive”, ‘Who has to know of this decision? What action has to be taken? Who is to take it? And what does the action have to be so that the people who have to do it can do it?’ this will then lead to game design and the UI/UX designer delivering thorough wireframes and mock-ups, iterating upon them many times over until they are chiseled down into the smoothest, most user friendly flow possible. Code will then ‘breathe life’ into the layout mock-ups and artists will deliver beautiful, polished assets to replace the white-boxing done in the game-engine. Finally the UI/UX designer (and the whole team, probably) will tweak and adjust the work during a testing phase to iron out any bugs prior to code-freeze and delivery.

If success is to be had, all of this must be done in close co-ordination, with near constant communication between those working together.This is because there are many places where the process can break down and flounder. The overall goal can be misinterpreted right from the beginning, with the team cracking ahead with work which is not at all in line with the goals of the feature. This will result in losing valuable days or weeks as well as motivation on work which must be dumped or, at best, salvaged.

Isolation

A common occurrence in my own experience is that code begins building a feature at the same time as game design or the UI/UX designer are working out the flow or functionality of the individual screens. This concurrent working typically leads to lost work as well a lot of sitting idly by, and ultimately to lost time for the team and lost money for the employer. Furthermore, the severe frustration, loss of trust in the competence of one’s team-mates and general miasma of confusion will almost doubtlessly lead to skilled workers “checking-out”. This can happen when a team are working in isolation too much and not regularly speaking to each other to check in on what each other are doing and why — creating more moments to catch potential pitfalls before they become a severe problem.

Cal Newport’s “Deep Work” explains in tremendous detail why skilled workers need to be able to spend great lengths of time uninterrupted, to produce their best work. However, in agile teams building games we must find some balance between this and communicating regularly with our team and remaining in sync with them.

Communication

Perhaps the single worst experience in my career involves a truly terrible communications breakdown on a feature-team working to deliver a new feature on a live game. During this period, the team had thorough and clear meetings in which we’d discuss our plan, who was doing what and when and these would proceed without a great deal of conflict of vision. We’d typically leave these meetings confident about what we were doing.

But curiously, after a couple of days we’d find ourselves confused, each working on something different to what the other was expecting. Despite temporarily successful efforts to clear up the broad confusion, this issue would always return and a total motivation drought soon set in, before the feature was cancelled.

But How?

So how could an experienced team of highly competent professionals agree to one objective, but then find themselves all working towards quite different ones? And for this to happen several times over?

This genuinely perplexed me. I would not discover the root cause until much later, when I encountered the problem in the team again and was able to identify the common thread and cross-reference my suspicions with several of my team mates. As it turned out, our game designer was, privately, much more unhappy with the planned outcome of the feature than he’d made known to the team. But it appeared he had accepted the feature owner’s decision and had grabbed an oar with the rest of us. This couldn’t have been farther from the truth. Eventually it became clear that the game designer had been holding back in our feature-team meetings, only to later privately contact individuals in the team to tell them we were changing direction, contacting each separately. Even going so far as to privately recruit someone from outside the feature-team to step in (seemingly spontaneously at the time) and interfere on his behalf, quietly coaxing team members into working on the game designer’s vision. Perhaps he believed he could subtly puppeteer the team into changing direction and deliver a feature not agreed upon, but to his own liking (which, of course, did not happen).

“The team must…. depend on each other and understand who depends on them. If they forsake this principle and operate independently or work against each other, the results can be catastrophic to the overall team’s performance“ — Leif Babin, Extreme Ownership

There are many things wrong with what the game designer did, of course. He was knowledgeable and experienced and so should have known better. It was thoroughly disrespectful to his team, it demotivated them, it was short-sighted and petty, but most importantly of all — it failed. And this failure cost the employer money. If the live game that the launch of this new feature was supposed to aid didn’t pull it’s weight financially, it could ultimately result in some of the team being laid off.