Project Interaction is a personal project where I examine interactions of digital products. I provide unsolicited design feedback on ways to improve usability with a prototype.
— — — —
Prototype Link : https://framer.cloud/rRMYV/
Interfaces are appearing in everyday products that traditionally don’t have them. One example is our target this week, an elevator system with a digital interface. The paradigm is different from a traditional elevator, as the controls are outside the elevator rather than inside it. This brings plenty of advantages, but at the same time raises new problems which I’ll mention. These problems stem from two principles, design affordances and visibility of system status. This elevator problem rings close to home for me, afterall I work in this building a few days a week.
Affordances
An affordance is something that signals to a user about how something may be used. A door handle for example, can be designed in ways that suggest how one may open it. A horizontal bar is less favorable to pull so you should most likely push this door to open it. On the other end, a vertical bar is easier to pull so you should pull this door to open it. Unfortunately many of our doors are terribly designed, but that’s a different problem.
An affordance is a perceived signal or clue that an object may be used to perform a particular action.
With the elevator in LinkedIn, affordance isn’t the biggest problem. There are big buttons for anyone to press correlating with the floors. I did want to do one tweak here, and that is to alter the background image. Anytime a design has a large background image, legibility becomes a concern. There are ways to work with background images, but the question becomes what is the value of the image? The image itself is a picture of our building, but why does one need to be reminded the appearance of the building? So for this proposal I completely swapped out the background image with a blue texture.
Lack of visibility on system status
The primary problems of this interface stems from the visibility of system status. Before providing affordances to cue the user on how to use the system, the question is : do I even need to do anything? In the original design, when a user requests for an elevator, the screen will change to tell you which elevator to get into, and then return back to it’s original state. In this original state, there is no sign that the elevator has been requested. The design relies on the user to preserve the data in their head until the elevator arrives. This leads to two separate problems I witness on a daily basis.
Scenario 1 : A user presses the elevator but proceeds to engage in a conversation with a co-worker. They get deep into the conversation, so much that the user forgets which elevator to head into. They need to press the elevator buttons again to be reminded, that’s an extra interaction that’s unnecessary.
Scenario 2 : Four strangers arrive at the elevator at once, they all are heading to the same floor. They all line up to get access to the buttons, and due to the tiny screen cannot see what the users ahead have pressed. Due to the lack of elevator status, they all press the same button to get the same floor. That’s three additional taps then required.
Design Proposal
Prototype Link : https://framer.cloud/rRMYV/
The first design element to propose is something to show that certain floor buttons are activated. This one is a simple tweak, providing an active state until the elevators arrive. If users can see that buttons are already pressed, they no longer need to “call” an elevator that is already on the way. However, how will they know which elevator to get into? That’s where the second part of this proposal comes in.
The second proposal is creating a group of elevator status indicators on the left side of the interface. When an elevator is on route, one of these status indicators would be created per elevator group. In this design we call out the floors that it will stop at, and provide an icon that provides a reminder where the elevator position will appear. The goal of these design changes is to both help remind users when in the cases where they forget, and to inform users that no additional actions are needed.
That’s it. Two subtle changes (excluding the visual styling) to help address daily interaction problems. The goal of these interaction explorations isn’t to do a complete redesign, but to find small changes in the current structure. As you may realize these are small tweaks, but with these we can streamline the experience. When we design experiences that are used frequently throughout the day, we need to be aware of these small speedbumps we let slip into our designs.
— — —
Hope you enjoyed this week’s entry into Project Interaction! If you’ve enjoyed this feel free to follow me as I continually explore interaction proposals for designs in the world. The rest of these entries have been placed on my website www.projectinteraction.ca.
