Interactive Television
This interactive television UI was a real workhorse of a “white label” product for which I designed the front end. We re-branded and re-used it for about 40 clients on an even greater number of properties - primarily cruise ships, resorts and hotel-casinos. We designed the initial system way back in 2008 and it went through quarterly revisions and enhancements up until at least 2019.
Being navigated via a remote control, there were some interesting challenges that you don’t generally run into in other interfaces. These determined a lot of the layout and user experience.
In an app or a website, anything can be clickable, the user can easily tap or move a mouse to any spot on the screen, and nothing inherently needs to be selected or have focus.
With a remote on the other hand, the most intuitive navigation limits you to up / down / left / right and select. (In some cases we used additional special buttons for some functions, but this generally requires those buttons to be explicitly called out on the screen for the user to be aware of them.) This means:
The focus or navigation highlight always has to be somewhere, selecting something.
The user always needs a very clear indicator of where they currently are, and where they can get to from that position, so they don’t get lost or stuck.
Getting from one place to another potentially requires multiple remote button presses which makes for an irritating user experience, so we need to find ways to minimize that wherever possible.
Also with an app or a website, you can have some confidence that the user will take a little bit time to find their way around and discover features and functions that aren’t immediately obvious, and there are certain familiar UX / UI tropes that help minimize the users learning curve. (Think the hamburger menu button, for example. Not terribly intuitive in many people’s assessment, yet everyone now knows what it means.)
With the interactive television system in a vacation environment, we had a much smaller window to engage a user - that if the guest couldn’t figure out what they were doing in a couple of minutes, they’d give up and likely not return to it during their stay, which on average was a week. In addition, when we first designed this system there was nothing else much like it to give it any kind of familiar UI language to the user - this was at the very beginning of digital streaming devices becoming commonplace. As a result, the UI had to be as intuitive as possible.
To solve some of these problems we came up with the following solutions:
Clear focus and explicit navigation options.
We came up with a navigation highlight (generally skinned in a bright contrasting color) that is always present and tells the user where the focus currently is. Generally throughout the system if something can be highlighted it can also be selected and have something happen.
We attached up / down / left / right arrows to the highlight that display contextually as you navigate, indicating the possible directions in which you can navigate from wherever you currently are. They are meant to echo the up / down / left / right buttons on the physical remote.
Removing extra work for the user.
We tried to minimize the number of remote button presses required to get from one place to another. This was oftentimes analyzed and addressed on a per instance basis (i.e. is there some action a user is going to do repeatedly that would warrant the focus defaulting to a different starting point). But in general it meant:
Deciding if a page was better served by horizontal or vertical navigation, considering the layout of the other page content, what the page’s function was, etc.
Then dividing the page up into as few rows or columns (generally striving for two at most) as possible, so at most the user was two or three remote button presses to navigate between wherever the focus was upon entering the page to the “deepest” part of the page.
Once you were in a column or row of items (a list room service items for example) it was a theoretically endless list of items to scroll through, but you didn’t have to scroll through the whole list to get to other actions or a “back” navigation. You simply navigated out of the items column to the next column.
Certain fixed navigation areas that appear throughout the system, to quickly “teach” the user how to navigate, like a footer area that always has a “back” to previous page on it.
Redesigning the Main Menu
The original main menu was a looping carousel of module tiles. It was pretty simple and intuitive, but it was also pretty static. In addition, it only showed 5 modules on the screen at a time, with partial hints of a module tile going off the screen on either side to give the user the clue that there was more they weren’t seeing.
We discovered that if there were more than 15 modules enabled, the user would kind of get lost in the carousel, feeling like they were never reaching the end of the loop. (The system supports more than 30 unique modules and some of the modules, like “General Information” could be repeated as unique instances with different names and different content in them.)
As such, a few years ago we decided to revamp the main menu to make it a bit less static, find a way to support both a few modules tiles or a lot of module tiles on the screen at the same time, and lift more information up to the top level for the user but still present it in a uncluttered and attractive way.
To be able accommodate properties with just a few modules as well as properties with a lot of modules, we ended up with a mosaic style grid of variable width tiles in a module panel.
The property could control the module tile with and module order / layout via the CMS.
The tile widths could range from 1 column to 4 columns.
This meant a property could show as few as 3 module tiles and still fill the module panel or show as many as 12 module tiles before the module panel had to start scrolling.
To make the main menu a bit more useful and to present more information at a top level, we did a couple of things:
We reserved a space on the left side of the screen to display module data in various layouts, which we called the “live panel.” The property could use this area to show a bullet list of the next handful of scheduled activities or the upcoming items on a guest’s personal calendar, or use the area to promote various individual items from within certain modules like shore excursions or pay-per-view movies, thus promoting browsing of those modules and driving purchases. The items could be scheduled by the property via the CMS and would rotate in the manner of a slide-show. Additionally some had actions attached to them, like the ability to initiate a video associated with an item, or for the guest to request to be contacted about an item.
We also added the option to have some modules’ tiles display module data on them in the form of “live” tiles. For example the shore excursion tile could display the first couple of tours for the next port of call.
I believe the end result is still a very clean, intuitive and uncluttered UX but offers an-order-of-magnitude more information and utility to the user. In the actual production screenshots below, you’ll see examples of both versions of the main menu skinned for various clients.
