5 Ways Clickthrough Prototypes Harm Usability Testing
I love them, but they are the wrong tool for this
Before you lash out, I am not a hypocrite
I love a clickthrough prototype to discuss a design within a team. But usability testing is meant to validate an experience with actual users. And for that to work, we need to test a flow inside-out, forward and backward, and everything in between until we cover every scenario a user may face with the real product. Sadly, a click-through prototype done in Figma, XD, invision or any prototyping tool simply doesn’t allow that; mainly when it comes to remembering input, and informing users of a screen’s content and available actions. It falls short.
The results will be very unfair to the design, and far from right.
1. Selecting One Radio Option from Many (not a dropdown)
How are candidates to know they can only select one when the prototype allows them to select many?
I know what you are going to say; the designer can indeed make the entire list a component with two example states to allow users to switch between them to showcase the correct behavior. But what happens when they don’t select the option that triggers the status change? Nothing. This frustrates the candidate and leads to unrealistic results.
Please don’t tell me to use hotspot hints. What’s the point of the test if I tell a candidate where to click?
It’s pretty simple to make this in a nocode tool, though. This took 5 minutes in Bubble, and it’s a custom radio button too. Not the drag and drop one.
2. Understanding that a Container is Scrollable
Scrollbars in scrollable containers is a feature that honestly should be in Figma by now. It is amazing that we can make a frame within a frame scrollable, but how can a user know that more content and how much content is available on scroll without any visual indicator? Even if you use line spacing to show a part of a line to indicate more content, it’s a weak hint and requires strong concentration from a user who has other things to think about.
This is particularly harmful in forms wrapped in fixed height wizard containers. Candidates may miss fields simply because they don’t know they exist.
You can manually make a scrollbar but it’s too much hassle for a something that should be there by default. It takes no time at all to make this in Bubble.
3. Behaviors with Conditions
There are so many behaviors that require saving data, but for example: How can you test a number limitation flow when you can’t actually store data to the container?
As you can see, it is not possible to make the state where the candidate has selected the max number and the unchecked checkboxes are disabled. Which is the behavior we are testing: will users understand what happened when they try to select more than the max?
We can make a frame where 5 are already selected and when the user selects any available option the alert appears, but that requires hardcoding (designing) 5 selected options which will highly likely be different from the ones selected by the candidate. Jarring. And wrong.
This is what the candidate is supposed to see:
choose any five. Change status when number hits 5. When user selects any unchecked option, they get the alert.
Extra cherry on top? actually reflect the real number as they check and uncheck options.
4. More than one action per click
This one makes me want to cry 😢. Use cases are endless, but here is a simple one:
While testing a delete confirmation popup, we need to close the popup, delete the actual item from the list, and show a success message on the same page when the user chooses “delete”. But we can only do one thing per click.
Other use cases are endless; Create thing and move to page, update info and clear form, open form and set focus to a certain field, incorrect input, wizard where selecting an option automatically moves forward, etc…
Feedback to user action is critical in an experience; it could be the deciding factor on how a user acts next. So it’s not ok to omit it while testing a flow. This is how it should look:
And not just that, you can build any kind of flow using an impressive list of default available actions, not even mentioning APIs and plugins:
5. Component Overrides That Don’t Get Stuck or Reset for No Reason
Have you ever tried making a collapsable sidebar in Figma, where pages are nested components with multiple variants (state, expandable), and icons are also components?
In presentation mode, overrides get stuck in one variant for no apparent reason, sometimes the values are reset, and sometimes placement changes all of a sudden. This causes the component to display wrong information, may very well harm accessibility when the override is a color, not to mention embarrass you the designer in a presentation.
It literally takes less than a minute to add conditions to an element in Bubble, and it doesn’t have to be a reusable component to add conditions.
Again, I am not hating on clickthrough prototypes
I only believe that the right tool should be used for the right purpose. I absolutely love how quickly I can connect screens to discuss a flow with a fellow designer, but I honestly don’t think they do the design justice when we put them in real user’s hands.
A usability test is about imitating the real experience. Otherwise, it’s not a valid test. If you are interested to know more about best design and testing practices, read Mindful Design by Scott Riley. It’s a very valuable book for anyone designing customer-facing products.
Also, I am not paid by Bubble or Adalo or any nocode tool to write this
But I think that since these tools give us the tremendous power to make real prototypes with least waste of resources, we designers have no excuse doing less than real tests with halfway-there prototypes. And we should be responsible for what we deliver as test results.
What do you think?
I hope this doesn’t step on anyone’s toes, consider me a user with real need and I am trying to explain it in this humble post. Have you had any issues with usability testing because of this? Please share.
Until next time. Lots of love! and #keepdesigning
