Platform
Web App
Category
DIGITAL PRODUCT / UX / UI
Timeline
4 months
Project Maestro is a release-management platform for game publishers. Its users are the publisher-side release teams who take a title to market — coordinating products, metadata, assets, pricing, certification, and timing across every major storefront at once. The platform is built on a three-tier hierarchy that shows up everywhere in the product, so it's worth establishing up front:
Scope note worth highlighting
The client later reused the component system we built for the end-user experience to construct the platform's own internal staff screens — a direct engineering saving that only worked because the design system was consistent and reusable from the start.
Publishing one game title isn't one release — it's often 10–20 separate products spread across multiple platforms, each with its own metadata, assets, pricing, and certification requirements. Without a unified system, Release Managers hit three walls.
To ensure every design decision was grounded in real user needs, we followed a structured Design Thinking process—from understanding user behaviors to validating solutions through iterative design.
01
Empathize
02
Define
03
Ideate
04
Usability Testing
01. EMPATHIZE WITH USERS
Synthesized from stakeholder-reported behavior, the role model, and the teardown — a design artifact, not raw interview output. Primary role modeled: the Release Manager orchestrating a launch across every platform.
Research goals
The research focused on understanding what a Release Manager must accomplish to get a title and all its products live across every platform, identifying why the existing system failed to ensure the rebuild avoids repeating the same issues, and mapping how responsibilities differ across a publisher’s team to support the right roles and permissions.
What discovery drew on
The discovery phase combined stakeholder requirements gathered by the BA with the founders and handed over as lo-fi wireframes and written specs, a heuristic teardown of the incumbent build to surface its four UX failures, and domain and competitive analysis to understand how submission and certification work across all five storefronts.
Empathy map
Interview notes clustered around trust in the builder, clarity of layout, and a desire to picture themselves in the space.
Says
"Where does each product stand?" · "Did that build pass cert?" · "Have I entered this the same way everywhere?"
Thinks
"One missed cert requirement or dependency can blow a launch date." "I shouldn't have to type the same thing 20 times."
Feels
Anxious about things slipping silently; frustrated by duplication, unclear next steps, and no single view of progress.
Affinity Mapping
After consolidating all interview notes and empathy maps, we grouped recurring observations into thematic clusters. This exercise helped distinguish isolated opinions from broader behavioral patterns.
02. DEFINE
We reframed the brief from "look premium" to "prove the craft, then get out of the way."
PAIN
GAIN
Personas
"Jame Potter"
"I just need someone there Thursday before noon, I don't care who — I don't have time to chase this down again."
Persona 1: "Jame Potter"
01
/
03
03. IDEATE
01
Field inheritance
Define defaults (languages, release dates, age ratings) at the Project level; override selectively at Platform or Product level.
02
Multi-language localization
With no project selected, the only New action is
03
5-stage submission workflow
Guides each product through Technical Setup → Build Submission → Metadata & Store Config → Launch Readiness → Post-Launch, with platform-specific rules built in.
User flow
The Wireframes & Low-Fidelity Prototype
High-fidelity screens
04. VALIDATION
No formal usability study was run this phase. Validation came from informal feedback loops with the client and QA during the build, feeding iterative refinement of flows and components. Formal usability testing — starting with the submission-and-certification path, where the cost of confusion is highest — is the natural next-phase candidate.