GDnD Wiki

GDnD Wiki

This site is for Ulster University students and staff. Enter the class access password to continue.

Design Communication in Game Development

12 min read

Summary

Communication is the most difficult aspect of game project management, and it is the designer’s primary professional instrument. Designers work through other people — translating creative intent into art requirements, engineering specs, production plans, and QA regression lists. Every channel used to do this (documents, meetings, email, messaging apps, face-to-face conversation) has specific strengths, failure modes, and disciplinary norms.

This page documents the communication framework O’Connor developed over 20+ years of studio experience, covering tools, formats, and the distinct communication demands of each development stage (O’Connor, The Craft and Science of Game Design, see source-craft-and-science-game-design).

Key ideas

Why communication is hard in game development

Games are harder to communicate about than standard software because:

  • No brief verbal description can cover the totality of a game’s feature set
  • Every team member brings a personal reference frame of games they have played, creating different mental models for the same term
  • Teams grow during production; late joiners create assets without full design context
  • Even the design team itself rarely fully absorbs the complete design as it evolves
  • Fan wikis and public forums often contain more accurate information about shipped games than internal documentation

A small team of six people can communicate more effectively day-to-day than 500 distributed around the world — which partly explains why some small indie teams produce more innovative gameplay than large AAA studios, not because small teams are inherently better but because communication overhead grows non-linearly with team size (O’Connor, The Craft and Science of Game Design, see source-craft-and-science-game-design).

Vision and pillars

At the start of a project, the team needs to believe in the game’s potential. The designer’s ability to articulate the vision clearly and compellingly is foundational to team confidence.

Vision statement: A concise, impactful description of the core game experience in one or two sentences — an “elevator pitch” that can be quickly transmitted to anyone on the team at any level. This is harder to write than it sounds; it must be precise enough to guide decisions and compelling enough to sustain motivation through a multi-year production.

Game pillars: Typically three core gameplay components or player experience statements that underpin the project. Examples of what a pillar might express:

  • A key technological innovation (“unprecedented destructible environments”)
  • A unique player point of view (“you play as a ghost navigating the living world”)
  • A central narrative or emotional premise

Pillars serve multiple functions simultaneously: they are the main selling points of the concept, production priorities to focus resources on, and stable reference points for evaluating design decisions throughout the project. When scope changes, the pillars are the last thing to negotiate away.

Keywords: Find precise terms that describe the vision and use them consistently throughout all team communication. Inconsistent or drifting terminology creates confusion that accumulates into significant misalignment. If a term’s meaning changes, update it explicitly and explain the change.

Communication channels

Stand-ups

Daily stand-up meetings (a scrum-in-game-development practice) are for brief, relevant updates — not design discussions. Designer contributions should cover:

  • Progress on current prototypes and iteration results
  • Changes to features or documentation that affect current tasks
  • Blockers and dependencies

Detailed design descriptions, explanations of mechanics, or requests for clarification should be taken offline into separate meetings. The point of a stand-up is that everyone learns something useful in minimum time.

O’Connor’s note on over-communication: when announcing changes to documentation or design decisions, do not assume the team is keeping up. Actively over-communicate updates because team members are focused on their own tasks and are unlikely to check for changes spontaneously.

Meetings

Meetings are the engine of design development when properly run and a serious productivity and morale risk when abused. O’Connor’s four rules:

  1. Agenda in advance. Distribute a short, focused agenda before the meeting so attendees can prepare. Stick to it. Off-topic issues should be taken offline.
  2. Take notes. Record decisions, action items, and changes. Send notes to participants and relevant stakeholders the same day. Without this, meetings produce amnesia rather than alignment — the same topics recur in future meetings because nobody documented what was agreed.
  3. Invite only key stakeholders. Keeping the invitee list small keeps discussions focused. Leads pass highlights to their teams. Senior managers attend only when their decision is required. A production representative at design meetings is valuable as an early warning system for scope issues.
  4. Keep meetings under one hour. Beyond an hour, productive discussion degrades exponentially. If all agenda items are covered in 20 minutes, end the meeting. Do not fill time.

Email

Design emails are effectively part of the design documentation. Treat them accordingly:

  • Follow the same content standards as other design documents
  • Clearly indicate who is responsible for each item and which designer owns each feature
  • Flag importance and use precise, descriptive subject lines
  • Avoid back-and-forth debates in email — complex discussions should happen face to face; an email chain typically adds confusion rather than resolving it
  • Read emails back from the recipient’s perspective before sending; wording that seems clear to the author often reads differently to others

Messaging apps

Messaging apps (Slack, Teams, and equivalents) are essential for quick coordination but carry specific risks for design communication:

  • Do not design through messaging. Do not announce design changes or add missing detail via chat. The recipient audience is unknown, context is absent, and the information becomes untrackable. Keep design information in documents or email.
  • Refer to documents, don’t replace them. When people ask design questions via message, refer them to the appropriate document rather than providing an off-the-cuff answer. Quick replies contradict or circumvent documentation.
  • Manage notifications actively. Messaging apps are engineered to attract attention. Customize notifications to protect deep work.

Face to face

Even in something as natural as a one-to-one conversation:

  • Have at least three people present when possible, to verify shared understanding
  • Do not improvise design decisions in conversation without documenting them afterwards
  • Make clear when you are exploring alternatives versus stating final design — without this distinction, informal ideas get mistaken for official direction and spread through the team
  • After any significant conversation, send a brief email recap to the other person to confirm what was discussed and agreed

Communication integrity

Designers enjoy a creative freedom other disciplines do not. That freedom is a professional liability if not accompanied by discipline:

  • Be more organised and reliable than your role technically requires — this builds the goodwill needed when design results are judged
  • Resist gossip and complaint about colleagues; it lowers your own credibility and emotional energy
  • Own mistakes clearly and publicly; move on quickly
  • Give credit where it is due, verbally and in documentation
  • Choose design battles carefully; not every disagreement merits escalation

“Designers must be optimistic and positive, after all you are selling a dream and should act accordingly.” (O’Connor, The Craft and Science of Game Design, see source-craft-and-science-game-design)

Design task types and document formats

The three-pass document lifecycle

Design documentation should follow a three-stage process:

Draft: Quick internal document describing the feature’s main intention and most significant production components. Structured as:

  • Intention — what is the purpose of this feature from the player’s perspective? Why should it exist?
  • Design description — step-by-step description of the feature, using numbered subsections, diagrams, and reference images (one visual per page minimum to aid navigation and comprehension). Does not attempt exhaustive detail.
  • Designer’s notes — the rationale behind key choices, alternative B-versions considered, open questions. Helps the team understand why decisions were made.

Drafts may be shared with the broader team clearly labelled as drafts not yet ready to work from. They circulate within the design leadership for review before progressing.

First pass: Incorporates feedback from draft review. Ready for public consumption — team members can read it confident that most of the content will make it into the game, even if not final. Reviewed with senior leads across disciplines.

Final approved version: Reviewed, debated, and signed off by all major stakeholders. This version enters the central design repository as official and authoritative. Typically becomes increasingly obsolete beyond Alpha as cuts and reworks accumulate — by Beta, maintaining full documentation accuracy is impractical.

Feature Description (FD) format

The FD is a design pseudo-code format originally developed at Ubisoft to communicate precise feature information to large teams with varying English-language proficiency. It strips out the prose of design documents and reduces them to their minimum functional components in spreadsheet form (O’Connor, The Craft and Science of Game Design, see source-craft-and-science-game-design).

An FD serves three simultaneous purposes:

  1. Design specification: Line-by-line mechanical description of exactly how a feature functions
  2. Production task list: Each line maps to a specific task for a specific discipline
  3. QA regression checklist: The FD is the basis for testing that a feature is complete and working as designed

Standard FD fields:

  • Title — feature name
  • Project — which game this belongs to
  • Designer — the owner, responsible for updating the document throughout the project
  • Intention — a condensed summary of what the feature does from a player perspective
  • Description — line-by-line mechanical details, for example:
    • How is the feature activated? (button press, proximity trigger, etc.)
    • Duration of any gameplay effects
    • Area of environmental effect
    • Associated AI behaviour changes
    • Inventory or progression changes triggered
    • UI elements involved
    • Menu items affected
    • Combat effects (buffs, debuffs, cooldowns, interrupts)
    • Animation requirements
    • 3D asset requirements
    • Particle/visual feedback requirements
    • Audio feedback requirements

The FD is particularly valuable during Alpha and Beta when design documents are becoming outdated but feature-level information must remain accurate for implementers and QA testers. It is designer-maintained throughout the project lifecycle.

Communication by production stage

Preproduction

Design work is research and hypothesis rather than specification. The goal is answering: What is the core experience? What are the pillars? Who is the audience? What is the scope, budget, and technology? What does the competitive landscape look like? What is the monetisation strategy?

The preproduction period ends when major stakeholders agree on a vision document and initial core design documents. This can take a month to six months depending on scope and risk appetite.

Prototyping

The designer’s job is to identify the minimum representative elements of gameplay that can be quickly built and evaluated. Iteration — build, test, evaluate, refine — is the primary process. Get stakeholder feedback on each version, prioritise what to address, keep the cycle moving. Production drives resources; design drives priorities.

First playable / vertical slice

Core gameplay demonstrated at higher polish with sample art. A vertical slice adds approximately an hour of playable content, representative environments, AI examples, basic progression, and economy loop samples. Each milestone refines the concept and realigns the project. Stay flexible; features that do not work should be dropped without attachment. (See also vertical-slice.)

Alpha

All core systems and content are built during Alpha. The key word for the designer here is consistency: whereas prototyping demanded flexibility, Alpha demands maintaining a coherent vision of the final game across every parallel workstream. The designer has the broadest view of the whole project — use it to identify when things are going off-track and communicate clearly to get them back.

Design communication in Alpha: keep feature descriptions updated as the primary information source for teams cycling through; maintain documentation even as features change rapidly, since multiple developers may cycle through the same feature over weeks.

Beta

Feature complete. Focus shifts from building to closing. Design responsibilities:

  • Prioritise bugs for the programming team (show-stoppers first, then major system failures, then “polish bugs” — small issues that disproportionately undermine the experience)
  • Do a full balancing pass across all gameplay data, ideally using a spreadsheet view of all major values simultaneously rather than iterating in the editor one value at a time
  • Change one value at a time when balancing to isolate the real cause of imbalances (O’Connor warns against “nerfing” multiple values simultaneously)
  • Inform level designers of any balancing changes that affect AI difficulty, so they can adjust encounter populations accordingly
  • Keep FD documentation updated for QA regression testing accuracy

In practice

For student projects and small teams, the most practical applications of this framework:

  • Write a one-sentence vision and two or three pillars before starting any implementation. Write them down. Refer to them when feature discussions get circular.
  • After every design decision made in conversation, send a one-paragraph recap email to the people involved.
  • For features you own, maintain a simple spreadsheet of mechanical requirements — this is effectively a personal FD and doubles as a test checklist.
  • In stand-ups, report results and blockers only; save design explanations for dedicated meetings.
  • When you change a documented design, update the document the same day and flag the change explicitly to the team rather than assuming they will notice.

Open questions

  • The FD format is attributed to Ubisoft but no primary source is cited by O’Connor. Is there published industry documentation of this methodology or evolution of the practice?
  • How do modern tools (Confluence, Notion, game-specific wikis) change the three-pass document lifecycle? Does the FD format translate to wiki-style documentation, or does it require a dedicated spreadsheet?
  • O’Connor recommends at least three people in face-to-face design conversations for verification. Does this principle hold on fully remote or async-first teams?

Graph View

Backlinks