I've inherited a legacy software system, and have been tasked with performing usability and system upgrades. While there's nothing bad with the system, from discussions with the users, there are "small" usabilty issues that need to be addressed.

At this stage I'm the lone developer on this system, and apart from testing I don't use the system at all, so its difficult for me to know what issues may exist or are percieved to exist. I'm going to have some time to speak with them all and discuss what they percieve to be good/bad or indifferent about the system.

Since its essentially just me for the time being my time is limit. So I was considering asking them to imagine that I'd only be able to do one change, have them all write privately what they'd want that one change to be, and then helping them rank those, but I'm hoping for other tips as well.

What techniques exist for getting users to explain their wants, needs, and requirements, while also having them rank them by importance or desirability?

  • 4
    This is a knot of two non-trivial academic problems: how to make people truthfully reveal their preferences, and how to compare different people's needs. But for you, on a practical plane, overthinking this is not worth the time. Start from understanding the system in depth, build test suites, then complete at least one bugfix cycle without regressions. If there were any drastic showstoppers, the users or your boss would have told you long ago. Commented Jun 26, 2013 at 6:37

4 Answers 4


Recently, I had the "pleasure" of producing three separate prototype solutions for a problem our company has related to reports and presenting them to my bosses. Each had its share of advantages and disadvantages in terms of development time, performance, scalability (time between start of project and being able to begin producing reports), ability for clients to modify these reports, etc.

My bosses are notoriously known for their inability to make decisions of this nature, so I wasn't expecting wondrous things. So after explaining the advantages and disadvantages of each prototype, I asked which prototype they would have wanted. They were undecided (surprise!). My bosses were not going to commit to a decision without a suggestion from us as to which would be better (aka, you decide and if it fails, it'll get pinned on you).

So I decided to take a different approach: I asked which of these priorities is more important (development time, performance, scalability, etc.). Again, they were somehow able to evade point of my question by saying that all these priorities were important.

Finally, what finally worked was a strategy I adopted in my attempts to play off their inability to choose priorities. I made a table which have priorities on the x-axis and prototypes on the y-axis. For each priority and prototype, I gave it a number value from 1 to 10 based on how "ideal" it is in that respect, 10 obviously being the best (don't make 10 the worst for any particular aspect or you only risk to confuse yourself later).

Once you have this, you pick the strength of one prototype and you pit it against the strength of another prototype. So in other words, you begin forming questions like: "Which is more important? Development time or performance?" "Which is more important? Performance or scalability?"

At this point, really stretch these questions to get them an idea of perspective: "Which is more important? We finish in 6 months time or that the client has to wait half as long for reports?" "Which is more important? The client has to wait half as long for reports or that we can begin to produce reports within the end of the week?"

At this point, my bosses could handle making decisions in bite-sized pieces and could give a good indication of which prototype they preferred based on this information.

The inverse works as well, pitting weakness against weakness: "Which is worse? It takes us longer than 6 months time to finish or that the client complains about the time it takes to create a report?"

In your case, we're talking about features, not priorties, but I think the same can apply here. "Which would you prefer? Making it available on iPhone or enhancing performance?" Each question is easy to answer and can give you insight as to which features are more important. In your case, I would assign 1 point for each feature chosen in this way in order to be able to effectively gauge one feature with respect to another.


You might try the Agile / SCRUM approach: create a list of all known work (bugs, enhancements, new features, etc.) Then tell your stakeholders (users, bosses, or whomever) that you're always going to work on the top-most item on the list until it is done. Allow them to order it (and reorder it) as often as they like.

The method of getting them ordered is going to differ based on whether you've got a bunch of end-users vs. project management. If nothing else, issues could be "voted" upon in order to order them.

You will need to make dependencies clear though; i.e. issue A has to be done before we can do issue B, even though they want B and don't care about A.

There are a number of software solutions that can help you with this sort of thing, such as issue trackers (Trac, JIRA, Rally, etc.)


The programmer imagines the users taking the approach that: There is a long list of features that I want and our lone programmer has a finite amount of time, so I need to make sure I maximize the development time by pain-stakingly order my requirements to make sure the most important are completed first.

If this is the case, they'll come out and tell you. You are concerned that you'll randomly choose one feature over another and someone will come back and complain about it. It could happen, so what. Just be open about taking their input and prioritizing things as they see fit. They just need to let you know.

More than likely, they'll put things in groups: high, medium and low/no priority. Give everyone a list of requirements before the meeting and see if you can get them to indicate what is important INDIVIDUALY! You can aggregate the results and share with them at the meeting. Dont let the meeting turn into a G8 summit. Someone will keep going on and on about a text box label.

Remember, the priority may change, so don't spend too much time on it in a meeting. And since you're not a typical user of the app, get someone to use it as early as possible and observe.


I don't know where this originated, but if a customer has multiple bugs/enhancement requests tell them they have a $100 (or equivalent currency). How do they want it spent? Everything towards one issue? Even divided between two? This helps to block the usual response that everything is high priority as well as gives weights to each issue.