Jake Doering - Product Designer

Bright | Design Exercise


Bright | Design Exercise

 Photo by  Scott Szarapka
You've been hired at Otis Elevator Company to design the software for their next generation of elevators. The new 1000 floor Acme Building in New York City will be the first customer to install the new system. Design an interface that will accommodate the needs of this 1,000 floor elevator.
Please present the design for your solution and your process for how you approached the problem and arrived at the design.




Defining the problem

Building empathy for users is the first step towards solving a real-world design problem. Making something people want requires understanding their lives, problems, needs, and motivations. However, due to our hypothetical scenario and the short timeframe at hand, I will use basic assumptions in place of the answers that would normally be defined by research. I'll make assumptions minimal, and only as necessary:

  • This elevator is for people (not freight, cars, inventory... or drones).
  • A front concierge/security desk checks in visitors, and directs them to their desired floor.
    • Buildings of obscene heights often house wealthy people and successful businesses: entities that enjoy privacy. There will be no directory in this solution for finding any person or destination in the building. The "which floor?" problem will be solved securely at the first touchpoint: reception.




Needs & goals

Who are the users? All I know is that they are in New York. As such, I can design primarily for English speakers but expect users of any nationality and tongue. They could be blind, deaf, in a wheelchair, or otherwise handicapped. They could be men or women; adults or children. I know very little of our users, so I must design for all users.

What is the primary goal of any user?

A user needs a way to travel to their desired floor as quickly, easily, and enjoyably as possible.




Strategy & principles

Some basic strategies can keep the solution loyal to the need outlined above. 

  • Do not over-design the solution.
    • Using a cool interface is not the user's goal. Getting to a destination is the user's goal. Distracting users with bombastic design will lead to frustration.
  • Do not defy convention unnecessarily.
    • Some users will have lifelong daily experience using elevators. Many will have used them before. Ingrained behaviors are both difficult and uncomfortable to change.
    • Capitalize on existing behaviors by using common design patterns whenever possible.
  • Maintain a bias towards extreme usability.
    • Because we know very little about our users, the solution must be functional for any user.
    • No knowledge or experience is assumed. We especially cannot assume our users love technology for its own sake. The solution must be as simple and universal as possible.




Ideation & insights

Brainstorming and iterating on some concepts led me to a couple insights that simplified the solution.

An early wireframe for part of the interior interface.

Early wireframe for the outside interface.

  • An external interface increases efficiency and solves problems. 
    • Whether the scenario is a standalone elevator or a system (I chose not to assume either), there will be many stops. Requiring a user to choose a destination before entering prevents wasting other users' time.
    • The classic "up" and "down" buttons sometimes confuse users trying to call an elevator. Some aren't sure whether to act based on their end goal, or the elevator's current position.
      • Choosing a floor before calling an elevator eliminates ambiguity.
  • The informational needs of external and internal interfaces are different.
    • External interfaces need to display information relevant to the goals of one type of user. (Even if many people are waiting, they share a common location. Their collective question is "when will the elevator get to this floor?")
    • Internal interfaces need to display information relevant to the goals of many types of users. Each user could potentially be coming from and going to a different place.





External interface, entry level. 

Users waiting for their elevator don't need to see complicated visual representations of the elevator's progress and stops. In fact, with 1000 floors, the elevator's current floor is not even relevant or enjoyable information. 

Don't make the user try to calculate how long they'll have to wait. Just show the ETA.

Tactile buttons allow for braille to accommodate the blind. Deciding against unnecessary touch screens reduces production cost, keeps the display simple, and reduces effort required of the user.

A Clear button deletes the entry if pressed once, and cancels the request if pressed twice (in case of a mistake).

Traditional design patterns are used as much as possible. Users shouldn't have to re-learn how to use an elevator. 

 External interfaces above ground level include a Lobby button to speed up this common use case.

External interfaces above ground level include a Lobby button to speed up this common use case.


The interior interface adds additional info to accommodate:

  1. The new affordances a user will need once inside 
    • Open door
    • Close door
    • Sound an alarm in an emergency
  2. The informational needs of many users with different origins and destinations

A simple, textual interface subverts the urge to over-design with timelines or maps of the elevator's progress. This creates a simpler, less distracting experience and reduces cognitive load for the user.

The new screen highlights action-oriented information, in proportion to urgency:

  1. The elevator's next stop
  2. Time until the next stop
  3. Total time and number of stops
  4. A moving queue showing the next 10 stops, allowing users to cancel mistaken stops