Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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?

share|improve this question
add comment

3 Answers

up vote 1 down vote accepted

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:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

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.

share|improve this answer
    
Well, you had me at stakeholder experience design. –  Tony Bolero Sep 15 '12 at 14:13
add comment

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.

share|improve this answer
    
Yes, I'm talking about the client and people in the clients organisation that the web site will have an impact on such as the customer service division or the sales division. When I talk to those people about how the web site could help them they usually come up with a lot of content ideas and stuff that the think could be improved such as search. - Can I transform those ideas into business requirements instead? –  Tony Bolero Sep 11 '12 at 11:33
    
Yes, you can but be aware of the project charter and scope. Staff may give you their wish-list of items that they would like to be developed but are those tasks approved or not by the client management (project sponsor). –  Aziz Shaikh Sep 11 '12 at 11:47
add comment

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."

share|improve this answer
    
The problem is that when you mix requirements with implementation details, requirements docs stop saying "Achieve X", and start saying "Achieve X by using button Y in position Z". Then when someone realizes that X can be achieved better in a different way, or that the original idea doesn't actually make sense in practice, the statement of works has to get renegotiated. –  Jimmy Breck-McKye Sep 11 '12 at 18:41
    
I see now I got quite off topic. I'll edit it to try to focus on the question. –  JOG Sep 11 '12 at 20:50
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.