I talk about how many gamers don't seem to know what they like, only what they don't like.Videos I reference:Giving Good Feedback: https://www.youtube.com/wa...
In my experience as a software developer (not games) for nearly 20 years, I’ve gotten the strong impression that most people really don’t know what they want until they have it. My ideal client (i.e. person who intends to use the software I’m about to write) for a new project would have a clear idea about what they’re trying to accomplish, and what problem(s) they’re trying to solve. In my entire career, I believe I could count the number of times I’ve encountered such a client on one hand. In the overwhelming majority of cases, the client has a vague notion of automating some things that currently take them longer than they’d like, and initially provide very few details about the actual problems and goals. The result ends up being a series of updates, with feedback between, until the client is finally satisfied. Interestingly enough, it isn’t that these people are in any way stupid, or that they simply never bothered thinking about it. Rather, it seems to be because they’re a little overwhelmed (the reason they came to me in the first place), and focused more on relieving the burden than on what kind of solution might accomplish said relieving. This isn’t unreasonable; it just happens not to be particularly helpful.
All of that said, I do believe there is a lot of merit to providing feedback that focuses on what we want, rather than what we don’t, largely because, in my experience, people tend to have more specific ideas when thinking about what they’d like. When thinking about what they dislike, many people will naturally focus on their own emotional reactions to things, rather than how said emotions were actually triggered. When thinking about what they want, there’s still a focus on the emotions one wishes to experience, but most people tend to imagine something that will trigger those positive emotions, and state that, rather than talking about the feelings themselves, resulting in higher specificity.
I’m lucky to work in an org with a product team that does a fantastic job of detailing the problems they want to solve and an idea of the workflow a user should take. They discuss that w/ our design team and architect, who basically come to a conclusion about how the problems get solved in a way that works well for both users and developers.
If you ask our customers, they’ll say they want A and B (in many cases charts and graphs), when neither would solve the actual problems they have (e.g. optimizing cost), and what they need instead is to provide a little more data (i.e. their upstream and downstream costs) so we can produce better recommendations (i.e. reduce X and increase Y to get similar results for less cost). We’re really good at simulating things, our customers are really bad at it, yet customers ask for features that let them try to simulate things instead of us providing that value.
That goes double for games, since people are a lot more emotionally invested in games that workplace software. If the player is complaining about “bad controls,” the solution may be some kind of indicator of off-screen enemies (i.e. improve time to react), which has nothing to do with the controls themselves.
In my experience as a software developer (not games) for nearly 20 years, I’ve gotten the strong impression that most people really don’t know what they want until they have it. My ideal client (i.e. person who intends to use the software I’m about to write) for a new project would have a clear idea about what they’re trying to accomplish, and what problem(s) they’re trying to solve. In my entire career, I believe I could count the number of times I’ve encountered such a client on one hand. In the overwhelming majority of cases, the client has a vague notion of automating some things that currently take them longer than they’d like, and initially provide very few details about the actual problems and goals. The result ends up being a series of updates, with feedback between, until the client is finally satisfied. Interestingly enough, it isn’t that these people are in any way stupid, or that they simply never bothered thinking about it. Rather, it seems to be because they’re a little overwhelmed (the reason they came to me in the first place), and focused more on relieving the burden than on what kind of solution might accomplish said relieving. This isn’t unreasonable; it just happens not to be particularly helpful.
All of that said, I do believe there is a lot of merit to providing feedback that focuses on what we want, rather than what we don’t, largely because, in my experience, people tend to have more specific ideas when thinking about what they’d like. When thinking about what they dislike, many people will naturally focus on their own emotional reactions to things, rather than how said emotions were actually triggered. When thinking about what they want, there’s still a focus on the emotions one wishes to experience, but most people tend to imagine something that will trigger those positive emotions, and state that, rather than talking about the feelings themselves, resulting in higher specificity.
Lots of good points here.
I’m lucky to work in an org with a product team that does a fantastic job of detailing the problems they want to solve and an idea of the workflow a user should take. They discuss that w/ our design team and architect, who basically come to a conclusion about how the problems get solved in a way that works well for both users and developers.
If you ask our customers, they’ll say they want A and B (in many cases charts and graphs), when neither would solve the actual problems they have (e.g. optimizing cost), and what they need instead is to provide a little more data (i.e. their upstream and downstream costs) so we can produce better recommendations (i.e. reduce X and increase Y to get similar results for less cost). We’re really good at simulating things, our customers are really bad at it, yet customers ask for features that let them try to simulate things instead of us providing that value.
That goes double for games, since people are a lot more emotionally invested in games that workplace software. If the player is complaining about “bad controls,” the solution may be some kind of indicator of off-screen enemies (i.e. improve time to react), which has nothing to do with the controls themselves.