When you interview stakeholders in order to gather business requirements – do you also document content ideas such as product benefits or ideas for sections on the web site? Do you put them in the same requirement document and how much do you follow those ideas? Do you make some kind of thinning?
You're doing user experience design. It's not called stakeholder experience design for a reason.
So, your primary goal is to grab all those stakeholders who actually have something to do with the system: those who will actually use it. These are the customers, the administrators, the whatever, called together users.
Your customers ain't your users. Usually your customers are people with too much money who employ those people who are actually your users.
Usually there's only one need for your customers: they want the users to behave in a way that brings them more revenue.
The unfortunate thing is that you're employed by your customer, not by your users.
Also, usually the programmers are also stakeholders: some want easy implementation, others want challenge, others want to try out some new technologies.
Your priority is simple at first: make users have the best experience possible.
Last priority: eliminate everything which the users won't use. So, if the customer insists that (s)he wants to have his/her puppy on every single keyscreen on a website which has nothing to do with puppies, you can easily dismiss it. I'm not saying you shouldn't do it if it's their mania, but it's your last priority.
Middle ground: whenever there's a contradiction between users and the customers, choose a solution which brings the least pain for the users and the most revenue for the customer. The order is important: least pain first. You're, again, a User Experience designer.
You can draw a simple chart where you say:
As a user experience designer, your job is to create low-pain solutions to users, but as an employee of the customer, you have to bring revenue. Your priority is about the users - the profession which concentrates on revenue a bit more is called "marketing"
If there's a problem of cost, again, you should aim for the best user experience within the available resources. Resources include cost, technology, time and so on. As an employee, you have to stay within budget, and as a fellow employee, you shouldn't make too much trouble for the developers. However, you should push this to reasonable limits: your job is about user experience, so as long as the developers are still happy with their job, try to ask them to do what benefits the users, but let them have their creative playground sometimes.
If there's a problem within different user groups, paying users come first: while you shouldn't make a nightmare out of the job of customer service, customers (of the product) are keeping the company alive. So if it takes 10 minutes more every morning for the customer service to look at a given feature which makes life of paying users of the software easier, they won't die in it. However, if you can stick in a feature to have less pain for the service clerk, do it: the customer service clerk is still your user.
Your dimensions are the following:
- external users who are keeping the company alive
- internal users who are keeping the product running
- developers and other stakeholders which make the product available
- customers who are paying for you and for everyone else in the previous two groups
Your priorities are similar. As a User Experience Designer, you should focus on the first two groups more than the last two. Whenever there's a clash of interests, you try to bring minimal loss to the lower-priority partner while having the best for the higher-priority one.
That said, of course it's a hard balance and it has to be decided case-by-case.
By stakeholder, I assume that you mean the client/product manager because in my opinion, even the dev team is also a stakeholder. Anyhow, it is usually a good idea to keep requirements (the 'what' part) separate with the implementation details (the 'how' part). Sometimes the client/business analysts think that they know the best way how a system should be developed but actually it is not correct. I think you can document content ideas but keep them out of the business requirements.
First, I think this questions belongs more to a site like Programmers.
At my job we put all bugs and suggestions into the same list. Its then up to the product manager and the developer team to evaluate it.
We give it a description including both What and Why, in viewpoint of the user scenario. Technical details go into a notes section.
We encourage anyone including users to report feature suggestions. They should get documented to understand the needs of the user, not to dictate the details of how to get there. The suggestion evaluation process takes place in the development team, and it is basically up to the developers to decide how to implement it.
And don't forget Ford: "If I would ask what my customers wanted, they would say a faster horse."