Context
Two audiences, one broken loop
Game creators building for Xbox, from independent studios to AAA publishers, run into platform issues on a deadline. In 2022 there was no single place to report one, and no way to see what happened after they did. On the other side of the loop, the Microsoft and Xbox teams responsible for resolving those issues were juggling Azure DevOps, forums, and email, with no shared view of the same ticket.
The engagement was deliberately two-sided: phase one focused on the external user (game creators), phase two on the internal user (the support and product teams). I led the UX work across both: thirteen user interviews to ground us, then a problem framing workshop and design sprint per audience, prototypes for each, and usability testing to validate them.
Framing
Getting fifteen stakeholders to agree on the problem
Cross-functional groups do not naturally agree on what is broken. The problem framing workshop forced the question: participants collected problems, affinity-mapped and voted, then placed the winners on a business impact versus business effort matrix. The stickies tell the story in the participants' own words: "Developers don't know when fixes ship," "No developer-facing interface to track requests," and the top vote, "Inability to easily track developer issues."
The workshop's final exercise assembled problem, why, persona, and KPI into a single testable statement. The group's top-voted version became the brief for everything that followed.
Design Sprint
From long-term goal to a testable concept in two days
The design sprint compressed the classic week into two facilitated days plus a prototyping runway. Day one produced the long-term goal ("in two years' time, developers have a low-friction, secure way of communicating and tracking issues"), the sprint question ("can we track the entire issue lifecycle across multiple teams?"), and an end-to-end journey map of how an issue moves from a developer's desk through Microsoft's teams and back.
Day two ran lightning demos, three-part concept sketches, and a straw poll that crowned a winner (a concept the team named "Mo Tickets, Mo Problems"). We then breadboarded and storyboarded the ticket-creation flow step by step, with each step annotated with why it matters, the user's goal, and the features it requires. That storyboard was the direct blueprint for the prototype.
Design
Polaris: track the whole lifecycle, respect both sides
The prototype, named Polaris, gives game creators the single front door the problem statement demanded: authenticated sign-in, a dashboard scoped to their studio's projects, guided ticket creation (summary, details, attachments, review), and a confirmation that immediately surfaces similar issues and articles so duplicate tickets never start.
The internal-user prototype answered the other half of the loop: a triage dashboard with filtering by team and category, explicit claim-or-assign ownership so tickets stop falling between teams, threaded communication attached to the ticket, and privacy stop gaps that protect unannounced titles before anything is shared externally.
Validation
Tested with the people on both sides of the ticket
- Small-batch usability sessions. Following the Nielsen Norman Group's small-group testing guidance, we ran 12 external-user sessions and 13 internal-user sessions across both prototypes, moderated in small groups over three testing days.
- Findings fed the recommendations. Testing validated the single-portal model and sharpened the backlog: integrate and sync with the Xbox and Microsoft ADO databases, add related tickets and articles, and build role- and team-based permissions for ticket visibility.
- Handed off with momentum. The engagement closed with documented workshops, tested Figma prototypes for both audiences, and a recommendation set that advanced into the client's blueprint and development phases.
Impact
Alignment first, then a portal worth building
The lasting value was shared definition. Fifteen stakeholders across Microsoft and Xbox product, support, and engineering left the workshops agreeing on the problem, the user, and the KPI, and the tested prototypes gave the build teams something concrete to carry forward. As one participant put it during testing: "Half of us understood one problem, and the other half understood a different problem." The workshops ended that.
Reflection
What I took away
- Facilitation is a design tool. The highest-value artifact of the engagement was not a screen, it was a problem statement fifteen people voted for. Screens only stay shipped when the organization agrees on why they exist.
- Design both sides of a service. A support portal that delights developers but dumps chaos on internal teams fails within a quarter. Running a full phase for each audience kept the system honest.
- Two days is enough. A compressed two-day sprint with disciplined homework (lightning demos as overnight assignments) produced a winning concept as reliably as the five-day format, and busy client teams actually attended.