How to handle nonfunctional elements in prototype?

Question

In an interactive prototype there often tends to be elements displayed that don't function the way they eventually will, due to time constraints, not being a part of that particular user test, etc. But the elements (buttons, links, anything that could potentially be interacted with) still appear for the user. And because they are there, some user will at some point click on one, even when directed toward tasks that don't correspond with that element at all.

What is the best way to handle when users try to interact with nonfunctional elements?

I've thought of a couple possibilities, but am unsure whether or not any of them are viable or if there is a better solution I am wholly unaware of.

For example, the element (say, a button) could be visible, but not react at all when a user clicks on it. The user would quickly become aware that is doesn't do anything at the time.

The button could show a tooltip or some visual indicator that that specific function isn't available at this point in time.

We could also maybe ensure that every interactive element that does work includes a hover state, where the ones that don't function don't have a hover state, indicating before a click that they won't respond.

But to reiterate, what is the best way to handle inadvertant user interaction with nonfunctional elements in an interactive prototype?

Answer 1

I like the elegance of using hover effects (such as described in Konturs answer) however these will confound the study results because it will guide the user to know what areas not to click and over time, it will actually increase their success rates.

In fact, I usually try to ensure that no cursor differentiation occurs at all- making it so that the cursor is either always a pointer or always a link cursor. It doesn't matter which as long as they are consistent within study. This helps to even the playing field when the user is trying to figure out what to click on next.

Also, hover effects will not work for touch. So any mobile/tablet testing wouldn't be able to use it, unless the tooltip appears only on tap of the incorrect target- that may be the answer for all solutions actually: show a contextual, non-intrusive tooltip-like widget that appears over the incorrect target, only upon intentional selection of that target. You could even use this solution for gestures in touch testing. Upon unsuccessful gesture do to prototype fidelity, show the explanation widget where the gesture was performed...

Answer 2

I could imagine a cursor like either of the below to be a good visual indication that the item hovered is not yet usable.

or maybe

Both are standard browser styles, so implementing them in a HTML based prototype should require only little effort. An additional tooltip like "feature not available" might be of help, too.

Answer 3

I think this information should be as unobtrusive as possible so that it doesn't draw attention and interfere with the testing session or presentation unless necessary, but when it is encountered, should be explicit in explaining why the feature cannot be used.

However you provide the information, the most important thing is making it clear why the element cannot be used. The user needs to understand that the element is unavailable not because of something they've done (or haven't done) and not because of behaviour integral to the product itself, but rather because it isn't available in the prototype.

Answer 4

Disable the nonfunctional elements: http://www.w3schools.com/tags/att_input_disabled.asp

Additionally it would help to provide a color indication that the element is not in play to distinguish it from something that is in play but in a disabled as per normal use case, but sometimes color CSS styles have no effect on some elements in some browsers. Maybe a colored dotted border would show up but that might screw up the layout.

In any case the out-of-play elements could be managed by a script to it out of the markup.

Answer 5

You should not give a visual indication that a feature is not implemented in your prototype. Instead, the user test moderator should set the expectation up front that the participant is using a prototype and isn't actual working code, and thus not everything works if you try to interact with it. This is also a good time to remind the participant that since it's not actual working code, their feedback is especially valuable to you because you have a better opportunity to make changes based on their feedback.

If you were to use a prototype where they have a visual indication of what works and what doesn't, your participants will scan the prototype with their mouse as well as with their eyes, looking for the cursor to change so that they know what to click on to move forward. Not only will you artificially increase their success rate (and potentially have an impact on their time-on-task, if that's something that you're measuring), you also won't learn on where they think they should click to complete their task. When testing with a prototype like this, you have the option of asking "why did you want to click there?" or "that doesn't work, what do you think would happen if you clicked on that?". Otherwise, you can simply say, "that doesn't work, can you find another way?" If you find that a significant portion of your users in the study try a particular way to complete a task that isn't what you were trying to test, this means you might want to reconsider your design to better match with their mental model.