The same few questions, every raid night.
Raid teams upload combat logs to Warcraft Logs, which can answer almost any question but is built for general use. After a wipe, an officer asks the same few: who used a defensive, was a raid cooldown late, and could that death have been prevented?
I wrote the product around one persona, an officer on a progression team who reviews logs between pulls without a second monitor. The tool is for diagnosing execution, not for ranking players, so it shows no performance scores. It comes from the same game as my 2023 course project on sound cues for healers.
I directed the project and made the design calls. Most of the code was written with AI coding agents, which the commit history records.
Rules before screens.
The timeline is the organizing idea. A new question should be answered by adding a lane, marker, or overlay to a timeline before inventing a new kind of view.
Players already know Warcraft Logs and two community tools, Lorrgs and Consistency, so the layouts follow their conventions instead of teaching new ones. The interface is grayscale and sharp-cornered so that color only carries data: class colors, spell icons, phases in green, and deaths in red. Status pills and decorative color are ruled out, and interactions have a 100-millisecond budget.
Every view uses real report data. An early demo mode was removed, and spell names and icons come from the report itself, because they change with each game patch.
The same player, three months apart.
On June 27 the first build read a live report and drew one timeline: when each player used defensives and cooldowns, on every pull of a boss. On the same report, it showed a single tracked ability for this Holy Priest and no casts on most early pulls.
The current build shows the priest’s major cooldowns on nearly every pull, a boss row of mechanics for reference, and controls that align pulls by phase instead of by pull start. Boss health now matches the figure Warcraft Logs reports.
Most of the difference is the ability list. It is organized by role and category, scoped to each specialization, and checked against community datasets and the loaded report rather than written from memory.
Both captures load one public report, a Mythic progression night of 37 pulls, with character names replaced by each player’s spec.
A whole raid on one phone screen.
On July 2 the layout was rebuilt so the phone gets its own arrangement, not a squeezed desktop: bottom navigation between pull and player, filters and details in sheets, pinch to zoom, tap to inspect, and long press for actions. Later passes compacted the chrome until a 20-player pull fits on one screen.
What shipped, and what stayed hidden.
The deployed app has a report overview, pull and player timelines, and a player summary with talent trees and gear. It runs as one always-on service that keeps the API credentials on the server and caches report data.
Several features were built and then held back. Death analysis and a damage-taken timeline run only in development. A Mythic+ dungeon view and a comparison of top-ranked runs for one specialization were built with automated tests, then hidden from the deployed app in August because they were not polished enough.
Many design changes started as numbered notes I wrote while using the app, such as making zoom work the way it does in Warcraft Logs, with the wheel panning and a drag selecting a range. About 60 commits close a numbered note or issue.
In August, a registry of raid tiers let a new season start without breaking old reports, and bosses without a curated mechanics row get one derived from cast frequency, with a threshold calibrated on real logs.
Where it stands.
The app is deployed and open, with rate limiting to protect the shared Warcraft Logs quota. The repository is private.
It has had no research with other raid officers. The persona describes how I review logs; a study would start by watching other officers between pulls.