Everything I Needed to Know About Good UX I Learned While Working in Restaurants

Everything I Needed to Know About Writing Software I Learned While Working in Retail

1. The user does not always know why they are there and what they want to achieve.

2. The user cannot guess what something does, so they rely on the visual clues, such as reading the box.

3. Users will need to undo something at some point (sorry, no refunds).

4. Two customers wanting the last stock item on the shelf causes a concurrency issue.

5. Under staffed and too many customers helps you learn about queuing systems and load balancing.

6. Getting access to stock from the main warehouse on a weekend reminds you of the importance of correctly configured user roles.

7. Disparity of prices from the mail order catalogue and in store prices tells you the importance of data propagation delay.

8. Not all users understand the concept of an automatic door and which direction they need to enter and exit. Receiving an error in this instance causes the user to experience huge embarrassment.

9. Users will attempt to steal something that isn't properly secured.

A thousand times, yes. I've moved into 'devops' from support, and it's just as clear on this side of the divide just how little esteem developers have for support staff.

One bit of schadenfreude from the past: I worked in a 2-person support team in a small company, and constantly had requests for improvements (both support- and client-friendly varieties) rebuffed, basically with the 'eh, what would support know about products' attitude[1]. I ended up leaving that place, and the other support guy had already booked a month-long sojourn on the other side of the planet, leaving the developers to now support their own product. The company ground to a halt and no-one could do a thing as the half-dozen strong dev team struggled to do support with the shitty environment they gave us to work with. Apparently on the other guy's return, better support tools shot to the top of the devs' priority list.

I also remember hearing about a wine distribution company in Western Australia where every new hire, regardless of position, spends a week half on support calls and half in shipping, so that everyone is exposed to the difficulties of packing and shipping wine, and dealing with customer breakage. I love this idea, and wish it was more widespread. Dealing with the public is hard, but there's not much you can do about that. Dealing with the undeserved contempt of your coworkers is also hard, and it doesn't take much to expose people to the more human aspects of the crappy positions in a company; raising empathy can really help.

[1] I've always found this bizarre, that the department that has the most client contact when something goes wrong is so routinely ignored when developing the product further.

(1) Write code

(2) Follow good software engineering principles

(3) Have a public profile

(4) Negotiate a higher salary

(5) Never forget that dispensing wisdom through perhaps tenuous analogies is an integral aspect of (3), and arguably also of (2).

I thought that it was a hallmark of American culture that you get to do that in college, before you get a professional job.

      1. C:\> a                                    {enter}
      (a.bat starts c:\pos\pos.exe)
      
      2. Pull-down menu: Transactions -> Sales     {enter}
      (Sales is the default selection)

      3. Bill no: <last + 1>                       {enter}
      (new id starts a new bill)

      4. Item code: <4823>                         {4-digits+enter}
      5. Quantity: <2>                             {2-digits+enter}

      6. Item code: <blank>                        {enter}
      (just one item; give blank to exit)

      7. Menu: [Print, Next Bill]                  {enter}
      (Print is default selection)

      (loops back to 4, keying in a new bill)
    

Then the touch screens came out, so slow in comparison. The learning curve was faster but the operations were terrible in comparison.

I still remember Red Lobster POS codes from the 1990s. 2411, 2443, 901, ... Good times :-)

One of the problems you always have to deal with though, is that no matter how good the app is, the person programming in the menu can still be completely useless and make it annoying to use, so the challenge is to make programming in the menu as easy as possible.

Being iPad based means that we can actually utilise touch-screen actions, e.g. you can swipe items into a tab, rather than having to tap the item, and then tap again and tap some more, like you're describing.

I would say try to be more objective because you may be missing out on opportunities to actually improve things.

It's helpful if you don't know much about what you're ordering (is it a curry? soup? stir-fry? etc).

> I defy you to show me any European restaurant that treats it's customers like children by showing them brightly coloured pictures of their food on the menu.

Edit: Here is an online version of the printed menu http://www.kanpaisushi.co.uk/kanpai_sushi_menu/

Higher class establishments don't do it in general but it's not like it's unheard of in the UK to use food images on menus.

I agree it's cultural in the UK that this is tacky but besides that, why is it a bad idea?

Edit: typo

Grumpy, I know. I just loathe obfuscation for the sake of marketing. Guaranteed to mean I'll avoid that store. And no, I don't use Starbucks.

But if you think the UI for the end-user is bad, you should see the UI for the people who have to maintain and refill the machine. Having these things internet connected throws a pile of rotten eggs on IOT.