You wouldn't expect a family owned pizza shop in a small, sleepy Ohio town to be a hive of scum and villainy but that's what installing a computerized ordering system discovered.
I had worked off and on through college at this same pizza shop and about midway through my time there they switched from paper written tickets to a lightpen based ordering system.
Everyone threw a fit: "It's too hard to use", "It's not as quick as just writing 'LP' for a large pepperoni and an illegible address on a piece of paper".
This goes on for a week, orders are slow to go out, things are messed up, the phone lines are always busy so everybody knows we're losing business (people hang up and call somewhere else or get frustrated waiting for their food to be delivered).
The owner's contemplating canceling the system and going back to paper until the weekly tally is done and it is discovered that revenue is actually UP 30% for the week.
Drivers were massively skimming by "losing" tickets: drivers would go out on a run, deliver 4 orders and only return the cash and tickets for 3 of them. Managers would pull the same trick after hours: toss a $20 ticket in the trash and pocket the cash.
The computerized order system (which everybody settled into after a while) was an astonishingly good investment for the shop - ROI measured in weeks - and quickly led to a 75% turnover in the staff.
I don't know what's in the 4 mouse clicks to check each reservation in (as mentioned in the article), those steps might be worthless, they might be what's preventing the maitre'd from taking a folded twenty and seating someone who just walked in versus the couple who made a reservation weeks ago - and pissing them off in the process.
And without that information it's very hard to say whether or not the UI of that application is good or bad. Employees on the ground maximize their personal short term interests, owners paying for infrastructure have both a longer term view and different incentives.
This reminds me of one of the musings of Charlie Munger:
"...Now there are huge implications from the fact that the human mind is put together this way. One implication is that people who create things like cash registers, which make dishonest behavior hard to accomplish, are some of the effective saints of our civilization because, as [B. F.] Skinner so well knew, bad behavior is intensely habit-forming when it is rewarded.
"And so the cash register was a great moral instrument when it was created. And, by the way, Patterson, the great evangelist of the cash register, knew that from his own experience. He had a little store, and his employees were stealing him blind, so that he never made any money. Then people sold him a couple of cash registers, and his store went to profit immediately.
"He promptly closed the store and went into the cash register business, creating what became the mighty National Cash Register Company, one of the glories of its time."
>You wouldn't expect a family owned pizza shop in a small, sleepy Ohio town to be a hive of scum and villainy but that's what installing a computerized ordering system discovered.
Actually that is exactly what I would except, nothing to do with Ohio or a sleepy town I thought it was pretty well known that businesses of this type deal with a large 'skim factor' just like its common knowledge that many in the food/beverage service industry don't report all income to the IRS (pocket tips and not report it). In fact it was my understanding that almost everyone knows this (in regards to tips not landing on IRS forms) and lets it slide as really its the only way those that do this as a 'real job[0]' get by. This is why it is, at least for those I've known, considered 'bad form' to tip on credit card as those tips flow through company pipes to the employee's taxable income.
[0] real job meaning career employment vs a job while getting through college or whatever.
Flip side is it's harder for the owner to skim and not pay taxes. Quite a few places are cash only, paper receipts, no electronic trail for that reason.
I spent two years building one of these systems (http://rez.urbanspoon.com). It runs on the iPad and I'm pretty confident it's the market leader in terms of usability.
A lot of the responses in here make it out like this is about stupid arrogant programmers who didn't bother to understand anyone's needs. That's not true; what's really going on is that the design challenges are significant -- think high end calendaring plus inventory management, but used one handed for 5 seconds at a time. And design is not how restaurants get sold anyway -- they get sold on the marketing and table optimization stuff, which Live Bookings is actually pretty good at.
A good counterexample to look at are the back of house systems restaurants use. That's the touch screen they plug your order in to. Next time you're out to eat, notice the high information density and the fact that your server can key the entire order for your party of six in like 3 seconds. The fact that they all look like ass is not really relevant -- a lot of those setups are very well designed.
Great story about interfaces designed by people who don't use the software.
I've been encountering similar bad interfaces as I've been working volleyball tournaments mainly to learn how large scale tournaments are run and frankly the software out there works like something I might have built 15 years ago when I first learned MSAccess and VBA - that is to say, the interface is terribly clunky and not at all intuitive.
Though for niche products visible only to workers and admins, the 'vim principle' applies: software CAN afford to be (initially) intuitive, if it speeds up the workflow after a bit of training. Unfortunately, this current tournament software does not do that to the degree it should. There's no reason it can't be both efficient and highly intuitive based on what I've seen.
It's far worse than that. Either they've never set foot in a busy restaurant, or they're insufferable, self-absorbed bores who don't take five seconds to look up at what's going on in the world around them.
Ouch. Well, sometimes the dev wants to look at the world around them but isn't able. For example, I used to work for a company that sold software to health clubs, including high end ones like Equinox. I made various things, from a web app to allowing people to check in to the club using only their fingerprint. Most of what I made was used by the staff of the health clubs, but I was never allowed to actually go to the clubs and see these things being used. Instead, I had to rely on the knowledge of a guy who just knew a lot of stuff about the industry (ie, a "business analyst").
There's no reason to take offense--You'd be part of the first group, through no fault of your own.
Although you could have obtained a gym membership and checked it out. Or just showed up and asked nicely to see the system in use. If you introduced your pelf as "someone who wants to make check-in systems easier," I bet you'd get some info.
I have had several experiences like this: I get asked to build software and hardware systems for trade shows, and I get to attend to implement the technology. What I learn during the first show rivals all the meetings and handed-down info from the stakeholders. I am actually very excited about my projects now that he second occurrence is coming up for some of them.
Getting a membership would have cost him money & hassle. Showing up at the client's place of business without permission from your company sounds like a good way to get reprimanded, maybe even fired if the company got the impression you were "going rogue" & trying to steal the contract from them.
My intention with my comment was to encourage people to avoid behaving helplessly. That is a potential trap that could keep one surrounded in mediocrity.
I did intend to suggest that an unapproved visit to your employer's client would be conducted anonymously, but I did not word it very well.
A friend of mine has a restaurant and constantly gripes about the poor usability computer reservation system.
However he also pointed out one thing this blog misses (r.e. the reasons restaurants use them) and that is that it lets them automate reservations - i.e. let people reserve online.
Apparently this can be a major advantage now; significant enough to take the awkwardness.
He also mentioned that the computer has advantages over a whiteboard in that it is easier to modify cleanly, limits the number of things like double bookings and so forth, that a whiteboard can create. :)
More than that, the online systems may give you the software for free and possibly the computer too, because they will take a $1 or so off of each reservation. Since restaurants are perpetually cash-strapped, this saving to the owner outweighs any inconvenience to the actual users.
Isn't this really about the dichotomy between owner/manager and worker?
Many systems we built are specified by the managers of the workers. And of course they want lots metrics and fail safes and all kinds of extras the result in a really crufty system.
So the workers try all they can to "route around the damage" of such a system. And the workers aren't happy, but the management is, because for the first time, they can really see what is going on in the business.
This isn't a software issue, this is a fundamental split between management's and worker's interest.
If you think you are going to solve that with some fancy UI design and the latest touch screen hardware, well...I wish you luck.
There's this awesome karaoke bar in Philly where you can rent private rooms with their own karaoke machine. the interface is so bad, that I, a software engineer, was unable to get it to work without getting extremely frustrated, calling for help multiple times. so naturally I start thinking about how I could build a business around karaoke machines with nice UX and rent them. But it turns out a karaoke machine is useless without a library of content, and the company that builds them is a subsidiary of a Japanese label thus can negotiate discounts with content owners. It's just not something that's easy to compete with.
Anyway, I go to this karaoke bar about 6 times a year and drop a hundred bucks each time. I don't think they care to invest in UX right now ;)
anyway, if you extrapolate this idea a bit, it makes you wonder - if software is your business's core competency, and you're competing mostly on UX, maybe you are doing it wrong?
I think this is the same reason Microsoft Office is so popular when there usually are "better" alternatives. Because Word is like pen and paper with spell check. You can add whatever shit you want wherever you want with zero effort. But you don't realize the technical debt you will have to pay for later because nothing is consistent, diffing is a nightmare and your data is everything but normalized.
Want a header, just increase the fontsize, Is that really a header?
"Hmm, it's thick and big, whatever, did anyone say lunchbreak?" Save exit.
For small temporary documents like party-invitations this is fine, doing anything else would be silly. But companies actually use word for serious documents like 100+ pages technical specifications valid for years with tons of versions of each document. It is scary how much mission critical information that is stored in this form, at one of my previous jobs if changes happened outside our division, every document depending on this data had to be updated by hand because it's just plain text in word, nothing is connected or autogenerated. It's grunt work but it actually gets the job done sooner or later. I've seen this in several places. Word and excel keeps the world spinning even though it at the same time requires much more manpower than is reasonable.
Someone has to make an alternative to word that is as easy to use but doesn't allow you to do all the stupid stuff. Enforce styles, make references and other data-connections easy, smooth and reliable and provide a good diff.
I think this is one of the greatest challenges in software development, allow freedom at the same time as you have a strict data model that can be analyzed, processed and generated by a program. Something that paper will always beat, regardless of what kind of paper you get you can always write and highlight on it, with software that is very exceptional.
> Someone has to make an alternative to word that is as easy to use but doesn't allow you to do all the stupid stuff.
Notepad? Vim? Plus a little bit of Markdown?
I had to do a big certification project. A guy went on with a MS project massive file on my team with milestones, completion percentages and so on. I couldn't see it without nausea (and obviously I couldn't see it at all on my Linux box), so I dumped it as text, reformatted it with some Mardown and custom markup, and did a little parser highlighter in a week-end. Then I could put this under version control, have meaningful commits and diffs, and the MS project guy stopped trying to micro-manage my team, and was fired eventually...
That is to say that for me (but not for everyone, I am aware of that issue) nothing beats plain text and, when needed, some markup. Exceptions could be printed books and magazines. But I would not trust MS Word with a 500 pages specification document, and more so because it is important and long, and must be precise. As far as I can tell, TCP/IP specs are written in pure text with some markup.
>Someone has to make an alternative to word that is as easy to use but doesn't allow you to do all the stupid stuff. Enforce styles, make references and other data-connections easy, smooth and reliable and provide a good diff.
That is why I'm building (actually finishing the ALPHA release) of a little FOSS app named Paste Box.
It is a paste bin/simple word processor with one click saving ( to a db ), syntax highligthing, user accounts, one button search feature, anonymous pasting, and a simple (but easy on the eyes) UI.
It also features a simplified install process, to keep the IT dept. from going postal.
The first release is a PHP/sqlite version, then a .NET version will follow (desktop and ASPX versions), and then a RoR version.
After those are done, I plan (if people actually use the thing) to add simple text formatting features with JS.
--
I came up with the idea after realizing that office people have a pretty bad workflow when dealing with text files.
They have to open up Word (which depending on their system, can take up to a minute), then they have to save the document, but not without deciding on a name. Worse if they have to create a directory to store the file into. This does not take into account all the different options that Word offers in terms of file types (which most people don't understand.
I just want to save people time (and whats left of their sanity).
The git repo for the project is over at github/codepockets.
All the code in there is just prototype (read: ugly, non-working)(I follow TDD).
Once the thing is ready and tested, I shall announce it to the community. Deadline is the last day of February.
Proves the articles point even more. Even when all the features are there, people still just wanna get the task out of their hands as quickly as possible and press the bold-button because it takes them one click less than choosing a style, and it is still enough to consider the task complete.
(I know choosing a style is also a one click operation but i'm generalizing)
And the companies selling computer systems (of all kinds,
in many businesses) usually push the possibilities to get
such data as big advantages with their system. But is it
worth the effort? In many cases, a headwaiter would
probably know most of what really matters anyway from
experience or rule-of-thumb.
Management, not headwaiter buys software, and results of this software most likely used by management to do right decisions. And what if headwaiter leave company, hit by a bus, abducted by aliens? It is better to have data in computer harddrive/tape/dvd.
Although, this is not an excuse for making something 4 clicks instead of one (i.e. to replace crossing something with a pen)
I think you missed a great takeaway from the article: that it doesn't matter if the software calculates these things if it can't collect that data in the first place.
1) Nobody uses a useless and awkward system as intended, 2) so the data is not collected, 3) so there is nothing to analyze, 4) management cannot base their decisions on data that does not exist, 5) time and money was wasted for no productive purpose.
This is why everyone should have had a "real" job at least once, even if you've been a programmer since birth. It's a real eye-opener to realise how bad systems work in practice.
We develop software for warehouses and I am continually flabbergasted at how our stuff is used. That being said, we work very closely with a few of our customers to get direct feedback and know what is and isn't working for people.
If you're writing software and not getting feedback from someone using it in a real environment, you're more than likely not making it very user friendly.
I'm surprised they managed to find a whiteboard pen which didn't destroy their display. Most of them have solvents which I would expect to interact poorly with the surfaces of LCD monitors.
That's the smartest part of the hack I guess - that the waiter actually invested time to test out his idea! Who knows probably the first marker he picked up didn't work the way he expected and he moved on to the next one till he found what worked.
My experience with generic "Don't put this chemical on that surface" issues has been that it usually takes quite a long time of heavy contact before there's a noticeable effect. I'm guessing an Italian restaurant with an identifiable "head waiter" can afford to replace a $200 monitor every few months.
Great story however I think the author is missing a link in the communication chain.
Computer systems are not always used as the developers suppose.
I would happily bet good money that the developers built what they believed to be a useful and efficient system that the thoroughly tested. A view that I will guarantee was shared by the restaurant owner who purchased the system and implemented it into his restaurant and spent valuable time teaching the staff how to use it.
A couple of busy nights later and the staff are struggling to remember the sequence they are meant to follow and instead of familiarising themselves and becoming more efficient with the system over time they implement a very basic system that takes less effort to remember.
This is less of a case of a poor system and more a case of poor management mainly because the staff obviously weren't trained and sold on the system properly and no follow-up checks have taken place to ensure the system is being used correctly.
But in the end it probably does both. I often find that when developing some system we end up with a less than optimal result due to all kinds of constraints. Sometimes there just isn't enough money to finish the project the way I wanted, or the existing ICT infrastructure isn't under my control and I and my clients have to make ends meet. Then the organisation starts growing around the solution like a leukocyte encapsulating a non-own-body cell and it becomes part of the organisation.
Not when you need to replace an X with four clicks...
You probably know the story with the high-tech tracking systems for planes on carriers - it was so good and easy to use they had to replace it with toy planes on a table - true story...
I'm not talking about this specific incident, I'm talking about the slogan. Pointing at a couple of bad examples doesn't mean that sometimes businesses do have to change their processes to fit software that is better for them. Or perhaps a better way of putting it is: business and software should change together to answer what's best for the business.
Where I currently work has shitty inventory control - salesforce for sales and device tracking, and an Access database for unit consumption.
This is absolutely woeful and has a number of problems to people who know anything about inventory. Want to know where widget #234 is? Well... I hope someone entered it against the sale in Salesforce. Cool, they did. Now, can we make sure that that serial is unique? No. Which batch of components was it made from? No idea. The sale was accepted on this date, but it wasn't installed until two months later... when was that? Is the item still in warranty? We sent device #234 to a demo site, and then it got moved on, and then it came back and then it was sent to another demo site, we can tell that right, because an issue has cropped up where we need to know where it's been? No, there is no history tracking.
Trying to track inventory in salesforce is a fool's errand because they have no concept that an item is unique and can have history - anything resembling a serial number is just a user-enterable text field, no protection against duplicates, no protection against assigning it against sale 2 because it's already on sale 1.
These are the current business practises where I work, and we've shaped our processes around them. But we're about to start being more hard-lined about warranty terms (until know we've been giving free terms as we've been largely on the VC teat)...
The business needs software that is going to be harder and more complex to use than "yeah, fill in this free text field with whatever you feel like, if you feel like it. So yes, sometimes software needs may look to the casual observer like "this is so arcane and complex", but that doesn't mean that they're automatically bad - the slogan above is trite and the real problem is that it implies business shouldn't ever need to change their processes to suit software. I mean, there is a point to the slogan, but it should be rephrased to something more suitable.
We have similar experiences with software. I think the problem comes from "I'm smart - you're dumb". The software should help me not the other way around.
Consider my brand new Samsung TV set: I could not believe that program numbers are not unique! You can have two stations registered with the same program number!!! Do I have to adapt my business because TVs are suddenly smarter than me?
If I'm too arrogant to realize that a domain problem has a very simple solution then I will reinvent the wheel and make it square.
(Indeed, slogans loose their power through overuse - that does not make them untrue though)
> Consider my brand new Samsung TV set: I could not believe that program numbers are not unique! You can have two stations registered with the same program number!!!
As someone who has spent his career in DVRs and smart TV stuff, I have no idea what you're talking about. What is a "program number" in this context? Are you confusing "program" with "channel"?
I call a "channel" the frequency of a station; "program number" is what the TV gives me on the remote control to go to a station - the number on the screen.
In that framework, the TV has two frequencies (or channels) associated to the same "program number". I can switch between the two by entering from the remote the same "program number" twice or more times...
It's just reality. Software is easier to change than people. People forget things, get into bad habits, have non-perfect understandings, ulterior motives, and all sorts of other flaws.
If your software relies on fixing flaws in humans, it's probably going to fail.
Actually, it directly depends on how many people. Good software is expensive, and if your staff is below a certain number, it may be cheaper to just use the stick. I think this is why hospital software systems are so abysmally bad. They have people who are accustomed to complex training, and software that costs a small fortune to deploy.
Part of the reason why hospital software is bad is because of the intense politics involved, complete with fiefdoms and sales reps with shiny toys.
A friend of mine used to be in Quality management at the Royal Children's Hospital in Melbourne, here are two (of many) stories
The hospital patient management process is somewhat paralysed because every department has its own custom system for managing patients. He was involved in trying to get a hospital-wide system in, but the CEO was more interested in "making her mark" than managing the hospital, which would require forcing the point with the department heads. So quite frequently patients moving between departments would not have their receiving department ready or even aware of their arrival. Generally the issue was that either department heads liked the shiny toys brought by sales rep -foo- (doctors get a lot through sales rep gifts) and didn't want to change because they'd stop getting them; or that the doctor was stonewalling because they didn't want to learn a new system. Classic case of everyone saying "something must be done... by someone else!". The kicker is that no matter how persuasive your argument might be, the doc would have the last word with "children will die if I can't use this software" and the argument would end.
The other story is much shorter: at one bigwig's meeting, one of the senior specialists - a 27-year veteran - shot down a new doctor's comments saying that he wasn't familiar with how things work here. The new doctor's reply? "I've been here 17 years..."
I've had a microcosm of this experience as well. While installing monitoring gear for one of the departments, the department chief went ballistic because the new computers had power cables that were touching the desk: "It's written into the quote that the power cables will not touch the desk!". Nonsense, of course, but it's how she gets things to her liking - she was the poster girl for post-contract feature changes. I would have called her on it to try and forestall the next few things that were 'in the contract', but my company was spineless and would never have backed me up.
I guess the short form is: a large part of the reason why software is terrible in hospitals is because not many people that have a say are actually evaluating the software properly.
> I guess the short form is: a large part of the reason why software is terrible in hospitals is because not many people that have a say are actually evaluating the software properly
There's a special case for England's "connecting for health" $18billion nightmare.
No, as I clearly said, I'm blaming the management for not clearly communicating to the staff why the new system will prove to be more efficient in the long run.
But it isn't efficient. Its so inefficient that the staff have been reduced to using a marker on the screen. Its not a failure of management communication or proper training. It's a failure of the product.
That could be the case or it could also be the case that the head waiter never took the time to learn and has refused to change his ways. Hard to say from just one data point. The same system could be successfully used in thousands of other restaurants.
You have no facts to prove your claim. You don't know whether or not a) the management clearly communicated to the staff; b) the new system is actually more efficient; c) the headwaiter isn't actually the manager that put the system there in the first place; d) this event happened "in the long run", after working with the system as it should after which stakeholders decided that it's actually not efficient, etc etc.
You can blame management and bad communication all you want but the fact is that what seems rational and efficient for some people (management) is irrational and inefficient for others (the person actually doing the work).
Unless the management bought a general scheduling system and not one specifically made for the restaurant business, then this is the fault of the software developers for building a system without doing the appropriate market research first.
I do believe this is a general restaurant booking system. By looking at the URL in the image you can see that this is a online based restaurant booking system.
Usually these smaller swedish restaurants doesn't have any management and the owner is usually the headwaiter.
It was made specifically for the restaurant business. Look closely at the last screenshot. You can see that it's a web app running in Chrome. The URL is visible, and the website is a "reservation service for restaurants".
Also of interest: the company uses a freemium model.
This reminds me of a supermarket where I shop where the point of sale system's display was so crowded that the cashiers had to draw a big arrow right on the screen with permanent marker to point at the total price…
Sometimes people selling / buying software just don't know what the people using it want. It's weird that this can happen to hugely popular software. Why don't they train sellers with "A list of common mistakes people make" or "things to look out for".
I remember months of hours lost because a system I was forced to use could only search the first 16 characters of a 2 line by 32 character description; where many of those first 16 characters were identical. (Sage Line 100 in a sub-contract electronic engineering company.) The vendors knew that searching for part numbers by description was crucial, as did the company bosses.
No-one wanted to pay for the trivial text edits to the parts-list; that would have cost at most a couple of hundred pounds. Time lost to searching for components, or having doubles, was significantly more than that.
I spent years managing restaurants and now develop apps and UI using web technologies. Being one of the few who truly understand both the needs of a packed, high-end restaurant/bar/club as well as the technology behind it, this is a problem I've wanted to solve my entire life. There is still a huge opportunity here as I can tell from this article and the comments. It is not easy, which is why it is still an unsolved issue -- but I know the secret which can marry tech and restaurants in happy harmony. If you are as inspired as I am to create the next-generation of super-usable restaurant POS, please drop me a line.
I also find it interesting that everything has been abstracted behind the mouse. The stylus was around for a while but is was replaced by the finger. But does reducing the physical tool set benefit the experience?
Is it practical to increase the physical toolset? Adding pseudo markers and exacto knives and erasers? This makes it less portable but what does that matter if its always in the same place?
It matters because extra tools cost money and get lost. If you work in a restaurant, you don't one a dedicated surgery kit just to indicate that someone showed up for their reservation.
A touch panel display that does everything, pinch in and out to modify details on specific tables, swipe to toggle between schedule mode and table view. Move people by holding on the table, then drag over. This is an easy app in the ipad age... I'd be surprised if it's not done already.
I admit my mind wandered from the immediate context of the article. Im just curious overall - like a draftsman using tools that suit the task, not hunting for an icon and using a mouse that is separate from the screen. Touch interfaces have come a long way indeed but fingers are still too fat for precision work. I was a big fan of this as well: http://www.wired.com/entertainment/music/news/2007/08/bjork_...
yeah, OpenTable is solid. I have experience in the restaurant industry as well. It does a very good job of mimicking the most efficient offline systems. Good software designers have to understand the real world experience of a problem to address it well.
If someone, perhaps an age-impaired individual, draws on your awesome screen with a permanent marker, you can draw over it with a dry-erase pen to loosen the permanent ink.
Interesting - the verb "separate" in Swedish is "skilja". Science is (according to wiktionary) from "scire" - "to know". Is that from "separate the wheat from the chaff", or how is knowledge tied to separation?
I don't have my full array of dictionaries at hand, but the Oxford Latin dictionary (the only one worth considering in my opinion if you want a serious discussion) gives the etymology of scio (the root verb) as possibly related to Sanskrit chyati and Greek schizo (as in schizo-phrenia, actually), both meaning to separate. I can't say for the Germanic connection to shit and friends, but it's not impossible, although I'm not sure where the l comes from.
I'm not entirely sure which root the Sanskrit form should be but it might be chid-, which fits with the Greek. In that case, I'd wager an Indo-European root along the lines of skedH-, with palatal k and laryngeal (IIRC, it's the laryngeal that gives the Greek z).
As for the derivation of the meaning, I think the notion of "separating right from wrong" is reasonable, but these things are often notoriously hard to pin down.
I imagine it as originating in knowledge about plants and animals. To know is to be able to separate one species from another, or one individual from the group. In the Genesis myth, the first thing Adam does is give names to different animals. And the Tree of Knowledge revealed the separation of nakedness from non-nakedness. This was before people "knew" things like history or math. I suppose this kind of knowing is similar to how the function `filter` separates things based on a predicate.
I would say that knowledge is tied to separation due to the fact that in order for you to know a concept, you will need to know what separates it from everything else.
Said in different words: Being able to see only one color is the same as not being able to see. You need at least two colors to see anything, as you need the contrast(separation) to see where something begins and/or ends.
I'm not sure about "science," but: According to the OED, the noun form of "skill" and the obsolete English verb "skill" (to separate, from Old Norse skilja) are both related to earlier Germanic words for distinction/difference.
However, in Middle English, the meaning of skill varied a great deal, sometimes representing, for example: "a statement made by way of argument or reasoning."
I had worked off and on through college at this same pizza shop and about midway through my time there they switched from paper written tickets to a lightpen based ordering system.
Everyone threw a fit: "It's too hard to use", "It's not as quick as just writing 'LP' for a large pepperoni and an illegible address on a piece of paper".
This goes on for a week, orders are slow to go out, things are messed up, the phone lines are always busy so everybody knows we're losing business (people hang up and call somewhere else or get frustrated waiting for their food to be delivered).
The owner's contemplating canceling the system and going back to paper until the weekly tally is done and it is discovered that revenue is actually UP 30% for the week.
Drivers were massively skimming by "losing" tickets: drivers would go out on a run, deliver 4 orders and only return the cash and tickets for 3 of them. Managers would pull the same trick after hours: toss a $20 ticket in the trash and pocket the cash.
The computerized order system (which everybody settled into after a while) was an astonishingly good investment for the shop - ROI measured in weeks - and quickly led to a 75% turnover in the staff.
I don't know what's in the 4 mouse clicks to check each reservation in (as mentioned in the article), those steps might be worthless, they might be what's preventing the maitre'd from taking a folded twenty and seating someone who just walked in versus the couple who made a reservation weeks ago - and pissing them off in the process.
And without that information it's very hard to say whether or not the UI of that application is good or bad. Employees on the ground maximize their personal short term interests, owners paying for infrastructure have both a longer term view and different incentives.