I have a general question so I'll provide an example:

Let's say you were assigned to build a software which will be used on a daily basis as a professional tool, let's say a statistician's.

Now, you understand the major components of the software as they are quite obvious (Maybe a spreadsheet of some sort) but you can't possibly understand what all the parts of the product are without using it on a day to day basis.

You can obviously refer to similar tools but: a. It will uncontrollably make you think of a similar solution to a problem, which is not necessarily the best one. b. They might want to include some features that don't exist in other products.

I was asked to help out a friend with an app for his workflow but I'm having some trouble understanding his needs.

Thanks a whole lot!

5 Answers 5


In the beginning of the design phase I would recommend these methods to discover the users needs:

1. Contextual interviews.

Basically follow a user around in the environment in which they will be using the product, performing the tasks which the products will help them perform. Follow up with a short interview clarifying your obbservations. Seriously, this method has given me so much insight that I would never have gotten if I'd stayed in my office. This is how you find out what the users need, as opposed to what they say they need

2. Personas

Create personas for your main user types, so that you can keep empathizing with your users needs and wants, as opposed to using your own needs as the basis for how you design your product. This is especially important if the users needs and wants vary greatly from your own.

3. Wireframing
http://balsamiq.com/ http://www.axure.com/

Start wireframing functionality. I'd recommend Balsamiq or Axure for this, but there are a bunch of tools available

4. Test your wireframes

Repeat 3 and 4 until you're satisfied that your product fulfills the users needs in a satisfying way

  • 2
    I can't edit as its fewer than 6 chars, but for linebreak add 2 spaces at end
    – Fractional
    Commented Dec 11, 2013 at 11:31
  • I got so sucked in to start building a solution so I can have something to iterate from (An MVP) that I haven't even thought about creating personas (A process which I actually quite enjoy! Needless to say that it brings valuable insights). As for contextual interviews though- do you feel these apply to cases where the solution you are trying to come up with is drastically different than the one currently being used today? How would you adjust?
    – Nir Bentia
    Commented Dec 11, 2013 at 15:47
  • I definitly think contextual interviews apply. I've used it in situations where there wasn't even a product to compare with, I just went out and observed the users doing the tasks they normally do. The results heavily influenced the final product, they hade some problems we could fix that we never could've anticipated, as well as us having some planned functionality that we never implemented because they weren't relevant for the users situation. A contextual interview is not the users using your product, it's them being in their normal environment doing what they normally do Commented Dec 11, 2013 at 17:06
  1. User research studies are a great way to get feedback on a product. Watching and listening is the best way to know what it's like to be the person using the software. This can also offer fresh perspectives after you've been working on a product for a while.
  2. Interviews are another opportunity to gain insight into your users. If you're making a professional statistically tool, talk with a statistician. What is the most time consuming part of their day and how could your product make that task more efficient?
  3. Find weaknesses in already existing, similar products. These weaknesses can be found in your own product and the competitor's. By identifying the weaknesses, it will get you thinking creatively to find new solutions, instead of similar ones, as you mentioned. Weaknesses may consist of things such as:
    • a task is unable to be accomplished (absent feature)
    • it's unclear how to accomplish a task (confusing UI)
    • a task could be completed more efficiently (possibly predicting data that a user must manually input, i.e. autocomplete on searches); thinking ahead to what the user will likely do next
    • disconnected products. Many times, there are two useful features or products for a user, and they need to be connected efficiently (example: gmail turning dates into links to a calendar)

I deal with this every day. I agree with the other posters on good solutions, but in my workplace and presumably in your scenario, their is no user or subject matter expert available to me. Sometimes in work we don't get to interview the end users because our boss doesn't give us the option or support such research. I think your question is what do you do when you don't get to do a survey and have no access to the users for observation.

What I do is code whatever someone gives me as best I can. The important trick is to realize that people who ask for help with designing a UI and don't provide you with the info and resources to do a good design job, are not expecting a perfect design job. They get through design by guessing and coding and then facing user dissatisfaction and then re-coding and repeating slowly and expensively because they have never experienced a repeatable better design strategy. Or maybe it's their first time designing an app flow and they are happy to have anything at all that doesn't miss major things like the save button or nav buttons. Check to be sure terms are used consistently and they don't use "employee" in one place and "personnel" in another when it's the same data element. Make sure the colors don't vibrate and a line length of text doesn't stretch from the left side to the right side of a large screen monitor.

These people usually want to see something pretty and won't notice a bad user flow or awkward experience until users have complained repeatedly and they've personally gone to a usability lab and learned some fundamentals. I'm not trying to get down on them, it's just not their profession or area of expertise. So pretty much anything you do will be a help just because you know enough to put in a save or a back button. Focus on preventing obvious newbie or non-designer mistakes like all capital letters for labels and all bold fonts for every sentence. Relax, tell them briefly about the effectiveness of use case and persona development while their eyes gloss over and then keep your time investment to a minimum so you'll be ready when they come back to you and ask for more help.

As they say. . ."You can lead a horse to water, but you can't make it drink." focus on maintaining your willingness and ability to make another trip to the river when the horse is ready for another sip until it learns how to gulp deaply on it's own.


Your goal is to understand the users' tasks. If you can't get hold of users to explain them to you, you need a different source which explains how these tasks are conducted.

As an example, my main project is currently a knowledge repository for description of animal experiments. I got no access to users, just to the product owner, who is a biologist, but has very little understanding of IT. She mainly said "it should be like the existing database of animal lines, plus a few fields for experiment procedures". Immediately, I had alarm bells go off in my head: will this really cover all the possible experiments?

So what I did was to go to Google scholar and find a bunch of articles describing such animal experiments. I fought my way through the papers, even though they were hard to understand because I am no biologist, and emotionally jarring because they contained pictures of cut-up mice. Then I made mockups of the animal experiment screen and started filling them with the data from the articles, the way a biology grad student will have to do when he or she uses my application. I found lots of things which deviated from the "old animal database plus three procedures fields" concept, and changed the mockup to accommodate them. The application still hasn't gone out to the users, but since then, I have seen no piece of test data which wouldn't fit into the current concept. And I know that it will fit, because I am capable of going through the task myself.

In your statistics software, it will be best if you can do the same thing. To see your own application through a statistician's eye, you have to become a little bit of statistician yourself. The best way is, of course, to have a statistician lead you through a particular task. But if you cannot get hold of a statistician, you will have to learn it from other sources. Take an introductory course in statistics. Find a textbook for statisticians which explains how to solve a problem of the kind your application will be used for, and try solving the problem yourself. Note where during the solution you had to make decisions, and what information you needed to make them. Then design functional mockups of the screens of your application such that they support your solution. Make sure to include the decision-relevant information at the places where you needed it. Provided that you were able to approximate the solution process reasonably well, this will give you an application which a very high need fit.

Of course, this method has its limitations. First, the more specialized knowledge the task requires, the higher the probability that your way of solving the problem will differ significantly from the way a specialist would solve it, and thus the application will not be as well adapted to the specialist's needs. Still, it is better to do it this way than to flail through the dark with no idea how the application will be used. Second, the more generic your application will be, the harder to cover all the tasks needed. An application which will support a particular business process is easy to design, because you can tailor it to the process execution. If you are making a competitor to Excel or R, you cannot go the way described above, because you cannot learn all tasks a specialist might want to execute with a general purpose statistics software. Third, it is very time-intensive for you. But I think that it is time well invested, as it lets you make a really good product.


This is an out of the norm situation. Therefore, perhaps some out of the norm user research techniques might help.

Interviews are the next best thing, but once again, you need something more than that. It's all mathematical:

  • in order to plan a product you are accustomed with, you need to elaborate an interview, right?

  • in order to plan a product you are not familiar with, you need to dive in it and become it. In a short period of time, you need to compensate and to get as experienced as possible, faking the passion of the most fanatic user, so that you can borrow the appropriate mindset. It's crazy and it's similar with being an actor. It's even scary, why not? I mean for a few days you basically forget about yourself and become someone else. But think about it this way: when you return to your normal self, not only that you have learnt a new experience, but your empathic skills are now fantastic, which is a great asset with regard to being an UX professional.

  • 2
    Mircea, you write nice answers, but are you planning to write answers linking to the same site every time? Also, the article you linked has absolutely nothing to do with the question and slightly related to your own answer. Please stop it.
    – Devin
    Commented Jun 29, 2016 at 18:46

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.