How to usability test a prototype that's not fully functional?

Question

I will soon be performing usability tests on a design prototype of a web app.

The proposed system, though, makes use of some advanced interactions that we probably won't be able to mock up in the prototype. Things like updating a graph on the fly based on data inputs, highlighting overlaps in the graph on the fly, etc.

What techniques exist to fake interactions in a prototype that's not fully functional?

In past tests like this I've used a Wizard of Oz technique, where an assistant generates feedback screens based on the user's input, and feeds them to the test screen. We might go that route, but I'm wondering what other techniques are available for a situation like this.

Answer 1

You can get pretty close to fully-functional with some prototyping software, like Axure.

Sometimes, though, building out every interaction and animation isn't worth the time. You can always use a simpler interaction to stand in for the real one. Some small confirmation that the user's action was recognized, in conjunction with your explanation, can be sufficient to keep the test moving. You could even keep some paper mockups handy to hold up and talk about.

I've done this with great success for a website that would send an email confirmation. I didn't have an easy way to display the email they would receive after clicking a certain button, so I just printed a copy and we talked about that.

This also depends on the test participant... some people can easily put themselves in the mindset of focusing on big-picture functionality, while others will get caught up in minor details.

Answer 2

Invision's prototyping product allows you to create and visualize UI interactions and responses based on your designs. Actions like state switching, hiding/showing of elements, and bringing in new data can be achieved.

Create a mockup of the base graph, another of the exchanged data, and you can add what they call a "hot link" or "hot spot" to a button, which can prompt the overlay of the latter view, hopefully achieving what you need.

Essentially, it just switches static images in and out (with nice, fluid transitions) based on where you press/click.

Answer 3

OK, here's a reply out of left field.

How about human-computer paper-prototype testing? If you use hand-drawn mock-ups on paper, then afterward you can get the participant to sketch ways to make ti better.

If you do this, I recommend:

• Use large-nib markers and really large sheets of paper.
• Use pieces of transparent coloured plastic (from a report cover) for highlighting.
• Practice beforehand, so you're sure you've got all the bits you need.

You'll need two of you for each participant: one to be the computer (who doesn't talk, only responds to "clicks"), and the other to facilitate the research.

Since the product isn't ready, that means it may not be too late to change the design, so why not paper prototyping?

Hope this gives you another option. If not, sometimes having something you Don't want to do makes it easier to choose the thing you Should do. :)

Answer 4

It depends where you are on development and design stage. If you have multiple ideas and more unknown questions, paper-prototype testing will be a good solution. Micro interactions are also important like updating a graph on fly based but I hope that this is not the only part of the system. You should have an overall testing for correcting the assumptions.

I am not going to give tools name but give my insights.

• Early stages - tools that are rough, that take less time
• Early-mid stages - tools that can be modified easily in digital environment
• Mid-final with ongoing development - version(ing) and documentation focused tools

I hope that it helps.

Answer 5

The following reply is based on the information you supplied. Obviously there are different approaches that could be taken to the problem. I am guessing that you are quite far in the design process and what to test specific user journeys, content and interactions.

When interactions require user input, one solution is to give the participant a task or scenario that requests specific information to be entered. you could check with the user whether this is the sort of task they might be likely to complete.

Example: If you had the following data [EXAMPLE] what would you do?

Then on submission, you can present them with the appropriate output based on the data.

If the user completes the task with different data, you can explain to them that it is only a prototype and the output is a "representative example" of what would be presented to them.

This dummy output data should still provide you answers to the following questions:

Is the task/data you selected appropriate?

Can they complete the task (enter the data in the right location, format etc)

And do they understand the output - What the graph/chart is representing.