When gathering player feedback, it’s important to have a good method of organization so that you’re not just trying to tackle things in an arbitrary manner. I like to organize points into specific groups — a form of development triage. This could involve categories like “clarity” or “juice” that are descriptive within the rubric but don’t directly tackle the core gameplay loop. Make sure to create these categories in a way so that you don’t indirectly manipulate your priority list. If you place a suggestion like “add some sound effects to this feature” beside of a bug report, the obvious thing needing fixing is the bug report. These quality of life changes are better fit into the “juice” category, whereas important issues like unclear mechanics and bugs can go into “clarity” and “bugs” respectively.
Once that’s done, it’s important to remind yourself of the priorities of these categories, such as clarity being more important than juice; many developers will try to fix their problems by adding more and more features until it’s too late to fix and every feature is half functional and barely understandable. Another category that I occasionally use is “features” but this category can be a curse in many circumstances; as previously mentioned many developers like to jump straight to features over fixing up what they already have. As a result, I try to avoid using it until I feel that the rest of the game is up to par to warrant more content. Adding more features is usually nice, but if you’re adding them over fixing bugs or making improvements in other areas, your game will end up looking like a hobbled mess by the end of development. As a result, I’d say the typical order to work on fixing, at least based on these categories mentioned, is to start by fixing any game-breaking bugs.
After that, focus on improving current features within the “clarity” category. If you believe that everything feels as it should, you can move onto the “juice” category and pump it up a bit. If you feel that your game needs more, you can go ahead and move onto the “features” category. Finally, fix any minor bugs that may be present; the reason this is mentioned last is because changing other parts of the game can introduce more bugs itself, so your work might be in vain if you work on fixing every bug early only to find them back in a different form later.
Important Takeaways: It’s all about organization and tackling things in the right order. Creating categories can accomplish this, but make sure the content within your categories won’t introduce a development bias due to juxtaposition. An example of this would be to have minor visual improvements being beside a critical bug, which may prompt you to push the improvements aside in favor of the bug. Make sure you know the right order to working on your game: Fix any critical bugs, improve current features, make them pop out a bit, add new features if necessary, then fix the minor bugs that are left over from development; don’t bother trying to add more content onto a broken game or a game that plays poorly — you’ll be doing yourself a major disservice.