A lab study compared two versions of the same recommendation app. The features matched. The interface did not.

A team at Universitas Brawijaya built an Android app that recommends food. Then they built it a second time with a deliberately different interface, and put both versions in front of users to see which one held up.

The two versions were named GoEat and LetsEat. They offered the same recommendation feature, but each solved the input problem differently.

Testing ran in a controlled lab with five participants, following the common recommendation for early usability work. They were undergraduate students aged 20 to 26 and regular Android users. A smartphone was mirrored to a PC, while audio and video recording captured faces, fingers and voices at work.
Two methods ran together. Concurrent Think Aloud asked participants to speak their thoughts while using the app, which shows where confusion starts. The System Usability Scale questionnaire collected a score afterwards.
Almost everyone finished the tasks, so the app was not broken. Trouble concentrated on the second task, choosing food alternatives. Some participants never realised the control in front of them could be scrolled, so they stopped looking.
That fault hit GoEat harder. Its flow based input had a lower completion rate on the second task, 80 percent against 100 percent for LetsEat. The team sorted errors into input errors, navigation errors and comprehension errors, then used first and second attempts to gauge learnability.
The conclusion is narrow and practical. Reaching for an uncommon widget to collect user input costs usability, even when the feature underneath works exactly as intended.
Az-zahra, Pinandito, and Tolle (2015). Usability evaluation of mobile application in culinary recommendation system. 2015 IEEE Asia Pacific Conference on Wireless and Mobile (APWiMob).