Question
What does a good feature request look like (from a non-technical employee)?
Answer
Short answer: users (as opposed to product managers) should not attempt to provide "good" feature requests at all. They should submit feature requests in whatever form feels right to them. Including huge, toxic rants or complete idealized mockups showing how they would have designed the system if they so choose. It is all data.
While Kevin Peterson's advice about sticking to the user-story level of abstraction is a useful design principle, it gets complicated. Even in his own example "is presented with a list of campaigns" suggests a specific presentation format (a "list" rather than a "slide show" or "tab set").
Sometimes it is just easier to have the user describe how they want things to work rather than trying too hard artificially to stick to the what. In fact, I recommend going as far as encouraging users to submit feature requests as quick sketches/mock-ups if they like. This does not mean you are delegating design to them. It just means their amateur design effort is data for the real designer. As a bonus, sometimes you might actually get good design ideas this way.
This is the UX equivalent of a judo: use the momentum of the user's inclination to overspecify rather than stopping it. The discipline to stop at user stories is a key behavior for product managers or product marketing managers who must work with UX designers everyday (and the discipline is more about managing effectively and respecting the autonomy of different team members in their areas). Users should be encouraged to submit ideas in forms that seem natural to them, even if it makes life a bit harder for the designers.
It is actually part of the job of usability/UX people to take such locked-in, preconceived notions about how a feature ought to work, back out the the implicit logic and come up with either a refinement of the suggestion or an alternative that the suggester did not think of that is even more intuitive. Users tend to have a certain amount of functional fixedness: a thought pattern that involves two complementary beliefs "this is how I use a hammer/a hammer is how I do this."
UX people need to be skilled at separating the such functionally-fixed suggestions into what is actually desired (intent) and how the user intuitively thinks about achieving that intent (the existing functionally fixed pattern).
Conscious design, which comes next, involves deciding whether to build on the user's existing learned pattern (that's what functional fixedness is, a symptom of a learned pattern) or to attempt to build a new pattern or build off a different learned pattern.
Many usability research techniques actually systematize this sort of thing I believe, like having focus group users create their own paper mockups etc.
While Kevin Peterson's advice about sticking to the user-story level of abstraction is a useful design principle, it gets complicated. Even in his own example "is presented with a list of campaigns" suggests a specific presentation format (a "list" rather than a "slide show" or "tab set").
Sometimes it is just easier to have the user describe how they want things to work rather than trying too hard artificially to stick to the what. In fact, I recommend going as far as encouraging users to submit feature requests as quick sketches/mock-ups if they like. This does not mean you are delegating design to them. It just means their amateur design effort is data for the real designer. As a bonus, sometimes you might actually get good design ideas this way.
This is the UX equivalent of a judo: use the momentum of the user's inclination to overspecify rather than stopping it. The discipline to stop at user stories is a key behavior for product managers or product marketing managers who must work with UX designers everyday (and the discipline is more about managing effectively and respecting the autonomy of different team members in their areas). Users should be encouraged to submit ideas in forms that seem natural to them, even if it makes life a bit harder for the designers.
It is actually part of the job of usability/UX people to take such locked-in, preconceived notions about how a feature ought to work, back out the the implicit logic and come up with either a refinement of the suggestion or an alternative that the suggester did not think of that is even more intuitive. Users tend to have a certain amount of functional fixedness: a thought pattern that involves two complementary beliefs "this is how I use a hammer/a hammer is how I do this."
UX people need to be skilled at separating the such functionally-fixed suggestions into what is actually desired (intent) and how the user intuitively thinks about achieving that intent (the existing functionally fixed pattern).
Conscious design, which comes next, involves deciding whether to build on the user's existing learned pattern (that's what functional fixedness is, a symptom of a learned pattern) or to attempt to build a new pattern or build off a different learned pattern.
Many usability research techniques actually systematize this sort of thing I believe, like having focus group users create their own paper mockups etc.