Bio
Brian is an award-winning game designer, with some of his games having been played by millions of players worldwide. He’s worked on titles like Bramble, Fantage, and EverQuest, and has consulted for brands like LEGO, PETA, NBA, and more. He has expertise in design leadership, prosocial mechanics, online worlds, live service games, and MMOs. Community is at the core of all of his work. Brian also designs indie games for The Sheep’s Meow, where he investigates connections between personal heartfelt stories and the striking beauty of nature. You can reach Brian online, but you’re more likely to find him offline, hiking uphill through a mountain forest.
Design Process
My design process varies and is always adapted for each specific project and team. It is generally based on an iterative loop of Design → Implement → Test → Redesign again, repeating as many times as necessary. The specific workflow is different per stage of development. Each stage involves a validation step and a way to collect actionable insights. Here’s a broad overview:
Concept
- • Ideas come from anyone, anywhere.
- • Organize, circulate, and collaborate on ideas: Brainstorms, Sketches, Mood Boards, Research
- • Design brief: an overview of the concept that answers key questions that stakeholders can align on.
- • What’s the concept? What’s the hook?
- • Design Goals: What should the player experience?
- • Business Goals: Especially written out as OKRs (Objectives and Key Results) or SMART (Specific, Measurable, Achievable, Relevant, Timely) goals.
- • Validation: define the validation steps for each stage.
Design
- • Design Documentation: Continuation of Design Brief, Mood Boards, Wireframes, Mockups, Flowcharts, Tables, Charts, and other visual communication patterns. This suite of documentation must be as brief and up-to-date as possible throughout the entire development process. It must also be socialized through any appropriate channels.
- • Tools: Documents, Spreadsheets, Figma, Miro, Adobe.
- • Prototyping roadmap: What design questions will our prototypes need to answer? What order will those questions best be answered in? What kind of timeline are we looking at?
Prototype
- • Core Gameplay Loop: Tests the core loop, so it does not need to be pretty, but it does need to be clear. Depending on the project, the process would be either be building a paper prototype, building a digital prototype myself, or working with engineering to build a digital prototype.
- • Instant Feedback: Tests the look and feel of player verbs and their responses. A certain level of audiovisual fidelity is required.
- • Feedback Loop: Tests positive/negative feedback loop dynamics. The core gameplay loop needs to be hooked up to its surrounding systems (metagame / engagement / retention mechanics, depending on the project).
Internal test
- • Testing goals: What are we testing for? Any prototype being tested should be checking assumptions and seeking to answer specific design questions.
- • Testing methods vary based on needs/resources, such as using a Hallway test or Observational test.
- • Take notes and ask some of the post-test questions that were prepared in advance.
- • Record gameplay metrics on client side.
- • Iterate on the design/prototype based on information learned.
External test
- • A public alpha / beta, or simply a scheduled external test.
- • Often conducted remotely, so tools like Questionnaires and Screen Recordings can help.
- • Record metrics on server side.
- • Iterate on the design/prototype based on information learned.
Live iteration
- • Live progression / engagement / retention data is coming in.
- • Reviews / review score may provide some information.
- • Other ways of capturing public sentiment can be helpful, such as if there’s a player forum.
- • Tuning, balance, and other design iteration continues for patches or updates.
- • Project retrospective. Large projects may have smaller retrospectives at certain milestones.