Tag Archives: Usability

Engineering for usability: Vending machines

Today, I used a vending machine. Anyone that has met me will surmise that this was obviously not my first attempt to purchase an unhealthy snack from such a contraption. In fact, not only have I excessively used of vending machines, I’ve written code for kiosks that use the same currency and coin accepting hardware as vending machines. Suffice it to say this long paragraph was meant to proclaim my self-appointed title of “Certified Vending Machine Professional” (CVMP).


However, with all of my years of experience, today’s experience was different. Today, I approached the vending machine, tired from lack of sleep the past month, distraught over having to get my cat a permanent tracheotomy, cranky from a back problem, and distracted by tons of work-related issues running through my head. I carefully stood in front of the machine contemplating what I would get this time — as though the product selection would have changed between now and the last time I looked. Well, I am supposed to be on a diet, but due to the massive amount of life-issues I’m having at the moment, I decide a “healthier” vending machine snack of pretzels will suffice this time. “D10, 65 cents, ok.” I think to myself as I begin to press the numbers out on the keypad “D, One, Zero — CRAP!”. As it turns out D-10 expected me to press D and then press a key they had specifically set to 10 — not 1 then 0 as I was thinking. I knew this. I’ve used enough vending machines in my life to know how they work. But today, I failed the test. I immediately began to blame the vending machine and started re-engineering a smart vending machine in my head.

Here were the problems I saw with the current design.


  • The keypad was placed at the bottom of the machine, forcing me to bend my already soar back over to press the numbers. I’m not exactly tall but these numbers were way the @#$* down there!

  • The vending machine made me bend down even further to retrieve my calorie-clad selection from a bin.

  • The numbering / item selection routes were flawed with that D10 vs D1 conundrum.

  • The selection sucked

  • They only accepted cash or coin which I often don’t carry.

The “lets design something cool” personality in me immediately started thinking about solutions to this problem.


  • Put a camera on the vending machine that recognized the height of the customer. The vending machine should immediately raise or lower the keypad based on the user’s height.

  • Place the items on a selection belt where the item is dispensed into a bin and procured to the user at a height that’s reasonable — again based on the height of the user requesting the product.

  • At the minimum, remove single-numbered selections and replace with all double digit numbers — force the user to press the number sequence out. At best, prompt the user to press “submit” when they are done selecting their item number. Don’t automatically dispense the product based on the first match of a selection.

  • Provide a digital feedback center where you could request the vending machine carry your favorite flavor of twinkie.

  • Place a credit card slot on the machine

But then the “practical architect” personality interjected with complaints to these solutions. First off, lets think about this. Who is the customer of a vending machine. Was it me? Surprisingly, no. The vending machine “customer” was the company who bought it with the intent to make a profit from it. Sure, I may use the vending machine, but ultimately, its the vendor that wants the mechanism that accepts payment and dispenses product. We unwittingly provide our services as testers of the product and give feedback on it (based on our use or non-use of the product). That whole argument is reserved for another post though. Blindly accepting my argument that the vendor is the customer of a vending machine, your next question is to ask, what are the vendor’s requirements for the machine.


Using a lose set of some of those spiffy PASS MADE criteria from the MSF exam (70-300) for your MCSD, lets take a look at those requirements.



  • Provide a fast transaction from which a user can request a product and get out. Quick response to user request for product.(Performance)

  • Provide a usable interface from which to conduct unmanned transactions. (Accessibility)

  • Provide a safe way to keep money received from the transactions. (Security)

  • Provide the ability to easily add more product to the machine — for those of you that don’t know this, they actually can add additional slots next to the vending machine without adding additional currency acceptors. (Scalability)

  • Provide a mechanism that works nearly every time with little intervention required by the vendor. (Maintainabilty)

  • Provide 24/7 access to any would-be customers. (Availability)

  • Allow these items to be shipped easily without fear of breaking during transit or movement from one location to another (Deployability)

  • Allow alternate methods of payment, exchange of hardware, and various types of product to be dispensed. (Extensibility)

So lets apply these characteristics to my “solutions” from above. We’ll find out these were not solutions at all, but fixes to perceived problems from a single-minded personality. My Architect (as I’ll refer to that voice in my head), says this.


The product isn’t on a belt because the time spent between asking for the product and obtaining it could potentially take a lot longer (Performance). The keypads were not arbitrarily placed at waiste level to tick me off, they were blatantly placed there to provide easier accessibility to those who are height-challenged or otherwise requiring accessibility. The credit card reader isn’t placed on the machine because it would be too easy to intercept. These vending machines can be placed anywhere, and sometimes in really poor choices (rest areas, for instance). While having a vending machine broken into would be bad, having credit card data compromised from one of these locations would be worse. (Security) Placing the items on a belt would make it harder to provide additional items in the physical range of motion of the device. It would be harder to add more product to the machine this way — and much more expensive (Scalability). Those devices would also have a large amount of moving parts that could break. Putting the keypad on a moving device as well as the product would reduce the useful life of a vending machine while raising the cost of it — bad for any investment. It would also be susceptible to significant breaks and massive amounts of upkeep (Maintainability). Putting these items in a bad area would be an even worse move. They would be much more expensive to replace and fix if someone vandalized them — much more, that is, in relation to a simple spring delivered product dispenser that relies on gravity to get the product to its location. The parts would definitely have a much higher dead-on-delivery rate than normal vending machines — causing massive replacement shipping/delivery costs (Deployability). This is a stretch, but by placing additional overhead on these machines, you actually reduce the available room to provide additional hardware to the machine. You could be restricted to a smaller area and some additional hardware may interfere with other pieces of hardware causing more issues than it solved (Extensibility).


Availability, therefore, seems to be the only area that I wouldn’t have negatively impacted by my decisions for a vending machine. As software engineers, we need to make sure we aren’t over-engineering our products. Many times the “cool” solution isn’t the right solution. For instance, the delivery mechanism, while annoying for anyone that is tall or has a back problem, is fairly consistent. I mean, who has a better system than gravity? Last I saw it was a constant! Sure, occasionally product gets stuck in the machine before gravity can do its part, but I guarantee the mechanical delivery system would be much more prone to mistakes than the simple “twist and drop” method of most vending machines. While I may have potentially solved “my” problems, I’ve caused many more for my real customer — the vendor. In actuality the dependability of my vending machine would have cost more money to purchase and maintain, caused dependability problems due to mechanical failure, and most likely annoyed everyone more than “New Coke” ever did.


Yes, its great to solve your problems in cool ways, but make sure the problems you are solving are for the right person and actually advance your product design before adding more features than are necessary.