I used to work for a company that made a POS system for hospitality.
It was incredibly hard to make everybody happy. Every restaurant and bar and cafe had their own way of doing things, and wanted our system to do it that way.
We did have a few "rules" that helped make the system easier to use and to avoid stories like this.
We tried to ensure that nothing that was used more than a couple of times a day was more than 3 taps away from the main screen.
We also did a lot of visits to our customers. If there were sticky notes around the POS terminal, that was always a red flag that our system wasn't doing something the right way.
One important take away from my time at the company, where we worked fairly closely with our customers, is that people love sticking to the old way of doing things, even if there's an easier, new way to do it. If you changed this system to only require one click to change bookings, they'd probably still use a whiteboard marker on the screen, because that's the way they've always done it. Cargo culting is incredibly common for non-technical people using technology, and even fairly common for technical people.
The flip side is techies often assume that because something is newer, more complicated, and more "high-tech" it's automatically better. In reality they often introduce dozens of new failure modes (what's the worst that can happen with a whiteboard, out of ink?) for a 10% productivity gain on the rare occasions it works as intended.
I've sat through dozens of sales pitches for (shiny new product that will replace your old piece of junk). When pressed on why it's better, the answer is basically "Technology!"
I was at a meeting years ago (IBM..they did have a lot of meetings). This was about making a complex online tool for facilities engineering.
After some discussion, the boss determined "This is solution in search of a problem" (it really was), so the project wasn't started.
This answer stuck with me. The tech was interesting but looking the bigger picture it didn't help the business. It was the do nothing alternative that made the most sense
One of the things I've realized is that you basically need to design your technology to do exactly what the customer does. Once you've done that, you can start cutting unneccesary stuff out and making stuff easier.
If you want to introduce a step that lets someone skip 2 steps, it's going to be a hard sell. Unless it's a critical part of your product, you should probably make it skippable. Otherwise people are liable to avoid it, falling back onto pen and paper, then run into trouble down the line when it prevents them from doing what they want.
Yeah. Assuming people are doing something just "because it's how they always did it" is a wrong approach. Your new 1-step process may let them skip 2 steps, but it may turn out they depend on the process being 2-step in order to e.g. handle special cases.
This is what I often see happens with software, when someone tries to simplify the workflow by just looking at the most common sequence of actions and designing around that, and not minding all the flexibility they're throwing away that's crucial to handling uncommon cases. It's (one of) the reason people keep going back to Excel spreadsheets, even though your custom-tailored piece of software does everything they need better. It's because your system is rigid, and Excel spreadsheets are flexible.
I think the problem is a lack of dogfooding in the industry. There is plenty of SaaS providers that simply sell the software to their users but don't use it themselves.
The ideal SaaS is one that sells software they use themselves.
I would think for a PoS it would be similar. Selling a good PoS might require running a few restaurants where you deploy and test it. That way you aren't running risk of not knowing the pain points because the users are far away and don't want to bother you with it. It should also lead to some pragmatism instead of overthinking.
Companies are using many user research techniques to get into heads of their users and find out their needs and painpoints. One of those is shadowing users over some period of time, where as a user researcher you basically spend every day observing your users perform their usual activities in their environment.
The problem of many today's companies is not using this approach right - or even worse - not considering this as a part of their business strategy, and that's when their solutions fail.
I think one of the earliest and most valuable (and obvious) software lessons I learned is that users are very busy, and don't want to take the time to learn your software. They have these things they need to do, and the software is getting in the middle of it. Either the software does exactly what they want, the way they want to do it, or it's in the way and a nuisance. Your opinion about what the best workflow through the app is totally irrelevant. The underlying data schema is irrelevant. Whether inserting a record is O(log n) or O(n^2) is largely irrelevant. Your customer has a workflow in their mind, and if your software doesn't conform to it, it's junk.
One place I learned a lot was working at a company that did displays for boats. From little fish finders on recreational fishing boats to multi-screen navigation systems for yachts. I'd go on-site to customers boats all the time, and these captains are busy people. When they're out on the water, they have 99 problems and your software cannot be one of them. Any task they need to do that involves traversing some menu hierarchy or precise cursor positioning (remember, 5-10 foot waves) is not going to work. Touchscreens are out of the question, unless they work when covered with salt water and you have gloves on. Physical knobs and buttons (with nearby handholds) are obviously preferable to pointer and keyboard input. You can hang your design school diploma and "UX master" certificate in your office above your desk and talk academically about the program's optimal information architecture, but your ideas are useless if they don't survive contact with the actual customer.
I always wonder how it is that multi-billion dollar companies are incapable of hiring a top-notch UX team, and then following through on whatever that UX team recommends
I keep wondering about too. My current guess is that it's a combination of the following considerations:
- Cars design is focused on sales, not utility. Futuristic tech like touchscreens looks better in commercials, and makes people think they're buying high-tech. This is incidentally what IMO is plaguing software industry too - software products are designed with focus on pretty looks, not utility, because it's the initial experience that drives sales / subscriptions.
- A touchscreen interface simplifies car design. When you're design the car's interior, a touchscreen is just a box connected to the CAN bus. You can ignore the rest. Which means, all UI work can now be done completely in parallel by a separate team, or (more likely) subcontracted out. Also, altering that software to e.g. move a button elsewhere is much cheaper than moving a physical button.
The car industry is famous for prioritizing sales over _human lives_. "Sexy looking muscle cars" was an image that sold cars, unlike "unsafe deaththraps without seatbelts, collapsible steering wheel columns or airbags" (see: https://en.wikipedia.org/wiki/Ralph_Nader#Unsafe_at_Any_Spee...).
It's hardly surprising that they'd prioritize looks, regarding touch screens.
Eh well, synaptic controls like buttons and levers look better in my opinion anyways. I really don't know why there's so much initial hype. "Wow!! This onboard touchscreen allows me to do things I don't know how to access, and without any feedback whatsoever!" ??? The design is usually really bad too, in terms of aesthetics.
Our ten year old daughter also thought the touchscreen was cool in the new car. Until she was allowed to finally sit in the front seat while we were driving. She directly came to the conclusion that a touchscreen is stupid in a car :-) Well, at least on the bumpy roads in northern sweden...
Many bad votes in appstores seems to come from "ugly interface" or "looks old" and other similar things. Why is it that an app needs to follow the latest fashion trends? There was a time when we computer nerds looked down at fashion trends, thinking that they just repeat themselves anyway. Why is it that you have to have the latest fashion colors/UI to get more than two stars from some people? No matter if the program does what it needs to and does it fast and efficient.
>Why is it that an app needs to follow the latest fashion trends?
I think our fashion and design tastes directly reflect something important about the time we are living in. For example, minimal and clean is in right now. You could speculate many valid reasons for this. It's also dependent upon the person. The majority of people are attracted to the latest fashion for various reasons, but some people go somewhere else, and others don't care. Users are thinking, if you're not on trend maybe you're out of sync with the user's needs?
It's also about consistency, and appearing as though you've spent time on the app to give it a consistent design. It doesn't necessarily need to be on trend as long as the design says something about the functionality of the app. A retro game in the play store should have a retro-looking menu!! If your design looks significantly outdated without being consistent with the functionality of the app, I think it sends a subconscious signal that the functionality is also deprecated, or that the developer was too lazy to care about an aspect of development that usually gets a lot of attention.
Because UX people are often completely lost in the fog of their own "brilliance".
Just observe the new task switcher on the Android P preview.
Where before you hit a button (either on-screen on fixed depending on the OEM design) and got a list of previously used apps, now you have to swipe from the center to the edge at the bottom of the screen to flip though them.
Sometimes UX people design the UX to wow the people who (1) control their paycheck (2) review their work externally (3) appreciate UX theory/trends/etc. No different than a programmer using a needlessly complex algorithm to impress people on the internet.
I remember MS word putting in the 'word count' feature for the article authors who reviewed the software. That feature is a high priority item for the writers and people who need their work to fit in a certain constraint, but not for most users.
I am sure that is true in general, but this quote:
"You can check off a reservation in the system, with the mouse, but hey, it’s at least four clicks away from this screen"
indicates that the problem here was not untrained, obstinate or idiosyncratic users, but a design that did not meet the most basic, general and obvious standards of usability.
Maybe it was a consequence of the system being customized to a specific set of requirements, in which case the interaction between the customer and the developer would be an interesting study in how things go wrong.
One of the reasons Excel is still so popular for business processes compared to purpose-built apps. The main disadvantage (the user can go in and edit any data or formula that they want) is a feature to many users.
Yup. It's funny how this is even seen as disadvantage. It's as if you hired people to do a job, and then started to make that job difficult for them because you don't trust them to do their job right :).
Well, people make a LOT of mistakes with Excel. I once made one that caused the answer to be off by $60 million (out of $200m), and didn’t discover it until I had presented to senior management. I never told anyone.
Getting a rush of "all-asking-the-same-questions-in-slighly-different-ways" and "all-wanting-the-same-information-but-with-slightly-different-phrasing" information security questionnaires - CREATED AS EXCEL SPREADSHEETS.
If you want multiple-paragraph answers please stick a table in a document if you really must or, better still, base your enquiry on a standardised document - they do exist (https://cloudsecurityalliance.org/group/consensus-assessment... - albeit it's another bloomin' spreadsheet)
It's like job application hell (every company wanting you to put the same info into their specific questionnaire) in reverse.
Yay GDPR!
(Fortunately, most of my responses are now 'see our GDPR doc ref: nnnn, which covers this point')
Not in the EU, but the healthcare industry in the US is the same. So many "see answer to question 4", and going back to an earlier question when a later question clarifies its meaning. And then the answers are only used to check compliance boxes, and you end up answering all the same questions again when it comes to implementation.
Here's my experience of POS, contrasted with my experience of the previous system.
- Write down words as customer orders on duplicate orderpad thing. One copy to kitchen, one to us.
- Write down words as customer orders. Get back to bar and start using POS system. Faff around trying to get it to add custom requests. Get moaned at by other person who also needs to put an order through. Click wrong thing, get annoyed. Fix it. Check a final time that it's consistent with my notepad. Send.
There are lots of things POS improved if I'm honest, but none of it was an improvement for the waiting staff in my experience. Things are obviously much better now - but the reason everyone hated the machine (even ignoring the freezes/crashes) was because it made a previously simple task have 15 extra time-consuming steps.
The reason POS systems win over is because the waitstaff UX is not the primary factor in the pros/cons list.
Consider things that are easy to do with a POS that are hard to do with handwritten notes:
* Generate a list of how many of each dish sell each night/week/month to decide what dishes to add/cut.
* Reconcile sales figures with purchasing to identify abnormal food waste/shrink.
* Identify waitstaff who are unusually good/bad at up-selling on wine/desserts.
* Automatically reconcile the till at the end of the night to notice any discrepancies.
Whenever you have data be converted from an unstructured format to a structured format and then back into the identical unstructured format, the detour in the middle is always going to seem like a pain in the ass because data entry is always a pain in the ass. But the justification for doing so is that other people need the data in that structured format so they can aggregate and analyze that data more easily and you happen to have just shouldered the shitty task of data entry on top of all of your other duties. It doesn't make the system overall a bad one though.
> Whenever you have data be converted from an unstructured format to a structured format and then back into the identical unstructured format, the detour in the middle is always going to seem like a pain in the ass because data entry is always a pain in the ass. But the justification for doing so is that other people need the data in that structured format so they can aggregate and analyze that data more easily and you happen to have just shouldered the shitty task of data entry on top of all of your other duties. It doesn't make the system overall a bad one though.
This is how the lowest paid get undervalued. Their job has been made harder but it is their work that has allowed "some big-shot restaurant exec" to claim he has added $n in extra value with his changes. BigShot gets a pay rise while the poor sod who struggles to cope with the new system gets fired.
The irony is when the new system is for just a single customer, after going through several meetings with mockups and usage scenarios with all key users.
That was implicit on my remark about key users, meetings are not always about being seated around a table.
Actual users engaged and discussing how they actually work and what they, the actual people that have to deal 8h a day with the system, want it to behave.
These same people will dismiss their previous remarks and state that the old way was better, even though they were the ones actually suggesting the new behaviours as improvements to the current issues.
That why good user research is not about asking customers what they want, but rather observing them use products, identify the pain points that are obvious and ask them more questions to understand better their problems and desires.
This is exactly what I mean. Also it's best to observe them during high stress periods when they are busiest. The pain points will jump out at you in those situations.
> One important take away [...] is that people love sticking to the old way of doing things, even if there's an easier, new way to do it.
I think "ease of use" is highly attribute, enormously dependent on the expectations and workflows a user has already learned.
If there is an arcane mouse gesture/shortcut/menu item/cmd command that a user knows very clearly how to use and a simple-looking button with unclear purpose, then for that user the former is probably a lot easier to use.
I see by the “programmers” the opposite: see Gnome KDE etc. The normal user would like to have desktop icons. The programmers make a GUI but probably never leave the terminal so they don’t care. The users would like to drag the border of the window to resize. The “programmers” again resize only their terminal windows with some arcane keyboard combination so they leave the border 1 pixel wide. See recent HN about new Ubuntu version for more of such insanity.
Disclaimer: a user if Linux who wants to use desktop and drag the window borders and scrollers. For Gnome I’ve wasted so much time to achieve that. A normal user can’t do that.
This is more a phenomenon of the UNIX developer culture than other desktop environments.
I came to realize that the only care to be around programmers that do care about UI/UX experience and hanging out with designers is to be on the Apple, Google, Microsoft platforms.
Check on each of their conferences how many UI/UX sessions are there and how many show up on a random UNIX conference.
That's particularly interesting, because I wrote an XFCE theme in order to get:
- 1 pixel wide window borders (left/right/bottom)
- big thick corners to grab with the mouse
- and an aesthetically pleasing (to me) titlebar that is high contrast when not the focus (because that's when you're looking for a new window to select) and medium contrast when it is the focus (because most of the time you already know what you're typing into).
>Every restaurant and bar and cafe had their own way of doing things, and wanted our system to do it that way.
This can be applied to many areas. Our first product over at DaycareIQ was a childcare waitlist management app. It would allow parents to pre-register kids, place them in a queue until the site confirmed their place etc etc. In our minds it was a good way to keep organized and ensure that the waitlist was fair and equitable.
We showed it to many childcare centres and were met with "Well our flow is XYZ, can you change it so it does that." We ended up abandoning that app as no one was willing to change their process, some of which were just a pile of few hundred forms. When filling a childcare spot, they would just grab a pile of forms and start calling, only to waste their time as many kids already found another spot. Our app would allow parents to remove their kid from the list, ensuring that the person at the top of the list actually still needed a spot... but still didn't convince operators.
Off-topic, but you seem to have a lot of experience in this! Would you either have some more resources you could suggest on building hospitality software, or could you be open to giving some advice to an aspiring founder in the space? My email's alexander at ahult.com if so; I'd really appreciate it!
It was incredibly hard to make everybody happy. Every restaurant and bar and cafe had their own way of doing things, and wanted our system to do it that way.
We did have a few "rules" that helped make the system easier to use and to avoid stories like this.
We tried to ensure that nothing that was used more than a couple of times a day was more than 3 taps away from the main screen.
We also did a lot of visits to our customers. If there were sticky notes around the POS terminal, that was always a red flag that our system wasn't doing something the right way.
One important take away from my time at the company, where we worked fairly closely with our customers, is that people love sticking to the old way of doing things, even if there's an easier, new way to do it. If you changed this system to only require one click to change bookings, they'd probably still use a whiteboard marker on the screen, because that's the way they've always done it. Cargo culting is incredibly common for non-technical people using technology, and even fairly common for technical people.