Project Jaguar: modernizing game and software publishing at Microsoft
A design-led re-architecture of game publishing: Shrinking simple updates from days of coordination to minutes, and a framework that became the backbone of every Microsoft storefront.
Role: Design Lead | Timeline: ~2 years through the v1 launch | Partners: Dedicated PM, Xbox Live PMs and engineers, a junior designer, third-party publishing liaison | Deliverables: Research synthesis, publishing framework, flows and prototypes, v1 launch designs
An app store from 2012 was asked to publish AAA games.
Windows Dev Center combined the Windows 8 and Windows Phone store backends into one portal for publishing UWP apps: simple products in the 2012 "app store" sense. Then, for organizational synergy, the business decided to unify the Xbox and Windows stores, and to meet an arbitrary early deadline, AAA-game functionality was layered onto a system built for much simpler products and distribution models. The result was slightly disastrous. Studios refused to onboard and stuck with the legacy Xbox dev portal, which won't be winning any UX awards, but was basically reliable despite major structural issues. This was costly to the business and continued to piss off users.
System architecture made every single contributor a bottleneck.
Every product change was instanced as a single cohesive submission, which slowed iteration, publishing, and updates. Modern AAA games are made by enormous teams: Halo Infinite had around 1,000 people, Red Dead Redemption 2 over 2,000. Only a fraction of them touch the publishing portal, but that's still dozens of contributors per title, working on different parts of a shipping game, and the submission model forced them to coordinate at points in the development cycle where coordination bought nothing of value.
Dozens of interviews, then several hypotheses.
I built the picture through observation, consultant research, forum and support feedback, and interviews with developers of all sizes, plus first and third party dev liaisons. I didn’t have access to dedicated researchers, but you can’t throw a stone in Redmond without someone in the games industry (not that you should be blindly throwing rocks). Then I wrote hypotheses, ideas with a measurable result, and most of them pointed the same place: Dev Center's problems reached far beyond the UI layer. Fixing this meant re-architecting the underlying systems.
The strategy: focus first on AAA game developers, a fairly complicated set of scenarios, then scale down for simpler use cases. In some initiative, this might seem backwards, but the business need to satisfy its most prosperous developers meant going for the big fish first. But above all, we needed to fit into the developers’ workflows instead of forcing them into Microsoft's org structure.
The big idea: flatten the submission.
Instead of one monolithic submission, contributors fork configuration at the feature level and work independently, which also saved us from our hub-and-spoke navigation nightmare: developers go directly to the area they want to work on. Late-binding publishing means teams work on their own pieces up until the first retail publish (often months or years in), publish that first version collectively, then update flexibly forever after. Floating drafts let publishers plan releases, sales, and promotions in advance, and a product can be serviced in retail while content updates are iterated on separately, without the two versions touching each other.
A very early wireframe prototype. In hindsight, kind of surprising I got buy in. 😅 Click through the PDF prototype yourself.
The “floating drafts” concept. Drafts could be published independently, encouraging iteration.
Design-driven projects weren't especially common at Microsoft.
At the time, and especially in the developer, partner, and B2B spaces, design led projects were uncommon. Most initiatives were driven by engineering-centric program managers with an MVP mindset, which rarely yields strategic overhauls in favor of shipping something (anything) in a given half-year cycled. Asking engineering to commit to a rebuild that could take two years was ambitious. I synthesized the research, mocked up flows showing the new approach, explained what outcome-driven design is, and presented to Dev Center product and engineering leadership. To my pleasant surprise, within weeks they assigned a PM to drive it full time. Together we stress-tested the thinking against the edge cases of the games industry, and named it Project Jaguar (fast car = fast iteration).
Refusing to ship the org chart.
Microsoft often releases products with engineering seams clearly visible to the end user. Through a close partnership with the Xbox Live PMs and engineers, we committed to not letting that happen. Xbox Live had been my favorite feature area, but I handed the bulk of that work to a designer on my team, and she and I collaborated on the most complicated AAA scenarios: designs that scaled to the edge cases without designing around them. The team’s partnership ran on an improv sensibility, a "yes, and" approach to each other's ideas, building meaningful trust, and it produced the most fruitful collaboration of my career.
Games are often made by hundreds of people. A centralized edit history is essential for not stepping on each other's work.
Vetted by the people who would live in it.
Throughout, I tested designs with game and app developers, developer account managers, and partner engineering teams. The v1 designs were shown at Xbox Developer Fest in the UK and US and at the Microsoft BUILD conference. Honestly, and this sounds made up, but a developer from Ubisoft told me, "We're going to pop a bottle of champagne at the studio when it launches!" I don't know if that reflects a good design, how poor many developer-centric experiences are, or how much they like drinking Champagne at that office. Maybe a combination of the three.
Solving the problem and solving for scale.
Simple updates went from taking days to minutes. What once required coordination across multiple stakeholders and disciplines became something one contributor does on their own.
The holdout studios migrated. Partners who had refused to leave the legacy Xbox portal finally moved.
Retail updates certified faster. Teams tested more often, which led to better and quicker certification of retail updates.
The coordination bottleneck disappeared, visible in the frequency of independent module publishes.
The framework became the standard. 10+ product types are configured and published through it in Microsoft Partner Center: games, apps, avatar items, Office add-ins, SaaS offerings, and more. It's also the basis for navigation in non-product areas of the partner portal, and it fed directly into the canonical workflows and UX certification standards my team built later when I led design for Partner Center.
Partners: Arisa Conwell, Rajesh Korada, Gersh Payzer, Greg Gonyea, Justin Wald | Video: Carlos Go-niji Loera Orozco
Post script - kind words.
It’s hard to think of this project as anything other than the capstone on that phase of my career. I did some of my best work, grew the most in skills, problem solving, empathy, and effectiveness, and collaborated with some of the most willing and talented folks I’ve ever encountered.
It’s a little self-serving, but I wanted to share this email an engineering lead sent me:
I was reading a transcript of Miyamoto’s 1999 GDC keynote where he talks about what makes a good designer. A bunch of what he says reminds me of qualities that make you a great interaction designer:
“Although I am not an engineer, I have always included in my designs consideration for the technology that will make those designs a reality… I know that when (Nintendo's) game designers and producers make their plans without a sufficient grasp of the technology and engineering necessary to make their game, they will often fail.
…we had designers who were painters, but could not understand the technology behind the games. They didn't know what they could and could not do. How were they to express their ideas so that they could be understood by programmers and realized by the CPU… in our company, all designers must go through technical training.
Suppose a director presented the following game specification for an action game. "The enemy shall randomly search and react to the character." To randomly search may sound like an appropriate specification, but a programmer cannot program this as it is, and in the latter stages of development, the director won't know what to begin with when trying to bring the game close to its original concept. But what if the specification presented was "The enemy shall change course based on character movement once every 30 game frames, and one in three times it will randomly select to progress in." This should be more easily programmed than the previous example, we will know where to begin modifying, if necessary.”
There are too many designers I work with where it felt like they are only artists. You always learn how the technology works. This understanding is I think what separates you from your peers.
They say there are two types of game designers in this world: (1) the kind who are storytellers, they are utterly dependent on a high level of graphical fidelity otherwise their games are no fun and (2) the designers who are obsessed with creating game systems and rules. I see something similar in the UX discipline. There are true interaction designers who while visually talented don’t need hi-fidelity comps to create great UX. And then there are those who I see produce very few wireframes, but at very high fidelity. These designs always look nice in Photoshop, but never show the different UI states or any edge cases. These designs always lead to poor experiences when translated to code.
I can also see how because of your understanding of how things are implemented, you are able to convey a design to a developer in fewer words, wireframes and almost never need redlines. Many other designers cannot do that. They convey a lot of the wrong information that isn’t useful to a programmer while missing the parts that are important.