BuDS Cash Register User Interface Critique
As a carts supervisor for BuDS (meaning that I work at the food carts in buildings around Brown), I interact with the the BuDS cash registers very frequently — both when I’m working and when I train other workers.
The main screen of the register can be seen in Figure 1:
This screen is actually not too bad, in my opinion, but there are a few things I would definitely change. The first is the button in the lower right corner featuring a bear holding a balloon. This button is problematic for a few reasons — it switches the computer to an older operating system that no one ever uses, and a bear with a balloon is not really indicative of any cash register function, let alone this one. Therefore this button has both 0 learnability (I only know its purpose because I was told), and impedes the user experience, because once it’s pushed it’s difficult to return to the correct OS.
Another issue with this interface is the return process. To make a return, a supervisor/manager starts by pressing the “Manager” button, which leads to this screen:
Then, they must press “Return”. However, upon pressing this button absolutely nothing happens on the screen — to continue the process you must hit the back button and from there go through a few more steps. The issue with this is that if nothing happens when a button is clicked, the user may think that nothing has happened and click multiple times, or just give up on the operation. I’ve been taught multiple times how to do a return, but because it’s such an unintuitive process, I often forget. Thus, it seems like both the learnability and memorability of this aspect of the UI are low.
I would change this interface by moving the bear button — perhaps to the “Manager” screen, and making it smaller. As is, it’s pretty large and located under two important, often used buttons (Hot Beverages and Beverages), so it’s easy to accidentally press. I would also make something happen when the “Return” button is pressed — probably have it switch to the screen where the following return operations are done.
Strangely, I don’t think there are many constraints to this design, because it would have been easy to design both of these elements differently. It’s possible that the bear button was once used often by BuDS, which would explain its prominence. Even still, I don’t see the correlation between a bear with balloons and changing operating systems. Perhaps the system hasn’t been updated due to cost, time, and effort constraints, as I know that these can be issues in BuDS.