Back in June, I wrote a rant about the unorthodox and not entirely successful innovation baked into the elevators at the new Times building. As I learned afterwards, they were designed according to a principle of elevator service called destination-based dispatching. The basic idea is that, rather than putting passengers on the first elevator car that arrives, the system routes passengers to the cars that will deliver them to their destinations most quickly.

This approach somewhat upends the traditional way passengers interact with elevators. Instead of hopping on the first car that arrives and punching a button for a floor, a passenger punches the button for her floor first, on a keypad available at the elevator bank. The system then directs her to, say, car number three, along with other passengers heading to the same floor. Once on the elevator, there are no buttons, nothing to push. It’s a little strange. At least the way it’s been implemented at our building, sometimes it works and sometimes it doesn’t.

In Elevator Design, There Are Ups and There Are Downs

I only know that it’s called destination-based dispatching thanks to a comment added by one of my readers: Sara Rahimian, a software engineer who worked for six years at Motion Control Engineering, a company that, you guessed it, specializes in elevator engineering. While there, Sara developed elevator dispatching products and led a twelve-person research and development team for the company, a depth of experience that far outclasses my own when it comes to talking knowledgeably about elevators. (She’s since left Motion Control Engineering and started a fledgling Web development practice of her own called Slick Logic.)

Via email, I asked Sara for more insight into the mysterious world of elevator design. In much the same way that an average user of the Web routinely underestimates what goes into creating a successful online experience, I had little idea of how complex elevator logic can be. It’s fascinating stuff. To me, elevators were always just things that go up and down; for Sara, they’re a science.

Playing in Traffic

For instance, there are four basic modes of traffic: balanced mode, in which up and down calls are evenly distributed throughout the building; up-peak mode, in which most traffic wants to go up (mornings, usually); down-peak mode, in which most traffic heads downwards (close of business, usually); and lobby-peak mode, in which the majority of the traffic goes from the lobby upwards.

An elevator system’s behavior has to be tuned to match the particular pattern of these modes that each building follows. It’s the job of a systems designer, like Sara, to implement learning algorithms and heuristics in software to identify the patterns and adjust the distribution of dispatches accordingly. Everything is measured, even the wait time between calls — both those made from hallways and those entered from inside the elevator.

However, that overview assumes the standard set-up for calling an elevator from a hallway and punching a floor button inside the car. Things get trickier with destination-based dispatching, which explains the long wait times I experienced at the Times’s elevators. Sara explained some of her experience with designing these systems:.

In most cases, I found that an algorithm that minimizes people’s wait times in the hallway can only perform so well because the elevators are not omniscient and need to travel some number of floors to respond to a call. But with proper learning and heuristics they can do very well.

In modes like lobby-peak we had averaged wait times as low as five seconds. And overall in a busy building we averaged wait times under twelve seconds. In most cases, 98% or sometimes even more of the traffic was served in the average amount of time and every once in a while one call would wait forever 60 to 90 seconds (therefore inflating the average wait time).

In those cases, it was almost always because of some buggy scenario that wasn’t implemented correctly. These cases were hard to track but overall that was my job, finding out what scenarios lead to extremely long wait times and making sure the system was programmed to respond correctly.

Destination-based dispatching, then, is an inherently trickier problem than traditional dispatching, but it can be effective. What makes the problem unexpectedly fascinating, though, is that the challenge is no longer completely one of physical engineering efficiency:

Destination-based dispatching changes the name of the game — because the technical problem to solve is [no longer] minimizing people’s hall call wait time, but rather their total elevator involvement time.

The algorithms try to minimize a person’s time to their final destination. But I don’t know how well this concept will work with human psychology. For one thing, people might find it annoying that they stand there while other people show up and quickly get on their designated elevator. People are used to ‘first in/first out&#8217 when waiting for an elevator. They also might find it irritating to hear elevators swishing past them and not responding to their call, although that can happen in conventional dispatching as well.

In effect, we’re talking about experience design. Presupposing a perfectly running, fully de-bugged destination-based dispatching system, it’s the intangible quality of what users are experiencing that becomes the toughest nut to crack. Though the system may in fact be delivering passengers to their floors with greater efficiency, a designer is still left to struggle with the subjective expectations of its users.

Car Four Where Are You?

This explains the frustration that I and many of my colleagues experienced when we first encountered the elevators in our new building. For all we knew, we were getting from floor to floor with great efficiency than if we had been using a conventionally dispatched system. But the problem was that it didn&#8217t; feel that way. And, to be fair, it also probably explains (at least in part) why the elevators have become moderately more acceptable over time.

In the intervening months, there have been some actual engineering improvements to the timing and behavior of the system — at least that’s what I understand, as it’s unclear to me as to what exactly was done. Whatever the case, the system has improved somewhat, or at least our perceptions of its performance have. It seems likely to me that passengers, like myself, have become accustomed to the elevators’ somewhat idiosyncratic behavior; the prolonged exposure and increased familiarity has changed the experience.

Actually, “accustomed” may be too strong of a word, as it’s still not uncommon for the chatter you hear while riding the elevators to focus on misunderstanding the system or being delayed by the system — it’s chatter that’s spoken with bemusement at some times and frustration at others. As it turns out, it’s not necessarily a positive sign of the overall success of your system when your users can’t stop talking about it. It all comes down to experience.