Are you making this restaurant service mistake when you code?

I visited two restaurants recently, and realised both made a common mistake. It made me feel frustrated, and generally unhappy about the experience. So what did they do?

They made it unpleasant for the customer (me) to buy and eat their food on their premises.

Case study 1: The Coffee Bean and Tea Leaf

Every weekday, I’ll go to the nearby Coffee Bean restaurant to take my breakfast before going to work. (The reasons why I do this is too numerous to explain. Perhaps in another post…) Recently, I started hearing some grumblings from the staff about students. It’s near exam time, and the students come to the restaurant, order a drink, down it to about halfway, and then sit in the restaurant for hours on end, supposedly studying.

The infuriating thing is, the students will come plop their stuff onto the tables and seats. Each student will effectively take up a four-seater-two-table place. If they’re happy, they might even share their table with another friend.

Now during peak hours, this is unacceptable to the restaurant. It is potentially losing four paying customers for one lousy-cheap-drink student. More importantly, I can’t have my chocolate brownie and Earl Grey tea on my off day weekends because of those students (there I’ve said it).

So the restaurant staff came up with a plan. One day, when I arrived at the restaurant for my breakfast, I felt a bit funny walking towards the ordering counter. Then I realised it. They’ve rearranged the tables and chairs.

All the tables were separated into single islands of one table with two chairs. They told me it was because of the students. It was a bit cramped actually, because the restaurant floor space was now reduced. I had to maneuver carefully to avoid spilling my tea.

I asked what if the students pushed the tables together. They said they’d tell the students they’re not allowed to join tables. After a few days, I asked them the results of their tactic. It seemed to have worked.

Now for the problem. Though aggravating, the students still represent a small percentage of customers. Why are they making all customers to have an unpleasant experience? From the front of the restaurant, the view looks kind of daunting, militant, uninviting even.

As immediate (and satisfying) as the table separation solution was, the long term solution should come from a management perspective, a design perspective.

Case study 2: McDonald’s

My nearby McDonald’s just underwent a renovation. Now it looks brighter, more woodsy-brown, different from it’s previous Hong Kong movie stars and music scene theme. The restaurant management also restricted the cashier line to just one, when they have three perfectly working cashier machines.

I’m guessing they’re trying to improve efficiency, since the staff at the sole cash register is working like crazy to get all the customers’ orders in. A receipt is all that represents the customer, which is pushed to one side while other staff scramble to fulfil the order.

This is like a multi threading problem, where before there’s three cashiers taking and fulfilling orders, and now there’s just one cashier taking orders with multiple staff fulfilling orders. In both cases, an attempt is made to move through the order taking and fulfilling process as fast as possible, in as parallel and concurrent a method as possible.

In theory, that should work. In practice, the user experience suffered. I would much rather that the one staff taking my order goes through all the way with fulfilling my order as well. Sure other staff can help out, but I want the same person serving me.

In the new method, my order was taken, and then I’m shunted off to the side, like some tool whose usefulness was spent. I don’t know who’s getting my drink. I don’t know who’s getting my burger. I don’t even know if anyone was doing anything for me. It sucks.

The coming together

When you go through your project requirements document (you do have one right?), do you simply want to get a certain function done, without giving any thought to how a user would experience it? Sure all the buttons are there, and all the display controls are there. But is it intuitive and easy to use?

I recently had this user explain to me how a screen from a legacy program worked. The sequence where she clicked buttons and checked output made no sense to me. She clicked a button on the bottom left first, then checked some data display, clicked another button on the top right, checked some more display, and clicked a button that was above the first button.

There was absolutely no logical flow to perform the task. Yet my user followed this pattern and was astounded that I had no idea how and why it worked. The user had conditioned herself into a negative usability pattern because there was no other way. I went back to my office, silently swearing at the programmer who originally coded the program. I swore even more after I saw the code…

Why was the user being subjected to this kind of service? As programmers, our users are like our customers. We should be treating them well, even if they aren’t paying us.

Are you making it hard for your users to use your application?

Sorry, comments are closed, but you can contact me directly if you like.

Trackbacks

  1. […] a loyal customer of Coffee Bean, despite a small grudge in the past. They have this cool Coffee Bean prepaid card, which I have. It doesn’t give […]