Abstract
Problem: What does a typical workday look like for a system designer in the game industry?
Approach: Tim Cain walks through his daily routine as a system/mechanics designer, from early morning through afternoon, covering different phases of the development cycle.
Findings: A designer's day splits into focused writing time (mornings), collaborative meetings and "whatabouts" (midday/afternoon), and heavier design work informed by those discussions (late afternoon). The role shifts significantly as production progresses — from writing design docs to playtesting, creating QA test plans, and handling press.
Key insight: Structure your day so easy tasks build momentum in the morning, collaborative work happens midday, and deep design writing happens in the afternoon when you've gathered input from others.
Morning: Early Start and Easy Wins
Tim arrives early — well before most game developers, who tend to treat start times as suggestions. He notes that in every studio he's worked at, people roll in around 9:30 when the stated time is 9:00, something his friends in other industries find shocking.
The quiet early hours are valuable. He grabs coffee (Obsidian's cold brew machine is credited with his coffee addiction), checks email, then starts on his to-do list — deliberately organized with easier tasks first. Knocking out a few quick items builds momentum so that by the time he hits harder problems, he's already "in the zone." This is the same technique he uses for programming.
Late Morning: Meetings
Meetings cluster around 10–11 AM, once people have actually arrived. Tim identifies several meeting types:
Design Team Meetings
Discussions with other designers about specific systems — combat, inventory, quest structure. These are department-internal and focused on design decisions.
Strike Teams
Cross-discipline groups (artist, programmer, designer, audio, QA, producer/AP) assigned to a specific feature for a milestone. A combat Strike Team, a stealth Strike Team, a dialogue Strike Team, etc. They meet once or twice a week and serve as a steering mechanism — if ranged weapons are taking too long, the team can decide to cut some. The producer tracks pace against deadlines.
Lead and Director Meetings
Lead system designer meets with lead quest designer, lead narrative designer, lead level designer. Sometimes directors pull in leads for cross-department discussions on specific topics.
Publisher and PR Meetings
Publishers visit the studio, often arriving the night before for dinner with directors/leads, with meetings the next morning. Marketing and PR meetings ramp up in the last third of development when rollout plans are being built.
Afternoon: Whatabouts, Deep Writing, and Questions
After lunch the vibe shifts. Everyone is present and available for individual talks — what Tim calls "whatabouts and what-ifs." He drops by other designers' desks or visits programmers working on his features: "Hey, how's that going? Hit anything? Had an idea?"
These conversations feed into the afternoon's heavy writing session. Morning work + meeting discussions + individual talks all inform the deeper design documents he tackles now. Anything lighter that comes up gets added to tomorrow's morning to-do list.
Throughout the afternoon, programmers send questions via Slack — clarifications on area-of-effect radii, maximum throw ranges for prediction arcs, things that were left out of the design doc now that they're actually coding it.
Late Development: Playtesting, Test Plans, and Press
The daily pattern shifts as the project matures:
Playing the Game
Designers play the game looking for something QA won't catch: inconsistencies between the design and the implementation. Seven player response nodes where the rule says five. Shotguns still powerful at range despite data looking correct. These aren't traditional bugs — they're design-implementation mismatches that only the designer can spot.
QA Test Plans
Tim learned this lesson the hard way. On Vampire: The Masquerade – Bloodlines, QA didn't like playing Nosferatu, resulting in severe bugs going unnoticed. On earlier titles, Atari's QA barely tested Bards or Halflings. Designers should create explicit test plans: test these classes, these race combinations, these skill/perk builds. You can't cover every combination, but you can ensure all major playstyles (ranged, melee, stealth, dialogue, exploration) are verified as viable.
Tim shares a concrete example from The Outer Worlds: he did an entire melee-only playthrough and found one level nearly impossible due to heavy verticality and ranged NPCs. He and the lead designer played it together, confirmed the problem, and fixed it by adding melee-only NPCs that run down to the player and cover at ground level to hide from ranged attackers.
Press Events
Late in development, designers get pulled into press days, presentations, video calls, and Q&A sessions with journalists. Designers are ideal for this — deep game knowledge and (relatively) more free time than programmers or QA at that stage.
Key Takeaways
- Easy tasks first — build momentum before tackling hard problems
- Mornings for solo work, midday for collaboration, afternoons for deep writing
- Strike teams are the primary cross-discipline coordination mechanism, scoped to milestones
- Slack before walking in — respect people's focus time
- Play your own game looking for design-implementation gaps, not just bugs
- Write QA test plans — don't assume testers will cover edge-case builds
- The day-to-day is surprisingly similar to programming; it's more about personal work style than the discipline itself
References
- Tim Cain. YouTube video. https://www.youtube.com/watch?v=GwVocugnoEo