A dashboard that adapts to you
Windows Dev Home provides a centralized hub for developers to manage their workflows, tools, and resources. The project involved collaboration across the Windows and Xbox orgs.
Role: Product design lead
Goals
Work with the Windows team to launch a game developer extension for Dev Home in the Windows Store.
On top of that, I had a couple of design-focused goals that I wanted to accomplish too:
- I wanted to create a series of principles we could use to build similar future products
- I wanted to leverage widgets to unify our game creation products
Challenges
Early on, the technical decision was made to integrate with Windows instead of building our own product. There were obvious benefits to this, but one of the big pitfalls ended up coming true: Flexibility and speed. There was less flexibility in what we could build and Windows, as a platform that reaches millions of peoples on a different scale than we were used to, moved much slower than we did.
We ended up having to shoehorn design solutions into existing systems.
From the start, there wasn’t much thought into how this product would make money. In hindsight, it’s something I wish I had thought more about. I did a few explorations around premium product offerings but didn’t go deep enough. In all fairness, it wasn’t a major goal for the product.
As a whole, the project ran smoothly, the vision I was designing kept bumping up against the technical limitations.
How I worked
Being new to the space, I started with research. I had a meeting series with our researcher to figure out what kind of data we needed and how we would gather it. The kind of data ended up needing was about the different ways game creators at studios of different sizes could leverage a platform like this to speed up the creation, and maintenance of their game builds. Could game studio project managers and leadership use it get a birds-eye view of what was going on with their game at different stages in the games’ lifecycle? Things like that. So our research spun up a survey with indie creators, small studios and large AAA studios. We came to find that it would be useful to be able to spin up environments and be a one-stop-shop for documentation as you’re building a game.
I got started writing out some of those scenarios and designing against them.
In addition, I also wanted to address those design goals. So I started exploring the widget space before I knew if it was even technically possible to build. I started by gathering a handful of example apps from our ecosystem to see how they displayed information and what information was being shown. And how different apps often showed some of the same data. I also became a voracious reader of Microsoft documentation to understand what the writers thought people needed to know the most. I took all that and started designing out some different examples of what these large, complex apps could look like if they were shrunk down into a tiny widget.
As much as they tried, I found out that the widgets could only be build with a specific library (WPF) that drastically limited the functionality. There was really no way of knowing that we ultimately wouldn’t be able to build as freely as I had explored. But some good came from this -- it led to another project that helped me define how I wanted the creator space to look and feel. The principles also helped me figure out what data from these disparate products was most important for the creator and what needed to bubble up to the top.
Outcome (more below)
We were able to launch an game development extension that housed a handful of different widgets that did, in fact, speed up developers workflows. For instance, we built a launcher for game files and software installed on your computer, which the Windows team extended to build Command Palette. We also launched a sandbox switcher, that was received well, based on our initial research.
But as it turns out, we should have built our own product from the beginning. We were just too limited technically, to make the kind of impact we envisioned for our creators. And the business winds of change hit us pretty hard and broke up the Windows team who went on to work on more AI-focused features for developers.
What’s next
This project was sunset in May 2025. The product, however, lives on in several different forms. We were able to take the ability to install a custom suite of software and move that to another tool that helps you set up your development machine in addition to the other launcher workflows that the Windows team extended. All things considered, I’m pretty happy with what we were able to put in front of customers but I would have hoped we got closer to our vision.
Created with beta software, there may be some bugs
A dashboard that adapts to you
Windows Dev Home provides a centralized hub for developers to manage their workflows, tools, and resources. The project involved collaboration across the Windows and Xbox orgs.
Role: Product design lead
Goals
Work with the Windows team to launch a game developer extension for Dev Home in the Windows Store.
On top of that, I had a couple of design-focused goals that I wanted to accomplish too:
- I wanted to create a series of principles we could use to build similar future products
- I wanted to leverage widgets to unify our game creation products
Challenges
Early on, the technical decision was made to integrate with Windows instead of building our own product. There were obvious benefits to this, but one of the big pitfalls ended up coming true: Flexibility and speed. There was less flexibility in what we could build and Windows, as a platform that reaches millions of peoples on a different scale than we were used to, moved much slower than we did.
We ended up having to shoehorn design solutions into existing systems.
From the start, there wasn’t much thought into how this product would make money. In hindsight, it’s something I wish I had thought more about. I did a few explorations around premium product offerings but didn’t go deep enough. In all fairness, it wasn’t a major goal for the product.
As a whole, the project ran smoothly, the vision I was designing kept bumping up against the technical limitations.
How I worked
Being new to the space, I started with research. I had a meeting series with our researcher to figure out what kind of data we needed and how we would gather it. The kind of data ended up needing was about the different ways game creators at studios of different sizes could leverage a platform like this to speed up the creation, and maintenance of their game builds. Could game studio project managers and leadership use it get a birds-eye view of what was going on with their game at different stages in the games’ lifecycle? Things like that. So our research spun up a survey with indie creators, small studios and large AAA studios. We came to find that it would be useful to be able to spin up environments and be a one-stop-shop for documentation as you’re building a game.
I got started writing out some of those scenarios and designing against them.
In addition, I also wanted to address those design goals. So I started exploring the widget space before I knew if it was even technically possible to build. I started by gathering a handful of example apps from our ecosystem to see how they displayed information and what information was being shown. And how different apps often showed some of the same data. I also became a voracious reader of Microsoft documentation to understand what the writers thought people needed to know the most. I took all that and started designing out some different examples of what these large, complex apps could look like if they were shrunk down into a tiny widget.
As much as they tried, I found out that the widgets could only be build with a specific library (WPF) that drastically limited the functionality. There was really no way of knowing that we ultimately wouldn’t be able to build as freely as I had explored. But some good came from this -- it led to another project that helped me define how I wanted the creator space to look and feel. The principles also helped me figure out what data from these disparate products was most important for the creator and what needed to bubble up to the top.
Outcome (more below)
We were able to launch an game development extension that housed a handful of different widgets that did, in fact, speed up developers workflows. For instance, we built a launcher for game files and software installed on your computer, which the Windows team extended to build Command Palette. We also launched a sandbox switcher, that was received well, based on our initial research.
But as it turns out, we should have built our own product from the beginning. We were just too limited technically, to make the kind of impact we envisioned for our creators. And the business winds of change hit us pretty hard and broke up the Windows team who went on to work on more AI-focused features for developers.
What’s next
This project was sunset in May 2025. The product, however, lives on in several different forms. We were able to take the ability to install a custom suite of software and move that to another tool that helps you set up your development machine in addition to the other launcher workflows that the Windows team extended. All things considered, I’m pretty happy with what we were able to put in front of customers but I would have hoped we got closer to our vision.
Created with beta software, there may be some bugs