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.

I am a UX designer, and my task in a desktop application development is to discover what is the need of the users and how they would want to use it. It's a UX designing job plus customer discovery/understanding job.

Now, the target segments of my customers are professionals (engineers/sales), and being in an Asian country ( south east asia to be exact), even the professionals are not good in expressing what they want and what they need. I have a hard time to get them talking and express their opinion. When I present my prototype in front of them, usually they would not have any opinion at all.

In the end, I feel like I am wasting time preparing prototype since either their feedback is usually lame ( "can you make sure that the text box doesn't overlap with other text box"? Yeah, I know that bug, but it's just a prototype, can we move on to something bigger? Like the overall userflow and how would you use the application?), or worse still, there is no feedback.

The users either don't know how to tell what they need, or they don't even know what they need.

How to get them talking in a fruitful way as far as application development is concerned?

share|improve this question
add comment

4 Answers

up vote 5 down vote accepted

Taking this question as more about how to get feedback on prototypes*, that is quite straight forward - You need to set them tasks so that they are focused on using the prototype to achieve a goal.

This could be things such as "From this screen where would you go to find out information about Red MacGuffin Shoes?" or "From the point of view of a typical user, how would you find the contact number of this company?". Things like that, although you want to cater the tasks specifically to the target audience and site purpose of that particular project. Ask them to vocalize their thought process as they go, and watch how they progress to see if what they say they are trying to do matches their actual actions.

In addition to giving them some tasks to complete, ask them to rate the prototype against some subjective heuristics such as the famous Nielsen ones, although there are many, many usability heuristics out there to use. Obviously which ones you choose to measure would depend on how high-fidelity your prototypes are (you can't get them to evaluate the language used of you've still got Lorem Ipsum everwhere).

*You're sort of coming at things from two directions at once - firstly you say you're having difficulty identifying the requirements, and secondly you say that once you present the prototype then you don't get any useful feedback - well I don't really understand how you got to the prototype stage without having any user requirements identified - what is it you've used to build against?

share|improve this answer
    
Yes, you are indeed right that I come from two directions at once. We build the prototype based on what we think what the user wants/ what the user requires without prior input from them. –  Graviton Jul 16 '13 at 12:22
    
@Graviton That is fine to an extent, it just means the project will take longer (and therefore be more expensive) - it takes more time and effort to correct prototypes based on client feedback than it does to get the requirements pinned-down in the first place. You'll always have to make changes throughout the project though, but it's best to identify them as early as possible. Still, better to make changes to a prototype than to finished and live code! –  JonW Jul 16 '13 at 15:39
add comment

It is known effect of the skilled users can't verbalize their thoughts. From Testing Expert Users by J.Nielsen:

  • Skilled behavior is often automated behavior. When people are unaware of how they think about a certain behavior, they can't verbalize the reasoning behind their actions.
  • Expert users can turn into design critics and bend your ear with their opinions on the product, as opposed to staying in the user role and engaging with the actual features.

At the same time they do their job, so you could gather their needs by:

  • Observing their job
  • Researching their office instructions and manuals
  • Exploring the artifacts using primary-noun technique

Then in user test use scenarios containing their primary tasks and assess their usability metrics.

share|improve this answer
add comment

I think you are asking two separate questions here?

1) understanding what you should be designing

2) Validating those designs with users

Lets start with looking at:

1) If you are designing purely for the end user then great! But there are often other stakeholders involved so make sure you get their input.

Contextual research - Observe the users in their environment, try to understand the key tasks they need to perform. What are the current barriers to completion etc.

Ideas workshop - Get a selection of end users and other stakeholders together and run through a bunch of activities. These could include reviewing competitors offerings, prioritising functionality, card sorting etc. Have a look at game storming: http://www.gogamestorm.com/

2) Validating designs can be done in various ways. User testing - from looking at specific design challenges and running them past users to fully fledged lab based user testing. The important thing to remember is to provide context. What is the problem you are trying to solve? Give the users a real life situation and ask them to use the prototype to solve it.

Heuristic evaluation - You could also perform a heuristic evaluation on the prototype. This should help identify any usability issues with the designs. Heuristics are a set of principles that you review your designs against: http://www.nngroup.com/topic/heuristic-evaluation/

share|improve this answer
add comment

To help identify these tasks that you have been advised to set, may I suggest going back a step and conduct some interviews.

Don't start from zero, go into those meetings knowing as much about the user as possible; I would recommend taking a step back and interviewing to gather up enough feedback that can help illustrate the peoples needs and goals.

With this information you begin outlining a scenario comprising of a number of tasks needed to complete the goals you have identified. You might find this task grid a helpful starting point: http://www.servicedesigntools.org/tools/137

Once you have identified a number of scenarios, arrange another session and prompt the users to complete each task, the structure should ensure a productive session. With this approach in place you should achieve a design loop of prototype, validate, revise.

share|improve this answer
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.