7

I have just started a new project and I am going to be speaking to customers directly to try to derive needs for a new version of the software application. I have not done this before.

Some of my constraints are:

  • Small user segment (less than 300 users) but I may only get to speak to 15-30 reps from the customer organizations.
  • I may have access to some in person interviews but a majority are geographically far away and there is not a budget to travel to all locations. So my options are phone or online interactions.
  • My agency does not have a culture of user-research yet and I am the only UX professional.
  • This may be my only opportunity to communicate with end users. If it goes well it may open up future possibilities.

My tentative goals are:

  • Differentiate technical roles of users to determine the need for specific features.

  • Determine how our app is being used in customer day to day processes and identify pain points.

  • For onsite interviews I would like to gather as much information as possible. For Example: identifying if they are using browser versions or browser tools that may hinder the display of our app.

My questions are:

  • I have been reading that focusing on the past is the best way to get information on users goals, tasks, and day to day activities. We have a small what are other framing techniques to help keep the conversation focused so that I am not trying to answer customer service issues?

  • I have been reading that using small prototypes to get feedback can be very effective. I have a backlog of requests for the new version of the software I can prototype but none of it is mature. Is this sort of early feedback recommended? How do you set customer expectations? My fear is having a customer think they can micromanage the design because they are a larger customer. I also worry that it may set false expectations if design goes another direction.

  • What are my best options for deriving the most relevant information from these customers? Does it have to be consistently derived from a single technique or can I use multiple techniques to try to piece a bigger picture together?

Improve this question
2
  • You use both "customers" and "users" here. Do these two words represent different groups of people, or are you using them interchangeably?
    – nadyne
    Jan 23, 2014 at 0:44
  • My understanding is that each customer may have several types of users. The user may be the purchaser or that may fall to a different group but they should all work for the same agency. One of my goals is to try to determine if the same person purchasing the software is the same person who uses it on a day to day basis.
    – Chromarush
    Jan 23, 2014 at 2:31

1 Answer 1

Reset to default
2

Detailed questions lead to detailed answers. If you don't want to face detailed, but differentiated and inconsistent clients' expectations, do not suggest any precise solution. Try to get general information on what should be the result of work with the application, what application have been used for that purpose before - if any actually have been; do some research based on deduction, simulating their environment on your own, rather than precise information. If one is annoyed with Windows 8, he will start complaining about how these damn tiles work, but he probably won't mention the tiles could have just a little different information on them. Ask about the information that needs to be shown, not about the preferred data presence.

As mentioned, focusing on the past seems to be a very efficient way of getting to the bottom of clients' expectations. Getting information about past problems is also a way of designing a great UX and there's nothing wrong with getting details about glitches in the users' daily routines; if you want to avoid too detailed/technical answers, start the conversation with the honest introduction and say what you do, and what you don't expect. Just put it into some nice words. Try to make an appointment with an e-mail rather by phone and give your interviewees opportunity to get prepared well (and make sure they will be able to!) - send them a list of topics you will talk about; if any of your questions eventually will require a detailed answer, that's a good opportunity to ask it - instead of counting on customers' memory and improvisation.

Use small prototypes only for expressing what you mean to explain (and emphasize it's not a ready solution) - but don't use prototypes for literally getting feedback, like mock-ups edited in Microsoft Paint (which is surely going to happen if you don't make a clear statement you don't want that). If people suggest their own solutions, listen, but explain that every solution needs deeper research and discussion with the developers.

Looks like this is where UX designing meets psychology. Hopefully this helps a little.

Improve this answer
6
  • 1
    I would also advise on being careful: what people say are not what they really do. So you should try to spend some time with real users (not representatives) and observe how they really use the old system. This will let you take conclusions for yourself and help you prioritise.
    – jff
    Jan 23, 2014 at 21:40
  • Why do you recommend setting up meetings by email rather than phone? In my experience people are really bad at answering emails, and when they do, they have 20 emails to get through so they hurry and won't prioritize me. By calling you can express more politeness and interest in their feedback. My experience is not from software design or anything similar, but still contact with people I don't know, and I think the challenge is the same.
    – Mads Skjern
    Sep 25, 2015 at 16:30
  • Resources for learning more would be great if people have any :)
    – Mads Skjern
    Sep 25, 2015 at 16:32
  • I don't understand what you mean by "don't user prototypes for literally getting feedback".
    – Mads Skjern
    Sep 25, 2015 at 16:33
  • @MadsSkjern, as it comes to the e-mails, reason is pragmatic, you are less likely to forgot about anything if you write an e-mail (there's time to think), and it works the same for the customer. So if a meeting needs solid preparation, you can emphasize this in e-mail; voice calls are a lot more spontaneous and the conversation can end up in being a long digression about something completely unrelated.
    – Grzegorz Janik
    Sep 29, 2015 at 19:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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