Notes of the Tool Design Roundtables at GDC 2025
This year we had 3 Tool Design roundtables. Day 1 was focused on Design and UX, day 2 was focused on Production & Strategy, and day 3 was focused on User Research.
For those who have never attended a roundtable: This is a room filled with mostly game developers, from both big studios and indie studios, as well as non-game developers from manufacturers, software houses, and service providers. The folks in the room ask questions, and then anyone in the room can raise their hand to answer those questions. This information is unfiltered, and not directly from me, written down after the fact from memory and some shorthand notes, so always take it with a grain of salt. Your own situation may vary.
The topics discussed at day 1 were:
What is the best tool UX thing that happened to you this year?
What is the worst tool UX thing that happened to you this year?
How do I transition from UI/UX to Tools UX Design?
Who has a dedicated Tools UX person on staff, and what is their daily work?
How do you do more with less, and how do you find out what to do?
How to iterate, to avoid the vocal minority, work with satellite studios, and get feedback.
What tools do you work on?
1. What is the best tool UX thing that happened to you this year?
I always open the Tool Design Roundtables with these two questions to get everyone warmed up, and for folks to share their stories.
Some good things that happened to folks this year was: Wizards and AI agents improved some folks’ workflow by making it constrained enough that less issues were popping up. Users can only select from a set amount of options in those workflows, which meant they could not go off-track as much, so it prevented issues where users have to fully do the work themselves. So users may be able to ask an agent anything, but it will restrain to only certain outputs that are vetted for accuracy.
Someone mentioned they had complained a lot, way more than usual, and that this helped tool developers hone in more on what the users actually needed. Complaining can be good! In some cases a particular complaint can upturn all the other feedback you had, and put you on the right track to find the real core of the problem. Don’t forget to communicate your issues!
2. What is the worst tool UX thing that happened to you this year?
Appreciation was hard to find. Once a tool was fixed, the tool engineers did not hear back about whether folks liked it. This is a classic issue I have seen at many companies, where the tools are essentially thrown over a fence to the users, and nobody hears back about what folks liked, disliked, or want changed, until some Jira tickets fall in their inbox. This may make it seem as if users only ever want changes, which isn’t the case, as they love tools as well, but you don’t usually get that via a Jira ticket.
Once a tool gets out there, and folks like using it, get some reactions and tell the tools team about it. I used to do this when I worked at Io-Interactive as a Tool UX Designer on Glacier: I would go around, get live comments from users who had used the new tools, and in whatever next meeting we had I would literally tell the tools team those quotes directly. It really helped morale!
3. How do I transition from UI/UX to Tools UX Design?
Someone in the room was a UI/UX designer, and they were wondering how they could transition into being a Tool UX Designer, and what kind of work a Tool UX Designer does.
Some things the room brought up are:
Communicate early. Be very early on in the customer pipeline so that you directly hear what is wrong, and can facilitate that communication between users and engineers. Filter out what isn’t relevant and amplify what is relevant, so you can give the tools team what they really need to know, and save them time.
If you want to start doing the job: Do it! Internally at your company the customer is right there! Sit behind people and see how they work. Find out what work they do, and why. Write down issues they are having. Then you can start finding solutions to overarching problems, and save the tool engineers time.
Have direct involvement in the tool. Make a prototype in Figma, design things together with users, and really involve yourself. Use the tools yourself, find the issues users are dealing with. The best way to get started is by getting involved as much as possible, as early as possible.
4. Who has a dedicated Tools UX person on staff, and what is their daily work?
Only a few hands up when this question was asked. It was about 10% of the room. Which may seem like very little, but that is already a huge raise from back in 2015 when barely anybody had heard about this as a job!
One thing folks raised to get a Tool UX Designer on staff is to steal UX folks from elsewhere in the company. Get those UX folks to do some tool design work now and then, while trying to hire a full time tool UX designer to fill that position permanently.
What was also mentioned as very useful was for the tool designer to start making libraries of components in Figma so that the tool engineers no longer have to worry about what a window looks like, what a button looks like, where it should be placed, etc. Even basics like this can save a lot of time for the engineers. Taking efforts out of their hands is generally useful and valuable for a full-time Tool UX Designer to do.
A tech background helps in this role, as it makes the conversations with engineers easier. It can never truly be a programmer as doing UX design is a full time job that allows for no programming on the side, but a background in techy things can help.
Someone also mentioned they had a Tool UX Designer that works directly with tech artists and is in the full loop of creation with them, so from initial request, to design, and then sitting with tech artists as they build the tooling and helping with the designs & workflows on those.
Also, someone mentioned that a Tool Designers’ work is not just visual. It is the user experience they take care of, so the visual part is only a small part of that effort. It is important in their work that the user experience works well, so they have the time to sit down with users, see their workflows, really understand what is going on, and then design workflow solutions, not just UI. A big part of that workflow is understanding what is, and isn’t important to users, so that you can skip building tooling that will eventually not get used anyway. That is a big part of the Tool Designer’s strength: To make sure users, and programmers, don’t have to waste their time, because the Tool Designer can find out what is really going on, and what really needs to get fixed, so that they can spend their time wisely.
5. How do you do more with less, and how do you find out what to do?
Learn from other tools! Keep looking at what other tools are doing, how, and why. Use those other tools, and understand their workflows so you can see what does and does not work well. This can save you a lot of time and prevents you from re-treading old ground when you do not have a lot of time.
If you have very little time, another thing you can do is ignore requests. Someone mentioned this as “They will forget about it if it’s not as important.”. So if an issue gets raised multiple times, you know it’s important to work on, but if after the first request it is forgotten about then it may not have been important. Giving requests a ‘cooldown period’, where in a few weeks you check up on it, was helpful for someone. It often meant the original requester would say “Oh, that’s not important anymore actually.” and so they could close the ticket without having to do the work.
Another technique brought up was having Slack automation for submitting tasks. To make it so easy and simple for folks to submit issues so that it becomes much easier to see what needs to be done, as everyone is more likely to submit issues.
Being frugal with time is also possible by combining requests. There may be 10 issues that can be solved, or at least solved 80% of the way, with one new tool or change. If you have few resources, it’s important to have someone like a Tool Designer on staff who can look through all the requests, understand all the workflows, and then see what the biggest bang for buck is.
In combination with the earlier point of having a cooldown period on requests, it also pays to check in on whether a request is still relevant. Sometimes a ticket has laid dormant for months, and so it is helpful to go back to the original requester and check with them on whether the issue is still relevant, or whether it can be closed as no longer needed. Sometimes old tickets are still super important, so always check!
6. How to iterate, to avoid the vocal minority, work with satellite studios, and get feedback.
Gamifying via a high score list can be helpful to avoid the vocal minority. Basically: Make sure everyone has some votes that they can give to open issues, and see what the majority thinks is important. This also has the added benefit of showing everyone else what their colleagues think is important, which gives levity on their own issues. They may see that their own issue is not as important in the face of all the other things that folks find important.
Catching conversations on Slack is also very helpful when working with satellite studios. If they are on different timezones, or far away, you want to make sure you keep an eye on their Slack conversations so you can see what they are discussing, and why. Then from there you can find out what the big issues are, either on the surface or even below. This helps avoid vocal minorities too, as you can see how many folks interact with specific issues that come up.
Someone brought up that you can also almost annoy folks by asking about their request, to iterate and get feedback on the request: Keep asking what the problem is, essentially keep asking ‘Why?’ until you dig down into what the really important issues are.
If folks are remote, it is also important to screenrecord. Especially if they are on different timezones. Users can record their workflows, and then you can go through them at 2x or even 10x speed to see how they work, what tools they use, and what workflows they often go through. You can slow down to see specifics when necessary, but even a timelapse recording gives you a great amount of information to work with.
Some folks also mentioned the great talk that Laura Taylor gave at GDC 2019, in which she talks about a spreadsheet to track what tools folks are using, and give clear indication of what tools are the most important to work on. Tracking data such as that again allows you to avoid the vocal minority, and give you better space to iterate on what is most helpful to folks.
Doing workshops and team meetings to walk through tools together with those who use them, gives you a great live platform to gather feedback from. Especially because it is a team meeting, you are not just talking with one person, but you can see the discussion that starts between the same folks using the same tool, all with different thoughts on how it works. Using tools together gives you a lot of feedback to chew on.
7. What tools do you work on?
Everything. Tool Designers work on all kinds of tools. Material editors, asset browsers, publishing tools, narrative tools, cinematic tools, anything that interfaces with tech. There is no limitation, and in my opinion there should be no limitation. If you do not know how a tool or workflow works, just ask. There is always more to learn out there, and the best way to help folks is to ask ‘stupid’ questions about their workflows.
The board of Day 1
Day 2
The topics discussed at day 2 were:
What is the best tool UX thing that happened to you this year?
What is the worst tool UX thing that happened to you this year?
How do you iterate with fast growing satellite and third party studios?
How do you slow down?
What is your prioritization organization?
How do you inform users?
How do you brace users for change, and how do you promise them good things that make them want to use the tools you are building? And how do you ‘Hire’ users? How do you get them to use your tools?
How do you educate users so they log bugs, and how do you help QA teams?
1. What is the best tool UX thing that happened to you this year?
Getting tools to users fast! Making sure that whenever updates or new tools happened, that there was a pipeline to get that to users quickly. This made the users happier, and also made sure they got feedback quickly.
2. What is the worst tool UX thing that happened to you this year?
Forgetting to factor in testing time. Tools would be built, and then immediately sent out to users without them getting tested. This made many issues appear to users right away, which could have been caught in testing. With testing not scheduled into the timeline there was never time for it. They mentioned they should have scheduled more time for testing, right at the start when the feature or tool is planned.
3. How do you iterate in satellite and third party studios? Especially if they are growing fast?
Some of the things discussed in Day 1 also apply here: Let remote folks record their workflows so you can take a look at them, and look at Slack to stay in communication.
If there is a lot of growth, then allow users to try things fast. A way of doing this is by having some kind of frontend that allows folks to quickly get latest for specific features or tools, or letting users try software on the engineers’ machine. When there is a lot of movement, it is important you can quickly move too.
Start early. Get into the workflows as early as possible, so that you can understand what is going on before many other folks are hired and stay on top of what is necessary, where, and why. You want to see how the workflows grow and change, and the needs grow and change.
Also, it is very important to visualize the backlog. Give everyone visibility on what is planned, why, and when. Especially between different studios, and when making tools to ship to many folks, it is important to let them know what the future will look like. This will noy only soothe them so they know what to expect, but can also help to make sure you get feedback that is relevant to what is being worked on.
4. How do you slow down? How do you make sure you aren’t just constantly building things from fire to fire?
You have to say ‘No’. This can be politically very difficult to do, but at some point you have to say ‘No’ and slow down development. Someone also mentioned a really great rubric to start with: Ask why, why now, so, and so what?
Why?
Why does this need to be done, and for who is it for? Do we know what the scope of the request, issue, feature, or tool is?
Why now?
Why does it have to be done right now? What is the reason behind moving other things out of the way to do this?
So?
What if we do not do this? What would happen? Do we know the consequences of inaction?
So what?
Are those consequences really that important? Are they really that bad? Do we really have to care about this right now?
So build clarity on the ‘No’. Why is it a no, for what reason, and what are the consequences? Once you have this, it will be easier to slow down. Sometimes the ‘So’ can mean you will get fired, in which case the problem is more that you are in a company that is constantly on fire, which isn’t a great position to be in, but at least you will have clarity on your situation.
5. What is your prioritization organization?
Having a visible priority screen is very useful, as also mentioned earlier in Day 2, and also in Day 1. This can be done as a high score list, in Jira with a specific custom visualization, or physically. Let folks see what the prioritization is, so they understand what is going on within the tools team.
Some kind of physical visualization was mentioned as a particularly nice way of doing this, such as with post-its or an actual whiteboard. A physical place where folks can go to to see what is going on, and ask questions if they have any.
6. How do you inform users? About changes, updates, anything?
This is a topic that comes up pretty much every year, and some of it we also saw in Day 1: Team meetings and workshops are great for telling users about changes and updates. Also, I personally always recommend short gifs and videos. If you send those via email, everyone in the company gets to know what has been changed or updated with a 10 second gif. A short visualization like this is much better than just sending them a link to documentation, as barely anyone will ever read documentation. Engineers read documentation, but artists and designers rarely do.
7. How do you brace users for change, and how do you promise them good things that make them want to use the tools you are building? And how do you ‘Hire’ users? How do you get them to use your tools?
This is a conglomeration of questions, and it’s a combination of issues that create such a question. We get it often in the Tool Roundtables, and someone immediately piped up with the answer they give every year: Create champions in the teams.
Some other folks call those folks a ‘Spy’, but I think ‘Champion’ is a bit nicer to word it. When you start building tools, grab someone and let them try out the tool before it is released to everyone else. Make this someone who understands the workflows well, and often talks to others in their team. Let them give feedback, and make changes to their feedback. Then, when the tool is finally ready and released to others, that person who was initially involved is now a Champion for that tool. They will tell others how awesome that tool is, how much others should use the tool, and what they like about it. This cuts down a lot of the issues of pushing a tool to folks out of nowhere.
Also, sit with users. Literally go to users and sit behind them, and see how they work. Hear what they have to say. Understand what their problem space is. Then you can let them know what changes you are thinking of, let them be a part of the development so they know it’s good and not just promises, and they will want to use the tools. One thing you cannot get around is that the new tool has to actually be an improvement. You cannot give them a new tool and just hope or expect them to jump on it. Do not promise something great and then deliver something with only half the features. This may seem very banal to say, but it happens a lot! How many times have you updated software and been annoyed about features being removed or changed without informing you beforehand?
And also, again, do workshops and dogfooding of the tools. Try them out yourself, try them as a team and as a group. Do not just throw your tools over the fence to the users. Really pay attention to what folks need. Do what users do, and loop back to them so they know that you have really looked into their issues.
And if you really need to ‘hire’ folks for testing, food and candy tend to do the trick.
8. How do you educate users so they log bugs, and how do you help QA teams?
Wizards are a really good way to make users report bugs. If to report a bug they need to go to Jira, find the right location to make a bug report, write down the exact 10 steps they just took, verify a whole bunch of other metadata for bug reporting, and only then they are allowed to report an issue, then you will get very few bug reports. For example, make a single button in your tools from which automatically a bug report gets generated, which includes the last few steps in a log that is automatically attached, and the user only has to describe the issue. That way you are going to get way more actual reports, which the QA team then also has an easier time verifying and looking into.
The whiteboard of day 2
Day 3
The topics discussed at day 3 were:
The best and worst Tool Design thing this year
How do you solicit feedback?
Why are there so little UX researchers?
What are easier feedback systems?
What is your favorite UI system?
How do you gather Qualitative vs Quantitative data?
How do you spy well?
1. The best and worst Tool Design thing this year
Sadly I am lacking notes on what exactly was discussed here, apart from ‘The good & bad are close together’, which I think we also saw in Day 2: Getting new tools to users quickly is great, but if there isn’t any time to test them then it becomes a problem. Or, for example, gathering a lot of data is great, but that then means you have to spend a lot of time and effort into sifting through that data to get the answers you are looking for. So something that is very good for you, can also end up biting you later. Too much of anything is bad, even if it seems fantastic up front. As always, it is important to see if in your case, with your users, in your company, something applies well or not. ‘It depends’ is still the most accurate answer to any question, as goes for anything in these notes.
2. How do you solicit feedback?
Similar to Day 2, a big part of this is to remove feedback barriers. Make it super easy for feedback to be submitted, either inside the tool itself, via Jira, or automated Slack systems. The easier it is for folks to submit feedback, the easier it is to get.
Soliciting feedback is also very different on a person-to-person basis. The book ‘A Culture Map’ is helpful for getting an understanding of what kind of feedback an American might give versus what a Dutch person might give. They could mean the exact same thing, but say something very different. When you are working with large multinational teams, it is important to understand how different folks may give you feedback.
Also, do not just ask positive questions: Don’t ask “Do you want this feature?” or “Do you want this workflow to improve?” as the answer will always be: Yes, sounds great! If you only ever ask questions that can easily be seen as positive, every answer will be positive. This will seem confusing at first, as it will seem like users want polar opposite things. So the better question would be is: Do you want X, or would you want Y, and why? Again this ties into making it very clear what the priorities are, and visualizing that well for the userbase.
3. Why are there so little UX researchers?
Usually because ‘UX researcher’ is not seen as a full time job for one person, but instead something someone else already does. They have a combination of hats on, and user research is one of those hats. This then also restricts hiring, as it feels like the job is already being done by someone. As UXers we know what having a dedicated UX researcher is a fantastic thing that is really helpful, but convincing management to make headcount for this specific role is very difficult except for extremely large companies in which there can be such a dedicated role, or even a team of them. In general, the GRUX holds more user researchers in game development as well, and they usually help not just with tools but general game UX research too.
So it’s not that the role isn’t useful, it’s just hard to get approved in the face of other roles that are easier to directly argue for, or that folks have experience working with.
4. What are easier feedback systems?
Auto-telemetry is fantastic, if you can get it. Getting data on how much a particular button is pressed, how much a particular window is opened, gives you a great idea about what is being used, which then makes it easier for you to elicit feedback from users. You can ask about why they used a certain tool, or if they are avoiding another tool.
A kind of ‘legal bribery’ can also be useful, again with candy or food. Getting folks into a room with candy, so you can then ask them questions, can get you a bunch of feedback. Also, someone mentioned that you can ask folks for feedback, and to then give them features that they want a lot if they keep giving that valuable feedback, so essentially bribing them with features.
Also, do not forget that feedback to the tool creators themselves is very helpful too. So that if you hear ‘Thank you’ from a user of the tool, that you also send this feedback to the tool creators, so that they know their tool is appreciated and liked. Saying thanks can go a long way, as not all feedback has to be about something being bad!
5. What is your favorite UI system?
More of a technical question, but we did a show of hands and IMGUI still wins by a large margin. Most folks like how easy and quick it is to set up tooling with it, even if that tooling may not always be permanent, it is nice to get something out quick and unblock folks before moving on to other work.
6. How do you gather Qualitative vs Quantitative data?
When you do training for new tools that have been released, or workshops, or meetings, make sure to record those. That gives you great qualitative data on what folks like, dislike, and what they want to discuss. You see how they work, and also get the discussion on record.
Also, get the user story of the tool from the user: Ask them what their user story is. They open the tool, and then, and then, and then, etc. Walk through that with a user to get qualitative data on how they think about the tool, how they use it, and how they interpret the tool.
Pair testing is also very useful, similar to pair programming. Instead of one person using a tool, and talking to themselves, have two people use the tool on one computer. That way, when there is a question, they will talk to each other. This gives you great qualitative data as it shows what they want to talk about, what they think, and how they think.
7. How do you spy well?
Data is great, but be careful with the collection of that data. Make sure you do not share the data on how much a person uses the tool, when, and why. A user researcher may know which unique ID is associated with which person, but nobody else should know that. You have to treat it a little bit like Severance: What happens at work stays at work. You also want to make sure everyone knows what is being recorded, and why. You do not want to come to their desk and say “Hey, I saw you press this button a lot.” and hear them say “Wait what, you have been spying on me?!”. Be very clear about what you are collecting, why, and of course be careful of GDPR.
Recordings and sitting behind folks is also always still a great way of gathering data. Look at what users are doing live, or watch a recording of how folks work, and you get a lot of data you otherwise would not have gotten.
The whiteboard of Day 3
Thank you
A big ‘Thank you!’ for everyone that attended the Tool Design Roundtables at GDC 2025. I sincerely appreciate everyone who shared their own stories of both joy and woe as we all strive to create better tools & workflows for everyone.
Subscribe below to get updates when a new post is published.