I am user testing a new quick links section on the homepage that links to the most visited sections on the site. The links include news, education, forms etc.

I am trying to understand the best way to structure the user test. I will ask the participant for their first impressions and see if the quick links section stands out to them. Also as a task, I will also ask them to navigate to the forms section from the homepage and see if they use the quick links.

If however they use the navigation in the header to go to the form page and not the quick links, is it best practice to then take them back to the homepage and ask if they could think of another way they could have got to the form page or does this interfere with the test and their first attempt is the only valid attempt?

Should I even build the navigation path to the forms page in the prototype as the alternative. Is this a distraction or an opportunity to see how the participant behaves?

2 Answers 2


TL;DR: Get context first, stay on script, and only go back when it won't bias other tests

Get Context

First, get a gauge of their experience with the product or service you are testing. This will give you some important context later. You can do this by asking if they've ever heard of it, how often they (might) use it, what they (might) use it for, etc.

Stay On Script

Next, take them through the task without drawing their attention to the new section. Some of them may spot it and use it. Some of them may not.

Once the task is complete, ask them about their reactions to the task: If they found it easy or difficult, what liked or didn't like, etc.

Then you can ask them what they might change to make the task easier. You may find that they mention something like your new section here.

Don't Jeopardise Other Testing

Once that secondary interview is complete and there's no chance of biasing other tasks, you can take them back and show them what they might have missed. That's when you ask them how useful they think it would be, why they thought they didn't see/recognise/understand it, and what you could do to make it more visible/understandable.

Some of the users who miss it may be experienced users who are used to running through the UI in a particular way and rely on a kind of "muscle memory" of "I click this, then that, and that takes me there" rather than looking for the quickest or most logical way. This is why you need to ask them about their experience with the product at the beginning - so that you can weight their responses appropriately.


I think you should build the navigation and let is up to the users which way they take (navigation or quicklinks). If all of the users will choose the navigation maybe your quicklinks section is not that helpful to them or is not perceived as a helpful feature to them. And that's the thing you want to find out.

If you want to test the structure of the quicklink section you could the point out that there are other possibilities to navigate there. This way you find out if the quicklink section itself is understandable but not if the quicklink section is found by the users. But you still can use the data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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