Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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?

share|improve this question
3  
I personally believe in your second suggestion, showing a tooltip or modal that maybe explains what the feature will do but that it isn't implemented yet. This way the GUI doesn't seem broken, like an unresponsive button or other error indicator might do. –  AndroidHustle Jan 9 '13 at 15:33
add comment

5 Answers

up vote 5 down vote accepted

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...

share|improve this answer
    
You make a really good point with having no cursor differentiation! I hadn't thought of that, but it seems like it would be beneficial in seeing where the users think they should go next. Thanks! –  mookamafoob Jan 10 '13 at 14:27
add comment

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

enter image description here or maybe enter image description here

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.

share|improve this answer
add comment

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.

share|improve this answer
    
I definitely agree with the extra information being unobstrusive and likely concise as well. Making sure they understand it is no fault of their own is not something I had thought of, and would clearly be important. Thanks! –  mookamafoob Jan 10 '13 at 14:29
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
I really appreciate the detailed answer you've provided here. I was hoping to get some insight from actual user testing and it sounds like you've had that experience. We may be looking to let our metrics capture most the interactions, so I was considering putting hit boxes over elements that don't work, just to see where they click, even if there is no feedback, so we can evaluate it later. Then we can see patterns between participants. Any thoughts on that approach? –  mookamafoob Jan 11 '13 at 14:43
    
I think it depends on what your testing methodology is. If you're doing a standard usability study, your test moderator and/or notetaker (depending on whether you separate out those two roles) should note that the participant tried to click on something that wasn't available, and that should be part of their analysis of the data that they collected during the test. In this case, I would rather that the prototyper spend more of their time getting the prototype right, rather than doing things like adding hit boxes so that they can collect data that the test moderator/note-taker should collect. –  nadyne Jan 12 '13 at 1:35
    
Also, what is your reason to have your metrics capture most of the interactions? Do you want to have an unmoderated test? –  nadyne Jan 12 '13 at 1:41
    
Our tests don't always allow many researchers to be present, unfortunately. When it only takes a few minutes to add methods for capturing metrics, I thought it may ease the burden of the moderator and allow them to focus more of metrics that can't be easily captured, like body language. Ideally we'd have enough people and time to get everything right, but our users time is extremely limited and meeting with them at all can be a major challenge :) –  mookamafoob Jan 14 '13 at 15:28
    
I'm usually the only researcher at the research that I can conduct, and I personally wouldn't find such a thing useful. I think that you would be best served to talk to your test moderator and ask them what you could do that would be most beneficial to them in this scenario. –  nadyne Jan 14 '13 at 22:56
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.