Yesterday, I got a hankering for a burrito bowl and went down to the newly-opened Chipotle in the next town. The line was somewhat long, but I was already committed to the experience, so I queued up. After a minute or two, it became apparent that the line was barely moving because a woman at the front of the queue was ordering 6 burrito bowls and a regular burrito. I felt a sudden rush of anger build up behind my eyes; but, rather than give into it, I used it as a Product Design lesson. I'm just a User and I'm having a bad user experience (UX). But, why? The best reason I could come up with was that Lines / Queues have a certain affordance; and, when that affordance doesn't match a user's experience, it is met with a residue of resentment.
| || || |
| || |
| || || |
In the realm of user experience (UX), affordance is the idea that the form and appearance of an object should indicate what kind of actions could be performed with that object. In a software product, this means that things that look clickable should be clickable; and that short input fields require short values; and that huge textareas require long-form prose; and that anything scrollable should have a visible scrollbar or overflow indicator.
But, physical-world products also make heavy use of affordance. Doors are a wonderful example of this. The existence of a handle can indicate whether the door is a Push-to-open or a Pull-to-open door. And, the type of handle can indicate whether or not the handle needs to be turned in order to engage a bolt mechanism.
Lines (or queues, depending on where you're from) also have an affordance. They indicate wait time. This wait time isn't derived from some mathematical formula that the user is calculating in their head - this wait time is derived from pattern matching. Pattern matching that the brain can do after having spent a life-time of waiting on lines and building sophisticated mental models.
| || || |
| || |
| || || |
Since waiting-on-line is an inherently social action, the affordance of line-waiting necessarily depends on an unspoken social contract. That we, as members of a shared society, have agreed upon what is and is not expected line-waiting behavior. And it is only because of this agreement that we can build our mental models and that we can grant affordance to lines.
This is why we get frustrated with the construction worker who orders 18 coffees for his morning crew; and, we get frustrated with the woman who orders 6 burrito bowls for a group of co-workers; and, we get frustrated with the man who brings a full-size shopping cart to the self-checkout line. These people break the social contract and destroy the affordance of lines. They throw chaos into an ordered world and upend expectations. And, as a user experience designer, I can tell you that any time user expectation doesn't meet user experience, people get very frustrated.
Looking For A New Job?
Ooops, there are no jobs. Post one now for only $29 and own this real estate!
All this being said: what would be your UX solution to the Chipotle dilemma?
- A seperate large-orders counter?
- Manditory call ahead on orders over a certain size, pushing those users into a more catering-like experience?
- An express counter for users that have single, uncustomized orders?
- Designate "float" employees that work both food and counter (utilizing proper sanitation protocols between them, natch) to fork and run parallel tasks that are causing locks that degrade performance?
Incidentally, Chipotle Hyper Threading is the name of my Red Hot Chili Peppers cover band.
That's a great question. The obvious problem is that there is a single point-of-failure in the ordering process. In other establishments, this is overcome with multiple lines or multiple checkouts. But, in Chipotle, since the burrito / bowl preparation is an assembly line process, it's hard to think of a way to make that redundant (since it would require so much more space to work with).
I like your ideas. I think having people call ahead is going to be difficult because people won't know that until they get there. I think the idea of "float" employees makes the most sense. Perhaps instead of passing the order down the line, each order sticks with one employee and that employee takes it all the way down the line, skipping over slow orders where possible.
But, that could be difficult to implement and / or make safe and easy (ie, don't drop orders on the floor, etc).
It's a difficult problem to be sure!
"Chipotle Hyper Threading" ... that's great :D