DESIGN
Our project describes an elevator system in which floor selection is moved outside the elevator, to the lobby. Because this is such a drastic change to a very established protocol for riding an elevator, our interface needs to be intuitive enough to 1) signal to users that this is an alternative elevator interface and 2) train them how to use it. We accomplish this with a three-part interface.
The first part of our interface is the floor selection kiosk in the lobby. It is the first thing the user encounters when entering the elevator lobby, and its button layout is identical to the buttons inside a traditional elevator. Pressing one of these buttons will summon one of the available elevators to the current floor, and assign it to the selected target floor (among other existing target floors, potentially.) Once a button is pressed, it glows with a color that corresponds to the summoned elevator. It also temporarily displays a letter that corresponds to the elevator, to remove ambiguity for the colorblind and in cases where there are many elevators. A screen at the top of the panel displays a map of the elevator lobby. When one of the buttons is pressed, a colored route is overlayed on the screen, directing the user toward the elevator that has been summoned for them.
The form factor of this panel was heavily debated in our early planning. Having it be so vertical may limit the number of users that can concurrently access the panel, if the lobby is crowded. We developed a horizontal version of this, but it wasn’t recognizable enough as an elevator floor-selection panel. Given that our primary obstacle in this project is training people to treat this panel as a floor-selection panel, we opted for a familiar vertical button layout.
We also had to decide whether to use colors or letters to identify elevators. Using colors would allow users to identify their elevator from a distance. Colors are also easier for users to remember in the short term than letters, which is why they are used to distinguish floors in parking structures. Letters, on the other hand, remove all ambiguity in the case of a building with a very large number of elevators. They are also more accessible to the color-blind. We opted to use both letters and colors to represent floors. While this slightly confused one of our testers, the benefits of using both letters and colors are worth the slight decrease in simplicity.
IMPLEMENTATION
Three interfaces make up our elevator system, one for the lobby, one above the elevator, and one inside the elevator. For clarity, we have grouped our implementation details by the relevant interface.
Lobby
In our lobby interface, we have a box that represents the interface that would be present in a physical version of our system. It contains a button for each of 10 floors. When these buttons are pressed they light up in one of four colors and the number of the button is temporarily changed to the letter of the elevator they should enter. At the same time, the map at the top highlights a path in the appropriate color to the correct elevator.
Because we built a web-based prototype of a physical system, we found it necessary to include additional elements to simulate the experience of actually using our system. In the lobby we included a “Done Selecting Floors” button. This allowed users to indicate they had finished their floor selection and would like to move on to the next task. In real life, people would simply walk around the interface. We also included a “Return to Floor Select” button for similar reasons. In real life, people could walk back to view the interface again if they needed to remember what elevator they should go to or wanted to select a different floor. Finally, we included a picture behind our lobby interface of an actual lobby so users would feel that they were in an actual lobby to the greatest extent possible. When a user indicates that they would like to stop selecting floors, the interface disappears and a click handler is bound to the background lobby picture to allow users to click on the elevator they would like to go to.
Above the Elevator
In our above the elevator interface, we have an arrow to indicate the current direction of the elevator, an estimated time of arrival so users are informed about their current wait time, and two displays of the floors the elevator will be going to. One display has a scrolling message of the floors the elevator will be serving. The other has a series of buttons corresponding to the floors that are lit in the elevator’s color if the elevator will be stopping there. This is designed to be seen from farther away since the frequent users will know the location of their floor among the buttons.
To simulate real use of the system we included two background pictures of elevators. When the user is still waiting for the elevator to come, the doors are closed. When the elevator arrives the second picture of an elevator with open doors appears. This gives the user instant, realistic feedback about what our physical system should be doing at each point in time. To allow the user to indicate that they would like to enter the elevator, when the elevator doors open, a dialogue box is displayed which presents the user with the option to enter the elevator or stay on the current floor. In a real system, the user would simply walk inside. We also include a button to return to the floor select interface so users can change their floor selection or walk to a new elevator if they ended up in front of the wrong one. In a real system, the user would simply walk back to the lobby interface.
Inside the Elevator
In our inside the elevator interface, we have a display that shows each floor the elevator will eventually go to with an estimated time to arrival. We also have an emergency exit button clearly labeled. The emergency exit button allows users to stop the elevator to get off should the need arise, but users are deterred from using this to simply travel to their floor by an alarm.
To simulate real use of the system, upon arriving at each floor the user is presented with an option to either exit the elevator or stay inside. In a real system, the user could simply walk outside the elevator.
Usability Problems Caused by the Implementation
The biggest implementation related usability problem we encountered was the fact that people were not expecting to need to click other buttons to switch between interfaces. Most of our users noticed the buttons and since they were clearly labeled, they were able to figure out how to proceed fairly quickly. However, some of our users overlooked the buttons at first and were unsure what they were supposed to do after selecting their floor(s). After they had noticed the first button, they were much more conscious of the fact that these buttons might appear elsewhere and they did not have trouble finding and using subsequent buttons.
EVALUATION
Users:
User 1: Female junior
User 2: Female graduate student
User 3: Male senior
Our users have all frequented crowded and busy elevators on a regular basis. Because most students have worked or lived in tall buildings with busy elevators, we found users by emailing around 50 people and observed the first few people who expressed interest in being users. After the user testing process, we asked each of our users about their elevator experiences in the past. All users said that they used elevators at least several times a day. Examples of elevators they used were the elevators at the Stata Center and in the Green Building
Briefing:
We created a new elevator interface. We’re going to walk you through a few scenarios and look at how users will interact with our new interface. If you want to stop at any point in time, just let us know. Imagine you’ve just walked into a high-rise building that has 10 floors. Yes, just pretend that each floor is really tall. You walk into the lobby, and there are 4 elevators — 2 on the left and 2 on the right. You see this display (show interface of main lobby display). This display is found on every floor.
Task 1: You walk into the building, and you have to get to a job interview in 3 minutes on the 6th floor. Get to the 6th floor.
Task 2: Now the company is sending you down to HR on the 3rd floor. When you get to the elevator, there is someone there also going to the 2nd floor.
(once in the elevator)
One other person is in the elevator with you. And he has a panic attack and needs to get out immediately.
Task 3: Now you get to go home! You need to get back to the 1st floor to leave the building.
(There are multiple people on your floor going to multiple floors in your building. The elevator going to floor 1 is also being assigned to multiple higher floors - basically this means that the elevator is going to go up before going down to the 1st floor)
Justification of briefing:
The briefing was done similarly to the first round of user testing with the paper prototypes. The basic set-up was the same, but we added more complexity to the tasks since we implemented more features and the features were associated with certain interactions.
In task 1, we wanted to see how a user would use the interface in the lobby to get to their desired floor. In task 2, we wanted to see wanted to see how a user would react to an emergency situation when in the elevator. We wanted to test this because one of the responses we received was that people were unsure of what to do to get out of the elevator in an emergency situation. For task 3, we wanted to see how a user would react when their assigned elevator was assigned to go up before going down to their floor — we wanted to see whether a user would get into the elevator early, go up and then go down, or wait for the elevator to arrive on their current floor a second time and just go down. This was a test for our interface above the elevator as well as the interface inside the elevator.
Usability problems and solutions:
Problem: The flashing between the floor number and letter representing an elevator on the lobby display was distracting and confusing. Two of our users questioned whether the letters and colors were associated.
Solution: We couldn’t just get rid of either the colors or letters. For a majority of the users, the colors would probably be fine; however, we wanted to have letters so that people who were color-blind wouldn’t have trouble finding their elevator. We discussed two ways of solving this problem. First, we would make the animation of the button changes smoother — more fading rather than flashing. Second, we would also create a key on the screen at the top of the display — each letter would be placed on top of or next to a colored box. This would make it more obvious that the colors and letters were associated.
REFLECTION
1. Through the design process, we had to learn how to pick which user complaints to deal with (since some feedback conflicted and some were tied to the fundamental idea of our elevator and were more removed from just straight design). Some of the heuristic evaluations from others in the class touched on aspects of our design that were directly related to the entire idea of our elevator. For example, many users said that they preferred to pick their floor inside the elevator like in a normal elevator and found it confusing at first glance since our elevator looked different from what they were used to.
2. Some of our user feedback conflicted and we had to learn how to balance concerns.
3. We found the paper prototyping to be less useful since we were designing a more physical and less virtual product. During the paper prototype testing, it was difficult to simulate the feeling and idea of an elevator lobby. We found ourselves using a kitchen for a lobby, kitchen cabinets and fridges as elevators, and then ourselves for structural supports (as we were holding up our prototypes). The paper prototype was useful for smaller design issues (like the ordering of numbers on the displays), but less useful for determining behavior when a user needs to go to a floor and finds him or herself standing before a display in a crowded lobby.
4. Through the design process, we found that we needed a more physical model to test some of our design issues. Creating a web app to simulate an elevator experience was better than the paper prototype because we could use more real visuals to represent physical objects. However, it still didn’t let us see if a user would actually stop by a display in the lobby and know when to step away and find his or her elevator. With our web app, users were mostly guided between our displays, so we couldn’t test what a user would naturally do.