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.
