Has any of you had experiences where you are trying to design for a very specific user group, but had a hard time conducting any kind of user research because the users are not willing to participate? How do you overcome this problem?

I am designing a business application for a very small and very specific industry where our users are in the process of converting from classic pen-and-paper to technology. They are only interested in trying a finished or close-to-finished software product. Otherwise, they have shown absolutely no interests in participating in any type of research or surveys in an early product development stage because they think they can better spend their time looking for a software solution that is already built.

Is there any user research methodology that you would recommend in this situation?

* updated *

I really appreciate all the replies! They are all very helpful and are definitely making me re-think my approach.

  • 1
    Are you offering financial (or other) incentives to participate in research ?
    – PhillipW
    Commented Oct 3, 2012 at 20:20
  • Do you know why they aren't interested in participating? It might be beneficial to investigate that more deeply, and then see if you can't find a compelling way around that reluctance.
    – Olivia
    Commented Oct 3, 2012 at 20:51
  • Perhaps your 'research' is not hands on enough. Some types of distant research and surveys by email or paper can get low returns. Are you actually following users around and living their life, watching them, talking to them, engaging with them? Commented Oct 3, 2012 at 21:01
  • @ Roger Attrill: Due to the nature of work my users do (hazardous environment and irregular work hours), I am unable to conduct a more hands-on approach. Phone seems to be the only way to reach them as they are always out in the fields, and for them to take the time to sit down with me for a proper conversation would require a formal meeting to be scheduled, which I better have a very good reason for. (Hence the frustration)
    – phlo
    Commented Oct 4, 2012 at 6:15

2 Answers 2


Most people love to talk about themselves and what they do...

(If you're having an awkward silence at a party, just ask the other person something along the lines of "What do you do for a living?" or "What do you do on your spare time?")

After reading your question and formulation a couple of times, I believe you would get a better response if you changed your attitude/approach slightly.

The way I read your current approach, is that you have job to do, and you just need some users to "serve you with information". It's like "I need you to answer my questions, because I need to know more about you".

You should use an approach like "Hey. Can't you show me how you do this? I'm all new to this and I would love to know how you manage to accomplish all those things?" During this informal "interview", you could drop in a few "do you think that would have been better if it was done another way?" and "what's the biggest pitfall here?"

Although I do like your question, it is a bit broad. Because you don't say anything about your intention with this user research. What are you trying to find out, and what are you going to do with your findings? That is really α & Ω when you're working with UX.
Always know why you are doing something and what it's for!

  • If your intension is to analyze something (task analysis, user analysis, workflow analysis etc), then you should consider to use another data collection method. Ie. interview instead of survey, or even observation instead of interview.
  • If your intention is to involve the users, then you should consider to go all the way with "participatory design" - let some representative be involved in everything (meetings, voting, budgets, strategy etc).
  • If your intention is to evaluate some prototype, then you might consider to use some other method that doesn't involve users (expert review, cognitive walktrough, heuristic review, GOMS-analysis).
  • I doubt that your user group is so specific that you won't benefit from testing it with other people. Lots of research suggest that DIY-testing (ref. "discount usability") gives you very valuable information.
  • Since they only want to use "fully functional products", you might consider to deploy the product feature by feature (aka "vertical prototypes" ;-) ... ).

Oh, BTW: Why not let them try another software and ask them to compare pen&paper vs software. There's no need for you to do the same mistakes others have done. A competing product can be a perfect prototype ;-)

  • Jørn, thank you for pointing out what's missing in my question! I posted this question out of so much frustration that it probably sounded more like a whining post. The intention with this research is to find out whether if there are any common/standard practice within the industry, as well as evaluating some prototype.
    – phlo
    Commented Oct 4, 2012 at 6:31
  • +10 also for the attitude analysis and remedy! Commented Oct 4, 2012 at 6:56
  • The problem is that we are constantly reviewing and making changes our current prototype without any validation from our users. I feel that certain questions can only be answered by our actual users, such as: "Do they value accuracy more, or efficiency? Will they be constantly making changes to the data? Do they prefer to group the data in any specific ways?" This would affect how users input/edit mass data, and hence affect how the back-end data model is being designed.
    – phlo
    Commented Oct 4, 2012 at 7:10
  • +1, Great answers, a ethnographic study/field observaion as suggested will probably be a good start. Be curios on your users, spend a day with them trying to understand what they do. usability.jameshom.com/fieldobs.htm
    – Alvin
    Commented Oct 4, 2012 at 7:28
  • Ultimately, the key still remains to be finding out what they really need. I understand that a more hands-on approach such as field observation is the best approach, but due to the nature of work my users do (hazardous environment and irregular work hours), I am unable to do so. However, I really like your suggestion letting them try another software as a means of evaluating prototype!
    – phlo
    Commented Oct 4, 2012 at 8:43

Following the lead of Benny, you could try to "market" your prototype a little differently. You could go to their manager and/or informal leader, and tell him that you are looking for the most talented, experienced and sophisticated employee. Then, this person would be granted the opportunity to peek at the new design. The exclusivity among peers boosts the attractiveness of the testing, which could also be supported by encouragements such as "you have a chance to influence how everyone would be working with the new software". In my experience, this right "marketing" can really get people at your doorstep.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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