GDnD Wiki

GDnD Wiki

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

Design Leadership

8 min read

Summary

Design leadership is the practice of operating effectively as a designer within a multi-disciplinary development team. It is less about game design techniques and more about the professional and relational skills needed to translate design ideas into finished, polished features through the work of other people.

O’Connor’s core argument is that design decisions ripple across art, sound, technology, production, budget, and marketing simultaneously. The designer occupies a central — but rarely formally powerful — position in the team. Influence therefore depends entirely on earned trust and credibility, not on job title or authority (O’Connor, The Craft and Science of Game Design, see source-craft-and-science-game-design).

Key ideas

Being an effective designer

O’Connor offers several concrete practices for earning and keeping team respect:

Be prepared. Whenever meeting with other disciplines on implementation, have updated documents and a set of possible solutions ready. Do not ask others to figure out design problems on your behalf.

Make decisions. Artists, engineers, and sound designers work to precise schedules. They cannot function if design decisions are vague or perpetually deferred. Make the decision, record it by email, and stick to it. Being wrong occasionally is far less damaging than creating sustained uncertainty.

Do not let the document do the talking. A design document is a starting point for collaboration, not a final specification. Walk relevant people through it; hold meetings before teams begin work on features. Expect questions — they reveal unstated assumptions and are healthy. Integrate the feedback quickly and update the document while memories are fresh.

Don’t fear being wrong. Games are built iteratively; features get cut, reworked, or replaced for reasons beyond the original designer’s control. Protecting ideas defensively is counterproductive. Treat prototype failures as information.

The importance of feedback

A design that incorporates no outside input tends towards what O’Connor calls an “inbred design” — internally coherent but blind to its own flaws. Design by committee produces the opposite failure: a “Frankenstein game” of everyone’s favourite features stitched together incoherently.

The middle ground requires:

  • Creating an atmosphere where anyone on the team feels free to suggest ideas at any time, without expectation of adoption
  • Listening genuinely, then explaining the design context that makes some suggestions fit and others not
  • Using questions from non-designers as an opportunity to demonstrate the complexity of the design system — not a challenge to deflect

The key test: can you explain your decisions clearly enough that people who proposed alternatives come away understanding why the chosen direction is better for the game as a whole?

Objectivity

“Being able to honestly evaluate the merits of a design idea regardless of authorship is key to being a good designer.” (O’Connor, The Craft and Science of Game Design, see source-craft-and-science-game-design)

Practically, this means:

  • Acknowledge superior ideas from outside the design team, publicly and by name. Taking credit for someone else’s idea is the fastest way to destroy professional credibility.
  • Distinguish between fighting for something because it is genuinely right for the game versus defending it because it is yours. These feel similar from inside; they look very different from outside.
  • Pick battles carefully. Every unnecessary design argument spends trust that will be needed for the important ones.

The business side

Designers must understand the strategic conditions of their project — budget constraints, technology scope, projected release schedule — without crossing into micromanaging upper management’s decisions. The goal is designing within the real constraints of the project, not a theoretical ideal version of it.

O’Connor notes that features should fit the scope whether the game is a £500,000 or £50 million production; scope awareness is not a constraint on creativity but a discipline that makes creative decisions more credible and sustainable.

Working with other disciplines

Each discipline has its own culture, workflows, and professional language. A designer who learns these is more effective; one who ignores them generates friction.

Programmers

Work in precise, concrete terms. Provide: mathematical formulas where possible, feature lists with exact asset requirements, functional diagrams, edge cases, failure states, and alternative plan-B versions. Avoid dense prose. Ask programming leads for their preferred documentation format and pipeline timing rather than publishing documents spontaneously. Write two levels of documentation: high-level vision (for general consumption) and nuts-and-bolts feature specs (for implementation teams).

Artists

Do not become an art critic. Keep the designer hat on. Offer aesthetic input when solicited, framed as personal preference rather than creative authority. Before any art work begins, be explicit about what the game is not — stylistically, thematically — to avoid costly misdirection. Understand that animators sit at the critical intersection of design vision and production budget; work closely with animation throughout to maintain that balance.

Sound designers

Sound is psychologically central to the game experience, not a finishing layer. Establish shared atmosphere early through video and audio reference. Be open to changing scripts and dialogue during recording sessions — experienced sound practitioners and voice actors often understand what sounds right better than written dialogue predicts. Sound design input should be treated with the same respect as other creative disciplines.

Production

Include production in design reviews, implementation meetings, and design team discussions. Their effectiveness depends on staying informed. Regularly publish notes from major implementation meetings if producers cannot attend in person. A well-informed producer can advocate for features before management decisions are made and can filter pressure from above rather than transmitting it downward.

O’Connor’s guiding principle: the production team’s role is to judge whether work is moving forward and what actions need to be taken — not to adjudicate the merits of design discussions. Inexperienced producers who attempt to resolve design debates by fiat cause serious dysfunction.

Writers

Writers need to wait for stable game systems and content before finalising dialogue, voice sessions, and localised text. Align with them early and keep them continuously updated on design changes. Give them genuine creative latitude — do not be precious about minor story elements. Writers “know what works better narratively and need to be given the leeway to bring that expertise into design decisions.” (O’Connor, The Craft and Science of Game Design, see source-craft-and-science-game-design)

Marketing

Marketing teams carry data and metrics that design teams often lack: competitive analysis, player demographic insights, market positioning. Support their requests for screenshots, quotes, and video material even when production is under pressure. The process of connecting a game to its audience — “Discovery” — is hard, and marketing is the primary partner in it. Treating marketing as peripheral until launch is a common and costly mistake.

Other designers

Designers are “an opinionated bunch” — the same quality that makes them good at their job creates friction in collaborative settings. O’Connor’s recommendations:

  • Remain objective; argue the case for what is best for the game, not what you personally prefer
  • Distinguish “fun” (a legitimate design rationale) from “fanboy” (uncritical attachment to a reference)
  • After the argument phase, commit fully to the agreed decision — even if it was not yours — and ensure the team does the same
  • Provide a clear design vision before discussing specific choices, so discussion has a framework to anchor to
  • Be consistent: contradictory messages from different designers in front of other departments damage credibility and confuse implementation teams
  • Watch for designers “going native” when embedded in feature teams — they may lose sight of the overall game direction

In practice

For students working in team projects, O’Connor’s principles translate directly:

  • Write brief meeting notes after every implementation discussion and send them to attendees the same day
  • When pitching a design feature, lead with the player benefit (intention) rather than the mechanics — this is the language every discipline understands
  • If someone suggests a better approach than yours, say so out loud in the group setting
  • Maintain separate documentation levels: a short vision statement for everyone, and detailed feature specs for implementers
  • Use prototyping results as the primary argument for or against design decisions; opinion without evidence rarely resolves design disputes in healthy teams

Evidence

O’Connor draws almost entirely on personal experience across 20+ years of studio development work, from the early 1990s through 2021. He cites Kim Swift (designer of Portal) on humility, and uses a Michael Caine / Zulu production anecdote to illustrate the value of a protective producer. The advice is observational and practitioner-oriented rather than academic. (O’Connor, The Craft and Science of Game Design, see source-craft-and-science-game-design)

Implications

  • The skills described here — objectivity, decisiveness, cross-disciplinary communication, earned authority — are not design-specific. They are professional practices that apply across most leadership roles in team-based creative work.
  • For students: most degree projects involve smaller, shorter team experiences where these dynamics are compressed but still present. Practising the habits early (meeting notes, explicit design rationale, separating argument from commitment) builds professional muscle memory.
  • For educators: teaching design leadership alongside design craft addresses the gap O’Connor identifies — that the industry perpetually re-discovers the same lessons because they are rarely documented or formally taught.

Open questions

  • O’Connor’s experience is primarily in mid-to-large console/PC studios. Do these relational dynamics scale down to indie teams of 2–6, or do they become less relevant at that scale?
  • How do remote and distributed team structures (which became far more common post-2020) change these communication and trust-building practices?

Graph View

Backlinks