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.

For starting any new project we generally ask questions to elaborate on functional requirements, so what are those questions in the requirement gathering focusing on the UX dimension? Do they vary with domain?

share|improve this question

closed as too broad by JonW Jan 29 at 9:12

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
Could you explain what you mean by 'domain'? –  Stewart Dean Sep 16 '13 at 8:26

3 Answers 3

"Elaborate on functional requirements" is not a good place to start the elicitation. The users don't know their own requirements (even when they think they do), and besides, you should be trying to get the non-functional requirements at the same time.

I am accustomed to work with Ian Alexander's requirements elicitation approach, and it has given good results so far. The UX expert should take part in all the stages, although he is most active in the scenario stage. In all of the others, his job is to act as the users' advocate, and defend their interests because the other discussants (usually engineers and management) often forget to take the user perspective in account when making decisions.

  1. Stakeholders Do not forget to list them all, or you will miss important requirements. The UX designer will need some information about the stakeholders who directly interface with the system, basically he needs to know their background so he can guess at their expectations. He might want to create personas at this stage.
  2. Goals I find it easiest to do them concurrently with the stakeholders who have them. The UX designer will have to keep them in mind, but is unlikely to need information beyond what is already important for getting the FR.
  3. Context, interfaces, scope Here you want to know the "landscape" in which the system will run, both the software landscape and the organisational context. You have to define which functions will be done by your own system, which ones by other systems, and which will stay manual. The UX designer does not have to do much here, but he needs to jump into the discussion if the others discuss solutions which are very hard on the user, e.g. requiring the user to manually enter information into interfacing systems.
  4. Scenarios Here is where you get your tasks defined. The UX specialist should be the one guiding this discussion, as he is usually the person with the best understanding of how the users will interact with the system. After the scenarios are gathered, it is the UX specialist's job to create the "workspaces" - a description of all the data and functions a user will need for completing a task. Later, an architect can create a data model based on this description, and the UX specialist can use it for designing actual screens.

The above can be gathered in the sequence specified above. There are other types of information which are needed in a complete requirements specification, and in my experience, they crop up all the time during the above steps.

  • Qualities and constraints are what most people think of when they hear "non-functional requirement". Just about everything specified in the good old ISO 9126 falls into that category. This includes classic usability metrics, such as "95% of non-trained users should be able to complete task X in less than 3 minutes". I have rarely seen a real-life project which specifies on this level of detail, but if it does, then this is what concerns the UX expert at this stage.

  • Rationale When you make a decision, it is a good idea to document why the decision was made that way. Nothing specific to UX here. Most people don't bother doing it at all, I normally do it for politically controversial decisions, or when a decision is made based on a counterintuitive argument which was discovered accidentally.

  • Definitions A glossary for the project. Software engineers have the unfortunate tendency to understand a concept, think of it in their own terms, then use these terms in all kinds of design documents, and the system ends up with those terms exposed in the user interface. All too often, it happens that these terms are not the ones users are familiar with, and the system is very hard to fathom for them. It is the UX specialist's job to pay attention that the most important domain terms are recorded (and used throughout the project) in the language of the domain, not in the language of the engineers.
  • Measurements Here you define the acceptance criteria for the project. Frequently not elicited at all, but if they are, the UX specialist should of course pay attention to ones concerned with the UI.
  • Priorities The requirements obviously have to be prioritized. The UX expert has about the same role as other specialists here, mainly to not let the most important requirements from the user's point of view be swept under the table.

You asked "what questions should the UX expert ask". As you see, even the definition of what the UX expert has to achieve in each stage is rather long. How do you know what question to ask about each? First, an intelligent person with the right attitude can figure out their own questions once they know what information they need to end up with (yes, it is hard, but it gets better with experience). Second, there are books on requirements engineering, from which the UX expert can learn. In my experience, the combination of Discovering Requirements by Alexander and Beus-Dukic, and User interface design by Lauesen gives you a very solid foundation for creating specifications for a system with good user experience.

share|improve this answer

Who are the users, what do they do, what are they looking to do, why do they do it?

What is the business, what does it do, what is is looking to do?

share|improve this answer

What would determine the success of the project?

E.g. number of users registered or migration timelines to the new service or number of sales in the in the first month from launch.

Figure out the mission of the project then the following: - Who are the users? - Why are they using this service/coming to this site - Why would they leave this service/site - What would make them feel successful/satisfied at the end of their experience with the service/site - What would make them feel unsuccessful/dissatisfied with the service/site. - Does this match up to the project mission.

This and I'm sure a few others will help flesh out the functionality with user experience and your business goals in mind.

share|improve this answer

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