Well sort of. Here is an approach that has worked for me on numerous occasions. To set the stage lets imagine that you are building some new application and it is nothing like any other you have seen. So clear your mind of any preconceived notions of how users will interact with it.
So how do you know what your interface should act like? The technique that I have found to work is appropriate whether you have real users to work with or not.
Step 1: Determining GoalsThe first step is to try to identify what goals the user will have when using your software. Usually this is partly determined by business folks, since they are the ones who came up with the idea for this thing. This would also come from real users if you have them. This can also be assumed if you happen to be building an application that is supposed to replace an offline, or paper, process. For our simple example, we will have a single goal. The subject is trying to find a person from an employee directory.
So that part is not where the phone comes in. That comes in step 2.
Step 2: The phone
If you have real users to test, you can use this technique with them. If not you can use this technique yourself or with others on your team. This involves a bit of role-playing however, you can make it seem less silly by the way you present it. You start by having one of the "test subjects" imagine that they have a set of goals that they want to accomplish but instead of having the application in front of them, they have a phone. With that phone they can call an expert user of the software and tell her what to do.
The idea here is to allow the user to forget about the software and focus on the human way in which they are accustomed to interacting. What you will find is people treat a human and expect to be treated by that human very differently. You will find that users typically think in non-linear terms meaning that you need to support unexpected task flows. You will also find, assuming you can do this test with multiple subjects, that patterns arise. These patterns can help you build your interface to meet human needs.
For example, lets say we are building a search interface to enable users to find other employees in their organization. You may be tempted to create a search form with first name, last name and employee id fields. The results screen shows a table of results with a back to search link. What you will find with this test is that users don't necessarily think in discreet properties. They might say, over the phone, "Search for John Doe". What that might translate to is you would have a search field where you type in the user's whole name. They might say "Search for John something that starts with D". That same single field will work if you allow it to support entry of "John D"
Continuing on with the approach, the expert user on the other end might say "There are 200 John Does". The subject might then say "I know he works in the Foo Department". So your search results page should allow further refinement. The user would not likely say "Ok start over and search for John Doe in the Foo department" meaning that your interface should not force the user to start over either.
Imagine for example that instead of returning 200 John Does, the voice said "No John Does were found". The subject might say, well I know if is "something Doe". Your interface, might provide a mechanism on the search results page offering to look for all Johns or all Does in the event that the no results were found.
This technique can be very successful as along as you keep the user on track. Don't let them start to say things like "Click on the button..." or "Go back to the previous screen". If they do, then they are thinking about an imaginary version of the application. This happens frequently when you are trying to redesign an application that users are familiar with. This also happens when doing this test on product owners. They typically have a "vision" of what the product should look like. In reality though, they only concern themselves with the problems you are trying to solve and the goals of the end users.
