Ozo Lounge Elevator

One of the major interfaces in the Ozo Lounge Experience. The initial launch of this side of Blaston had a single bar, that could hold 8 and had no instancing or ability to create private rooms.
We needed to create an interface for an elevator that could be intuitive, and give the player choice of how they wish to socialize!
The initial brief was that the interface had to:

Show available rooms, each room was on a floor of the building.
Show players inside the rooms
Allow the user to join a private room, entering a number that exists would join that room, entering a number that doesn’t exist would create a new room.
Show occupancy of the rooms.

With this brief of the functionality that the team wished to support, I went about exploring interfaces. Since this was an elevator, I thought that using realistic language and affordance of existing elevators would reduce the cognitive load and immerse the player much more to this interface. Since the Ozo Lounge area uses physical touch to interact with interfaces, we knew this would be a 3D interface.

INITIAL EXPLORATIONS OF WAYS TO APPROACH THIS INTERFACE

My workflow always starts with a pitch of ideas of how the problem can be approached. In this case, an elevator pitch. These ideas are always high level, looking more at solving the high-level problems, and upon the team review, we select the direction we feel the best to make a candidate!

In these explorations, I was looking at traditional buttons like an elevator control panel, or more of a flatter touch screen feel.

Varying the information shown for each room, “should we show only number of occupants rather than name?”, “if we separate the bars by the rank of the players, would this segregate our player base?”, “Can we reduce the information to simpler forms that are present on elevators already?”, allowed the team to tighten the constraints of the interface functionality based on the tech we were investigating.

After this, we had updated our criteria to explore:

Show available rooms, each room was on a floor of the building.
Allow the user to join a private room, entering a number that exists would join that room, entering a number that doesn’t exist would create a new room.
Show occupancy of the rooms.
Quick access to ground floor to exit the building from inside a room
Players are in rooms together, with larger rank groups together to ensure rooms fill up.
A new public room is created only after the previous one is 80% full.
Private Room should open a room code number pad. 4 numbers to enter.
Since the player uses the elevator from the bar to go elsewhere, the current floor is needed.
Loading State for slower connections
Error state for server connection issues
Error state for room not present.

The team also felt the first design and 6th design were in the right direction as we wanted a touch screen interface. We wanted to explore a thin version of the interface and wider interface for more information.

Iteration 1 on the wireframes focused on scrolling through the available rooms. Luckily each of the explorations had elements the team liked that tackled different problems. This iteration started to bring these together. The left side of the interface would house the main functions of the elevator and current floor number. This would be used for joining a private room or leaving the ozo lounge, since this area would show you where you are, and allow you to go back a step once you interact with something on the right, it was akin to a navigation panel.

On the right, the room information was shown. The floor number, who was in it, and the logo of the bar itself would allow the player to choose where they wanted to go. Clicking on a room would show the loading state of “moving” the elevator. Clicking on the private room button would bring up the keypad. If an error occurred during the loading, the same dialog would update to tell the player the error which just occurred.

After showing the team the iteration, there was an evolution in the bar-select idea. There was a second bar scene being made, and the level itself would be used for every bar on a certain floor.

So the new constraints were:

Each floor is a bar type with certain look and activity. There would be rooms on these floors which were the instances of bars. These would have a room number similar to a room in a hotel.
The player should be able to create their own private and public room.
Player can browse rooms on each floor and join.

And so began iteration 2…

After showing these two versions of ideas, one where the user could browse rooms and floors on the top level, and one showing the floors only and rooms once you select a floor. I showed the team once again my ideas! The second idea I played with a physical representation of moving floors similar to an elevator, which I thought would be a nice little moment as the loading was happening.

The feedback was a mixture, the team really liked these versions! Showing the activities on the front level so the user’s could see what each bar was about was really liked as was the loading state. The team thought the wider format as the first wireframe set in this iteration would feel best, so I had to merge these into the final iteration!

And so began the final clean up of wireframes for localization and copy! Before handing over to the artists who will make the UI Art, I make sure all localization and limits are defined in the interface. The gallery above shows the main states of the interface. I updated the user flow of how these worked for the developers implementing it. Below is a video showing the final interface! With the sound and look, the elevator feels like an actual elevator, which was great seeing the players use it after launch!