Touchscreen Signage
For this project, I oversaw the design of the public facing front end. The UX/UI department I managed collaborated with the development department to figure out the possibilities and limitations of the touchscreens that we were going to use as public kiosks.
I personally did the initial wireframes and the earliest mock-ups as well as the finished comps. Some of the design work in between was done by members of my team under my direction.
The wireframes were done in Balsamiq and Photoshop.
There is a prototype with some of the navigation available here. It was done with InVision Studio.
The finished product has been installed in a number of locations including Karisma Hotels & Resorts.
Wireframes
Some early mock-ups, playing around with layout and navigation possibilities.
We determined a number of things:
The navigation should err towards the bottom of the screen.
We didn’t know exactly how a sign would be mounted and positioned in each instance, but for a portrait oriented sign our testing showed that the lower area of the screen would be more easily reached than the upper area, so we decided the bottom 2/3 should be the limit of the hit area, with the top area non-clickable information. There was also a ADA compliance consideration to this for people in wheelchairs.
The sign is not a phone.
While the portrait orientation made it tempting initially to try to mimic a mobile app, it quickly became apparent that simply blowing up a mobile app to the size of a TV screen was a not very thoughtful approach.
In addition, there turned out to be hardware limitations that prevented us from mimicking a lot of the familiar gestures and navigation schemes from a phone. The touchscreens turned out to have much less precise hit areas and swipe gestures like on a phone didn’t really exist. Also often things too close to the bezel or edge of the screen weren’t very “hit-able.” So where possible we tried to contain the layouts to a single screen to avoid scrolling. If content overflowed, we had to resort to some system of paging, with the navigation not too close to the edge of the screen.
Be consistent.
A fairly uniform layout across pages in disparate areas of the app and consistent navigational methods would be best. This would serve two purposes:
It would minimize the user learning-curve for what is a fairly complicated (at least for a public kiosk) UI that is presenting a lot of different types of information and functionality.
It would make reskinning for successive customers faster, as the same CSS class could be applied to elements that are common across disparate pages.
We settled on a general template of:
A small header bar at the top that would display throughout the app, generally showing a logo, time, and weather.
No interaction.A 16:9 hero image area below it, the dimensions chosen both to standardize the size of content images and because we thought a video would sometimes be embedded in this area.
No interaction.A content or navigation pane which worked out to a nice square at 1080 x 1080 px (at 1920 x 1080) but which would have various layouts depending on the needs of the page.
Interaction.A small footer bar that would display throughout, offering a “back” button, a “universal menu” button that resulted in a bottom sheet of modules, a change languages button and an ADA button that shifted the screen lower.
Interaction.
For the user flow, we settled on 4 main page types. The primary difference between them was the content or navigation pane area.
Home page.
Landing pages (the home page is really just another landing page).
Details pages.
Transaction pages.
The user could drill up and down through the pages via the “back” button, or take a short cut to another module from wherever they were at via the “universal menu” on the footer bar.
As the requirements solidified, so did the UI. Pages were quickly wireframed in Balsamiq with some annotations. The wireframes were then turned into high-fidelity mock-ups.
Home Page
Module Landing Pages
Module Details Pages
Module Transaction Page
Mock-ups and Prototypes
The hi-fidelity mock-ups were annotated with CSS class names for the developers to indicate that a type of element was the same thing on disparate pages, and prototypes were created to indicate the expected behavior.
Below are two different skins that were done for Graton Resort & Casino and Borgata Hotel Casino & Spa.