Unmoderated usability testing on websites where registration is required

Hi, I’m looking for feedback on how to handle unmoderated usability testing on websites that have the barrier of required registration or subscription?

Background: Our website requires users to register or log-in after a certain number of clicks to view content or access certain features. We usability test our website through a third-party testing company, and the testing recruits aren’t usually registered on our site. This creates an obstacle right off the bat, and can disrupt the actual features/functionality we’re testing.

Right now, we’re creating individual test accounts and using custom URLs to automatically log the users in so they can bypass the login/registration process. This has started to become cumbersome as the accounts store the user data (i.e. if they take a quiz, save an article, etc.), which we then have to clear out after each test to reset the account for another usability test.

We can’t just create one test account, since after the first person usability tests, their saved data alters how the next user would experience the website and we often have concurrent tests going on.

Does anyone have feedback on how they handle they handle similar obstacles?

Thanks!

Hi Jenny,
Welcome to the UX Mastery community, and thank you for explaining your problem in detail.

I’m not sure what you are testing - if it is a feature for registered users, or the flow itself (when to prompt users for registration). I’m guessing it’s the first of the two.

I ran into an article some time back, that mentioned server-side A/B testing and feature flags. While it’s not an exact answer for your question, but I think it might be helpful – perhaps you can run the test in-house, with your existing users, and then use analytics to track behavior.

Here’s the link to the article, in case it helps:

Best wishes!

Hi Kasturika!

Thanks so much for this helpful response. You are correct, I would be testing a feature accessible only to registered users, not the login/registration process. The article you provided gives a different approach to this issue that I didn’t consider–I will see if this is something we could implement. Thanks again!

1 Like