My Role

As the UX/UI designer of the team, my role was to design the interaction between the hardware and the user; to understand the needs of the user of the keg; and know what kind of feedback the user needed from the device.

The Research

The research was divided in three fronts, first what other apps were doing with kegs, second, what kind of information were presented to the users on the screen, and third what kind of users would the device have.

During the research, an open source app on android, was discovered. This app tracked the level of beer kegs. For the user interface, this app, used lists and icons w to show the different keg levels and types of beer. Not many other apps did something different from this, but the goal of all of these apps was more tracking the level of the beer kegs than actually controlling the flow, or track the visits by user.

It was very important to pay attention to the use of the Iced Coffee keg. Considering that currently the keg was not controlled, adding a device should not be a nuisance for the user. Different timed observations were carried out with the uncontrolled keg. What was concluded was that users took between 5-7 seconds to fill a cup. The fluctuation of time depended on the size of the cup, how hard the user would pull the lever, and the amount of gas pushing the liquid up. Some users, wanted to ‘top-off’ their cups, adding between 1-3 seconds to the initial count.

The Design

Knowing what kind of user I was designing for, provided me with the opportunity to understand how the device will interact with user. I imagined an experience that would feel seamless to the user, almost as if the device was not there, that the added step of tapping the ID would not impede the easy use of the keg.

THE USER FLOW

The user flow was designed with as few screens as possible, so the device would be ready to use almost instantly between each visit to the keg. Once the ID tag is tapped on the RFID reader, access is granted or denied.

THE USER INTERFACE

For the UI, after making a set of low-res mockups, it was clear that information facing the user needed to be as practical as possible. It was also necessary to change different elements in the UI as the delivery schedule got closer and one important part of the device had to be left behind. The UI was then suited for the the prototype that was going to delivered at the end of the internship, keeping it clear and succinct, with only a few elements on the screen.

The welcome screen will have show the type of coffee that is currently in the keg, and an invitation to the user to ‘please tap badge’. Once granted access, the screen will show the name of the user, and a timer. This timer has two uses, the first one, it will inform the user that the app and device are running that has not crashed. The second one, it shows that in a certain amount of time the device will lock again, and no more coffee will flow from the keg.

In order to facilitate the use of the app, an administrator side was designed to display different information that the app was tracking, such as visits and how long the keg would last. The administrator side had an option to input or change the type of coffee in the keg, which was important because it will show in the welcome screen. The design had different revisions, trying to find the best way to display the information, and the type of information that would be important for the administrator.

The Prototype

My group delivered at the end of the internship a working prototype, that controlled and tracked the flow of liquid. It did so, by opening and closing a ball valve, to control the flow. The app also received information from an RFID reader. All of this was working on Raspberry Pi running Windows IOT.