Currently, each mission on Maze must have at least one defined path, and it is only considered complete once a tester reaches the end screen of the path.
This means that the ability to let testers navigate through your prototype without a defined goal is not supported directly.
This article explores a workaround using a prototype block and some adaptations in your design file.
This workaround only works with prototypes. Free roam is not currently supported when testing live websites.
In this article:
Before you start
- Before creating a free-roam test, it's important to consider the modifications that you'll need to do on your design file, and their respective implications on testing and results. Learn more
- Most relevant tester interactions will be recorded as an indirect success. Learn more
Set up your design file
Design elements
In the design, include the following elements to allow your testers to explore the design without being given a specific task:
- A banner or some other element that testers should click in order to complete the mission once they've finished exploring, or they think they've completed the task.
- A generic success screen that's triggered when clicking the banner.
Prototype setup
When setting up your design file, you can either use the same prototype where you conduct your normal task-based usability tests, or use a separate prototype.
Option A: Use a single file
If you want the same maze to include mission blocks for both the free-roam testing and the task-based usability testing, you'd need to use the same design file. This is because you can only link one prototype per maze.
However, this workaround requires adding more frames to your existing file, which may impact performance. As such, this approach may not work for larger files.
If you opt for using a single design file for your mission and your free-roam blocks, you should also ensure that all relevant frames are accessible in Maze by adding multiple flows.
You might also need to change the starting screen before setting your path so that the free-roam block starts with the correct screen.
You should also note that adding a free-roam test alongside other mission blocks will skew the results data.
This shouldn't be a problem if your primary goal is to analyze screens and paths at the block level in your Results dashboard. This functionality will still work as seen in the Analyze your results section below.
However, report metrics and analyses are calculated at the maze level. Since free-roam results all count as an indirect success, this will bring metrics such as the usability score down.
Option B: Use a separate file
Creating a separate design file for your free-roam test allows you to keep the file size lower, since the file only needs to include the frames that are relevant for that test.
This approach also maintains the integrity of your results, since there is a complete separation between results and reporting for the free-roam tests and for other missions.
On the other hand, you would need to create a separate maze because only one prototype can be imported per maze. This option does therefore require you to maintain two separate design files, as well as two separate mazes.
Create a free-roam test in Maze
After importing the prototype into Maze, set up a single two-screen path that leads from the initial screen to the generic success message.
Because testers will need to click the banner in order to complete the mission, it's particularly important that you give clear instructions about what they're expected to do on that block.
Analyze your results
With this workaround, you won't be able to analyze your Results data as you normally would for a mission block.
The only expected path is the two-screen path you've set up leading to the generic success screen. Because all testers will take unexpected paths before they reach the last screen of the mission, most relevant interactions will be recorded as an indirect success.
As a result, metrics such as the usability score or the misclick rate will be heavily skewed. That said, you'll still be able to analyze your testers' behavior by looking into paths and screens.
To avoid skewing your usability metrics, you may want to use a separate maze in order to conduct free-roam testing.
Path analysis
When analyzing paths in a free-roam test, make sure that the Indirect success tab is selected, since this is where all your meaningful data will be located.
Dive into the aggregated path data to see which were most common among testers.
Open each path to analyze the respective heatmaps.
Screen analysis
Click each screen to see the heatmaps/clickmaps of your testers' interactions.
Tester analysis
At the bottom of the page, you can also see details from each individual tester session.