The Top 5 Skills Every Game Designer Needs

A game designer is a multi-disciplinary role that requires a wide breadth of knowledge. Many people mistake this role as an “idea” role, where the game designer offers ideas to make the game more fun. In reality, the game designer’s role is to synthesize and curate the ideas from the team by making frameworks, systems, and player goals. They are the “glue” of the team.
While there are different types of game designers, like a systems designer or a content designer, these top 5 skills are useful to help the team find the fun, scope, prioritize, and iterate on the game or product.
These top 5 skills include:
- Manipulating data
- Understanding scope
- Decision making
- Public speaking
- Prototyping
Manipulating Data
Designers need understand what problems they are trying to solve, and figure out the data to point them towards the solution.
This could mean doing market research, defining data to collect, implementing the collection, or visualizing the data in a way that informs the team about what is actually happening in the player base.
It could also mean creating speculative data structures to model and simulate scenarios to test out economy and how a player might progress toward their goals.
For instance, let’s look at the problem: “How many days does it take a player to reach level 10?”
To model this, we might take into account all the ways a player is able to gain experience points. We might include parameters to change how many times per day they are able to gain XP, how much of it, while also taking into account how long a play session extends. We could simulate this via a spreadsheet, and also validate it through the game’s data using ad-hoc SQL queries.
As a game designer, I’ve used and seen many different tools to manipulate data to answer problems like this, and depending at which step in the project you’re in, you might opt for tool like Google Sheets/Excel. But understanding relational databases, knowing how to write ad-hoc SQL queries, or using R or Python will help you manipulate data to answer the team’s questions.
Scope
The ability to understand scope comes with experience. It’s the result of understanding the roles of people on the team, from artists to programmers. Making placeholder art or scripts is the quickest way to creating empathy for other teammates and understanding the timelines of tasks they may need to complete.
Understanding scope is half the battle. Being able to curate down the team’s ideas and convince people that downscoping is the proper way to proceed is also part of the challenge. Being able to estimate how long it will take to make a feature or asset and cut features that don’t support the core or meta loops directly is important so that the team will actually be able to ship the game. A great way to do this is by setting constraints the team can be creative under. These could be technical or objective constraints. For instance, the team could decide that the game needs to run on a certain platform, like an Oculus Quest, or it could mean defining the main strategy and measurable goals around your social features.
I often see many people over scope. Go to any game jam over a weekend, and many teams will try to implement 5 different mechanics, instead of choosing 1–2 and doing those very well. But this isn’t just confined to small projects, it happens every day on team of 100+. That’s why it’s important to provide constraints on the team help guide the ship in the right direction, whether it’s deadlines, objectives, or technical constraints.

Presentation/speaking
Game designers are always having to convey their ideas to the team and outside stakeholders. A workflow on a team might look like this:
- Game designer synthesizes ideas and creates a system
- UX designer creates the screen flows
- Engineers implements the systems and features
- Artists create assets
- Iterate
Since the information is flowing downward, it’s important to create concise presentations, flowcharts, and documents to drive clarity on the team. There’s nothing worse than asking an engineer to read a ten page document in order to implement a feature.
Your information needs to be clear enough but include enough context for an executive to read it and understand the vision of the experience. Often, designers are asked to present to leadership, so having the confidence and clarity to speak or pitch to outsiders is extremely valuable.
Prototyping
It never hurts to be able to test out your own ideas, and I’ve always found that the quickest way to an answer isn’t a conversation or debate, it’s feeling out the idea by implementing and iterating on it.
This is where the ability to use game engines like Unity, Unreal, or even animation tools will help you fail faster, convey your ideas to the team. You don’t need to be a programmer, but you need to understand some programming concepts, and be able to leverage the engine to get an idea across or test something out.
Decision making
The ability to make decisions comes from understanding scope, the team’s abilities and strengths, testing ideas, timeline, and the genre and history of the space you’re working in.
The main takeaway here is that you’ll need to do the homework. In order to have an opinion, you’ll need to properly test the game or feature being decided on, and understand what has and hasn’t worked in the past in other games or experiences.
If you’re looking to improve these skills, just start making something! Make something small. The more direct experience you get, the better you’ll be able to have an opinion on how to move the team forward, and be that “glue” of the team.