I'm a software engineer responsible for the development of UI software for an embedded device that will be used in laboratories and hospitals. I have the rare opportunity to visit one of our customer's labs for a day, and I'm aiming to gain as much insight as possible into the use environment and workflow. This information will feed into the UX design (aided by UX designers, who unfortunately can't also do the site visit due to geographical reasons).

So, what are the things I should look for, questions I should ask, and information I should gather while I'm there?

  • 1
    Just some thoughts: Tell the customer that you're not visiting to see them make mistakes but to improve the software. Know your main use cases (or your assumptions) and validate. See what they use most and if it could be more efficient. Ask for the top 3 changes they would want change in the UI. Don't explain, watch them, listen and take notes as much as you can. Commented Oct 2, 2013 at 23:49

3 Answers 3


You could carry out a mini ethnographic study, it is great that you have the opportunity to observe the users in their real-world environment.

It is worth looking at:

  1. What they do
  2. How they use things
  3. What they need

Information that would be great to gather include things like, contextual interviews, examples of other devices that they use and maybe some video/photographs (if possible).

I agree with what greenforest has said, you are not there to undermine them merely to see how the embedded device can be improved and actually help them more to do their jobs.

Maybe see if you can get a small focus group together with a white boarding session, simple questions like "Best things about the device", "Worst things", "Features you wish it could have".

Be careful to speak to the actual users and not the 'managers' you want to know real users thoughts.

And take criticism on the chin, it can be hard to hear sometimes!


This is a great question, and I'm so happy to see that you're trying to make the best use of this opportunity that is being presented to you. I gave a talk at Google DevFest West titled An Engineer's Guide to Learning About Your Users, which has a lot of advice for the best ways to go about doing it.

The first thing to remember is that it's your job to listen. You want the people who you're observing to talk as much as possible and share with you what they know, what they're thinking, what works for them, and what doesn't. If you're ever stuck and can't figure out how to get more information about them or how to formulate a question, "tell me more" is a magic phrase that can help you in amazing ways. You should speak as little as possible: you already know what your opinion is and what you think your product should do, you want to hear what their opinion is and what they think your product should do. Talk enough to get them talking.

The second thing to remember is to be open to all feedback, whether it's positive or negative. Feedback is a gift. Be open to receiving it. Remember: if someone's really angry, it means that there's a mismatch between their expectations and what your product is delivering. You've got an awesome opportunity to understand what that expectation mismatch is and how to solve it, and thus turn a detractor into a supporter.

When you're asking questions, avoid leading questions. I try to avoid starting off with "best things about the product" or "worst things about the product", but rather starting with "what do you think about the product?" This allows you to learn whether the first thing that comes to their mind is positive or negative, which is really important. If you feel like you're only getting one type of feedback, you can later probe to see if there is something on the other side of the coin (ex: if they only give positive feedback, let them give that feedback and then ask what they don't like about the product).

Likewise, it's important to understand what their need is, not what they think will meet their need. Asking about what features they want focuses on the solution. Your opportunity to truly innovate and make an awesome product is to instead understand what problem they're trying to solve, or what task they want to complete, or what their workflow is. Once you understand that, you can create an innovative solution that meets the needs. It might not be the same thing as what they would suggest to solve the problem, but it might do a much better job of actually solving the problem that they have.

Don't forget to share what you learned as widely as possible. Not everyone is getting this opportunity to learn from your users in this way. Let others know what you learned and what you think could be done to make your product a better one.

  • Thanks for the advice! Just fyi I had to login to Skydrive in order to view your slides (which were really useful btw).
    – akatkinson
    Commented Oct 4, 2013 at 23:24

Get a copy of - Rocket Surgery Made Easy if you can.

MeeMMeem provided a great answer. The key to is to find out what users do. Avoid asking them what they want as you're likely to end up with a wish list that isn't really useful. What they need will come out through you talking about how they do things and what they need whilst they do it. Noting how tasks and needs change between different roles is also very useful for your UX designer. Avoid judging the end users and, if you can, sketch out a few pen portraits after you talk to people - that will be a few facts about them and what tasks they do. You don't need to know their age incidentally as too much demographic information will cloud judgement later (a common mistake). I find these pen portraits far more useful than personas in the work I do.

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.