I have worked in different companies with different sizes and focus. Small and big, agencies and product companies. I even worked in an agency inside a product company. Last year I had a chance to work in Wargaming — a large game developer and publisher. This experience in game development showed me my work as a designer in a product company from a different angle. I want to share with you some take aways from this experience. I hope that you can pick-up some of them into your design teams.
Before we move on let’s take a look at the game industry in general from the interface designer point of view. I noticed that when I mention game industry it is often perceived not seriously and even as something funny — “Where have you worked? Really? Why?!!”. From my experience I‘d say the game industry is a really serious field to work as a designer. Both UI and UX expertises are present there and they have a big word to say. I never saw such deep user researches and analysis. I‘ve never been engaged so much with products that I worked on.
Here I’m referring only to my work experience within Wargaming in general and MCS (Marketing Creative Services), IDeA (In-House design agency) and Wargaming Mobile teams in particular.
Now let’s talk about what we can pick-up from game industry.
Know what you are doing
As an interface designer you should know and understand the purpose of UI you are working on.
We had a rule: before starting to work on a game-related project designer should play this game 4 hours without reporting this time. That’s a preparation for a design work. Some projects were more complex and required not only 4 hours before start but even regular game sessions on daily basis. Here I’m referring to complex projects, like a game portal or a game UI.
Why this time is important? You can read tones of user research documentation, watch hours of user test videos, but you will dive into the product much faster by experiencing it. Playing your game is a key for deep understanding key game mechanics and that is really important in long-run projects like making a game. That will give you a clear understanding of players reasons to play the game, his needs and it will help you to separate core functionality from secondary.
When I’m looking back I understand the importance of this simple practice. It helped me to make meaningful decisions, to stand behind those decisions and be able to defend them.
Here is a take away for any designer in a product company: use your product to understand how it’s works.
* * *
Know your competition
It is always good not to live in a vacuum, but to look around and to know what your competitors are doing.
By competition I mean direct competition like all products playing on the same field, but also indirect competition — products from different fields that can replace your product for the user.
We started every day from standup and a coffee talk about what we played yesterday. All types of games from all types of platforms were welcomed. We kept our standups short and focused, but major game industry events affected us — we shared progress of the God of War storyline or results of yesterday team session in Destiny 2.
That’s also very important source of your inspiration. Guys, I will share here a big secret of game designers: game designers are not searching for inspiration on dribble. Do you know why? Because they are playing games. Think about it.
Take away: don’t look for inspiration on dribbble — know and experience your competitors, both direct and indirect.
* * *
Analyse and compare
In our team we had a practice of making detailed competitive analysis for understanding the place of the product in its niche. We did analysis of game portals, of AAA-game UI’s and landing pages. By doing so we had a clear understanding of market as a whole and the place of our products on the market in particular. That knowledge was often used for not directly related project (like a design of a game-companion app), but also to kick-off some projects (guys, here is analysis, here is the place of our product, we definetily can do better, let’s do so).
Take away: not only know your competitors, but know how your product stands against them.
* * *
Know your area
Here is ambiguous but an interesting point. For sure it is not applicable for some product fields, but I still want to share it with you.
First thing that I learned when I started is a list of core principles of the main game trilogy dedicated to WW1/WW2 era. One of the principles was historicity — all the game models are historically accurate. And not just accurate — you could build a real tank/warship/warplane from those models. Each game studio has a dedicated team of engineers and historians that make sure that all the parameters of each model are historically and physically correct. And in the company I met a lot of people who knew not only the product that they were working on. Their knowledge goes beyond that — they know how real tank is operating and what you need to do to make it run and fire.
Ones we discussed ideas for a project that targeted an “engineers” target group. Halfway in the discussion I realized that project manager not only knew how to load main caliber gun on a battleship (get a shell from magazine, get a powder bags from another magazine, lift them up to the gun deck, open the seal, load shell, load powder and so on), but she knew how many men you need for that task (around 80 sailors for one 16” turret of Iowa-class battleship, without counting crew of magazines).
I’m still under impression from this meeting. Mostly because of how chill everyone was about this knowledge that seemed so extraordinary to me.
Take away: go beyond your job description, wonder how mechanisms are working.
* * *
Know your users
Here is one of my favorite findings. In all game UI projects we always took a hardcore player case as a main case. Why? Because those guys are spending much more time in the game than the others. They have much more units (tanks, warships, warplanes) researched, so that’s a good case for management in interface (shortcuts, filtering, sorting and so on). Last but not least — hardcore gamers bring more money to the company.
Sounds logical, right? Anyway in all the product companies and agencies where I worked we were designing for beginners as for the main category of users. We looked at hardcore users only as an edge case if we had time/resources.
Take away: focus on those who are passionate about your product, who use the product and not on those who come and go away.
* * *
Respect your users
This point is related to the previous one. We always had a principle “our players are not stupid”.
We measured our players by ourselves. We didn’t pull them by the arm explaining them everything 15 times. We didn’t annoy them with countless notifications — here is a button, we want you to press it! Here is another button, press it also! That’s how you learn things, private! Nope. Give users freedom, they will find buttons. Do you have doubts? Do you think that buttons are not discoverable? Test on your colleagues, friends and on beta users.
Why is this point important? Many times in different companies I was helping to “fix” solution that was good for 95% of users and not “clear enough” for the rest 5%. This 5 percent is a big amount for large products, but fixing something that is not broken in many cases led to terrible experience for the 95% of users.
Take away: your users are not stupid, they can figured your UI out. Focus on good solution that pleased the majority of users and just help the smaller amount to understand your solution.
* * *
Be proud of what you do
When I visited the main game development studio I was impressed by the amount of people wearing t-shirts and hoodies with company/games/teams branding. I never saw so many people in product companies who would be proud of what they do. I never met so many people who care about what they do.
Take away: be proud of what you are doing or you are working not for the right product.
* * *
Be a pirate
As a team of 25 creatives we were a part of the company of 4500 people. Any large company has a very complex structure and a lot of bureaucratic rules to align everyone. That’s creates a lot of blockers along the way and reduced speed of the daily work execution. I guess everyone who worked in large companies recognizes it.
In our smaller team we just used our own processes and tools if it was necessary to overcome blockers or make our work more efficient. That allowed us to move faster as a team without waiting.
Take away: don’t complain, but analyze what you can do, make your proposal, pitch it and push it. Be a pirate within the navy if it will lead your team to success.
* * *
The text and all take aways are written mostly for myself. Those are the things I’m starting to miss now that I’m not in Wargaming and game industry anymore.
I will be more then happy if you find a use of things that I outlined.