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!
Even today for semi- or non-routine tasks I'll do weird stuff like copy text to Notepad to remove formatting then past it back into the same app/web page to enter information. I'll also do some weird things like instead of using an entire screen to read text on a long web page article I'll just keep my eyes near the top of the screen and scroll so my eyes don't have to move. Not sure what I'm trying to say but maybe there are entirely new ways of building existing app types out there that have an audience out there.
I wish we spent as much time on HCI in our field. I get a lot more value out of seeing how people I develop software for do their tasks and then thinking about how that could be improved. An implication of that is that I'm not building a fancy UI for my resume's sake; that I'm actually improving their day-to-day workflows. That takes some cost and time but in my projects nobody wants to pay for that.
> I'll do weird stuff like copy text to Notepad to remove formatting then past it back into the same app/web page to enter information.
I do that too! In fact, I do that so often that on Windows, I have the following workflow in my muscle memory:
CTRL+C ;; copy
Win+R ;; open "Run"
CTRL+V ;; paste
CTRL+A ;; select what I just pasted
CTRL+X ;; cut it out (disappearing text serves
;; as a visual proof of operation completion)
ESC ;; close the "Run" box, restoring focus
;; to original application
CTRL+V ;; paste cleaned-up text
I do that without thinking in under 2 seconds.
On Linux, I usually abuse the address bar of the browser.
I used to always have to do this as well (I work in graphic design and oftentimes I have to paste text from Word/PowerPoint into my layout/design apps -- it's a nightmare)
Then I discovered this handy little utility, PureText:
Wow sounds like a nightmare! Although I certainly have many muscle-memory-scripted tasks that I run like that :) On OSX command-shift-v is paste-without-formatting and seems to be fairly universal - I guess there's not a Windows equivalent? I thought that I recalled ctrl-shift-v working in most contexts on Linux to remove formatting as well but I've been using OSX for too long now and don't remember.
Same shortcut is convention in Windows, but it takes only one program you use regularly to not respect that to make you learn an alternative workflow, and then stick to it everywhere.
I also use the web browser for this, it's extremely efficient:
CMD+A,C,T,V,A,X,W,V
I don't even release the CMD key between presses and it's all done with one hand extremely quickly. I've often wondered if Chrome collects usage statistics on this and what it looks like from their perspective. "This user opens a lot of tabs, pastes stuff in the address bar, then gives up before the new tab page is even done loading."
I think software designers underestimate how powerful this sort of muscle memory is. Even if something isn't technically one action away, if you can get to it with a sequence of actions you can perform consistently right after each other, you quickly start to think of that sequence as "one action".
This is one reason why old-school, keyboard-shortcut-driven UI can feel so good to use (and why animations that block interaction are so frustrating).
I worked on a Windows Mobile (on the huge ruggedized devices) they were really slow, but the people who used them knew the screens so well, that they wouldn’t wait on the screen to refresh to navigate the screens and start typing. They would just take advantage of the keyboard buffering. I mistakenly changed the order of one field on the screen and it threw off all of the data entry. We could not reproduce the “bug” but we knew we shouldn’t be getting that many mistakes from the same people who were doing everything correctly. We actually sent the QA guy out in the field and he discovered the issue within an hour - the users weren’t looking at the screens, they were doing everything from muscle memory.
And which is why I abandoned both Windows and Linux for using Emacs as my OS :).
No, seriously. I try to port all my workflow to Emacs, because with all the power and consistency of that keyboard-driven platform, I can finally put my muscle memory to use.
Beyond that, I finally developed a habit of automating annoyances away. Today, if I do something frequently and find it annoying, I fix it with a script. Be it elisp (Emacs), CL (Linux - I use StumpWM as my WM), or AutoHotkey (Windows).
--
Actually, some random recent examples:
- I frequently deal with Lisp code that outputs large structured or semistructured blobs of text; at some point I decided I need a quick way to pipe such output to a separate Emacs buffer: https://gist.github.com/TeMPOraL/8715c9dd9837e0b601d1cdce059....
- At my previous workplace, I found myself pasting some strings to various communications channels quickly. Since I already used AutoHotkey to remap Caps Lock to CTRL, this is what I came with (and later expanded): https://gist.github.com/TeMPOraL/d330edccf8ba9a2b13d01b4e7f1....
The point of giving those examples, beyond obviously showing off :), is that this is what IMO good software enables. Improving your life on the fly, one simple binding or one simple script at a time. Scripting isn't only for shell commands. It's definitely useful for UI experience as well. I regret it took me that long to figure this out.
This is also why I try to port as much of my workflow as I can to Emacs. It's because Emacs makes such modifications seem trivial. If you need something to interoperate more, you can glue it with together with a little bit of Elisp. If you need something new, you can probably add it with a little bit of Elisp in no time. Emacs, being a runtime-modifiable, introspectable and tremendously well documented system with a decent REPL, makes this quick and relatively painless.
> On Linux, I usually abuse the address bar of the browser.
Same here. I used to disable “search suggestions” so I wouldn’t be sending all of that stuff to Google but at the same time search suggestions can actually be useful sometimes so now I have it enabled anyway, meaning that I send a lot of random stuff to Google.
However mostly it’s no big deal. The primary reason that I disabled search suggestions was that I used to type out the passwords for new accounts in the address bar first and copy them and then paste them twice into the password and confirm password fields respectively. Since then I’ve written a pass-phrase generator command line program that I named pgen [1] which I use instead, so because I no longer use the address bar for passwords there is rarely anything sensitive that I am typing.
If a website has password requirements that are incompatible with the passwords generated by pgen I have the terminal I just ran pgen in open already anyways so I paste back into it and modify the password to suit the requirements.
Ctrl-Alt-V for Office and its ilk. My tip is to always set to paste without formatting by default, and use the shortcut when you want to paste with formatting, because the fancy format you want is usually pre-selected on the menu, but the plain text format never is.
I use the Option+Shift+Command+V all the time, especially in emails - that text that I copied from SAP or a Word doc invariably has bizarre formatting and if I Command+V paste it into my email, now the rest of what I type after it is going to be screwed up. A four button shortcut sounds like a pain, but once you use it two or three times it comes pretty naturally. Similar to Command+Control+Shift+4 for setting up a screenshot that will grab straight to clipboard, it's easier than it sounds when doing it on the regular.
Yeah - seems like it would be one of those things that you could allow the user to configure and they'd set it once and never again. I suppose you could switch your client to plaintext composition, but would be nice if there was a setting like you describe "don't change formatting after pasting" and/or "always strip formatting when pasting".
A fast way to work around apps that can't strip formatting on paste: command+spacebar (open spotlight search), command-v (paste), command-a (select all), command-x (cut).
Maybe I'm pointing out the obvious for you guys here but most browsers have a "paste as plain-text" option. In Chrome it's CTRL+SHIFT+V and you can see it if you right click in an input field as well.
My Firefox doesn't show such option under right-click menu. But even if it's common in other browsers now, it wasn't when I needed it first, so I found an alternative and put the problem out of my mind. Thanks for pointing out that there is a solution in (some) browsers, though. Maybe it's time to abandon the alternative habits.
Setting up a shortcut to "paste as plain text" is a handy secondary capability. Being able to see/select your last n copied items is very helpful indeed. (Ctrl-Alt-H is my shortcut, and whenever I'm on a system that doesn't have it installed I become sad when that shortcut doesn't work...)
And if your browser is configured to use a predictive search engine you've just sent the contents of your clipboard to Google or Microsoft (or other search provider).
Doesn't that just bring up a dialog box where you have to search through the radial buttons for "Paste Without Formatting", select it with the mouse, and hit "Ok"?
An obscure keyboard shortcut (vs 4-5 common ones), finding your option, and switching to the mouse doesn't seem like a better solution. Plus it's not universal.
> I wish we spent as much time on HCI in our field.
So did I, but IME, time and effort spent on minor UX improvements are rarely justifiable to upper management, especially in the case of business software it won't generate more revenue, often because the people using the software are not the ones buying it.
I've had the fortune of working in a couple of places where the most hardcore users of our product were our own employees. So I often silently wandered into others desks and observed their workflows, it's amazing to see the little hacks they come up with because of their routine. Sometimes it's things we can easily fix but it's not prioritized. Quite often I've spent a couple hours of my free time hacking together some minor features to help these internal users and they are always amazingly grateful.
This is huge in publishing. So many workflows are outdated or require so much copypasting and customized scripts, etc, that it’s pretty ridiculous.
I’m part of a team searching for an appropriate tool and the pickings are slim. Thankfully the people buying the software that may be in use for the next five years to a decade are taking it very seriously and working closely with a number of experts around the company and editorial teams. They’re also very familiar with the regular workflows, so they don’t fall prey to salesmanship.
My schedule’s kept fairly open lately to give me “free time” to develop something to help with a specific aspect of it (as upper leadership isn’t openly keen on any in house development). It’s been very interesting working closely with the people who will be using it just 3 floors away on a daily basis.
I’ve done similar projects in the past and some people were ...more grateful than others...
But the current situation is a little different, and the art and editorial teams this time through have been fantastic. I think it’s because they know exactly what they want to make their days and weeks easier, and they’re so grateful to even get close. And I’m happy to try and deliver as much relief as possible.
Because Apple rose to its success partly because of its UX philosophy.
But I don't think GP is going to achieve their goal with this. On the contrary, I bet their managers already read that book, and that's why the UX sucks in the first place. The managers want to follow Steve Jobs' footsteps, and treat UX as a sales driver, instead of something that should be designed to make the end user productive and happy.
Part of the reason that Apple found more success after 1998 was the “consumerization of technology” the end user was the buyer and not the corporate IT department. The UX is a sales driver for the buyer. In the corporate world, the buyer and the user are not the same person.
But the iPhone has a major presence in corporate America, has first class support for Exchange servers and their are plenty of MDM solutions deployed for iDevices.
And Firefox recently fixed it so this shortcut works! (Previously it was hijacked to show some toolbar or something—don't recall exactly what as I always just groaned and closed it, then opened notepad...)
To paste without leading white space you can paste into Chrome's address bar and recopy the from it. It stops out any formatting and surrounding white space.
I think so. It's very rare that I need to paste with formatting. The majority of time that I actually use normal paste is when the source content is either of the same format or has no format already.
Word at least lets you choose the default action and offers a little contextual toolbar on paste to change the behavior for that pasted snippet as well. The options are iirc: Paste with original formatting, paste with formatting adjusted to document styles, and paste without formatting.
>> instead of using an entire screen to read text on a long web page article I'll just keep my eyes near the top of the screen and scroll so my eyes don't have to move
Yes! I do exactly that. I use the window frame to act as a ruler so I don't lose my position when reading left to right.
I also do the copy to Notepad, but since moving to Mac, Notes keeps the formatting by default, so I'm conditioned now to use Ctrl+Shift+V - on the second attempt.
Other things are in Word or Google Docs to automatically backspace auto corrections, such as automatic links in the document. I do the same with auto complete on my iPhone to remove the trailing space.
If you open it up in Automator, it'll let you see the steps, and prompt you to install it [which really just moves the file into ~/Services]. This makes it show up in every app's Services menu.
Once installed, you can head to System Preferences > Keyboard > Shortcuts > Services, to set a keyboard shortcut for it.
I'd love a utility that takes text from my clipboard, converts it to ASCII and strips all formatting, then pastes it. It would need to map Unicode (and other character set) characters to ASCII equivalents, but even if it covered only the common characters I would be very happy. Any tips?
On Windows, AutoHotkey has all the tools you need for this. The built-in `Clipboard` variable contains only the textual data, and the `OnClipboardChange` event allows you to watch the clipboard for changes. You could then use regular expressions to remove unwanted characters and formatting.
On macOS I use the fact that pasting in the console strips all formatting. `pbpaste | pbcopy` in my terminal pastes to plain text then copy it again. It doesn’t map Unicode to ASCII, though.
KDE's clipper lets you do actions, so provided you have a script to convert input text to unformatted or ASCII or what-have-you then it's 2 clicks to get it in to your clipboard ready to paste.
(shameless plug) I put together https://pastemagic.com exactly for that, except that I wanted to just preserve italics and links. Because for such a simple thing, there was no tool to do that.
I think one key takeaway which isn't directly mentioned in the article is that UX designers, especially on custom-built business solutions like this one, tend to have a pretty rigid concept of the user flow. But the most useful and time-tested pieces of software tend to be the most flexible; the ones that empower users to do what they want, when they want, on-the-fly. That's what's so powerful about a whiteboard; not the fact that it isn't software. They're infinitely flexible and easy to manipulate.
Excel is an (eghem) excellent example of this concept in software, as pointed out by another commenter here. It doesn't presume a particular flow or even a particular set of user stories. It gives you the tools to record and manipulate large amounts of data, no matter what it is or what shape it's in, without writing code. That's a powerful concept and one that more designers should keep in mind.
Another beautiful example is Trello. I've used several task trackers for software projects, Jira and Mantis several times, and my experience with Trello beats everything else.
Turns out, you don't really need complicated automated processes and different views for the same data (as abstractions lover in me was absolutely sure of). Doing task management manually and easily changing workflows on the fly is much more useful.
> Excel is an (eghem) excellent example of this concept in software
Excel is indeed an excellent example, and excellent software. On a related note, pivot tables must be the next best invention after the spreadsheet itself.
Reminds me of when I used to draw on CRT monitors because it was quicker to illustrate UX changes than to use the mouse / change code.
I know a lot of restaurants around here that use a sheet of glass placed over a printout of the seating chart to record reservations and which tables are clear / ready to be seated at.
This article buries the lead, the most important takeaway is at the end of the list at #6:
> to really find out what’s important to the users, and how a system is actually used, you need to observe real users, in the field.
Came here to say exactly that. The only relevant and important take away from this article is to perform proper user research. All the other insights will follow that.
What it tells me is that preventing the developers from talking directly with the users, a practice which is mind-bogglingly common (bordering on universal), is a hurdle which companies are incapable of overcoming. There really is no replacement for a developer who can become embedded in the organization which is going to be using the software, watching or performing the job themselves for any position which is going to be enhanced by using the system being built, etc. I have always wanted to do exactly this as a developer, and the closest I have been able to get was on a couple freelance solo projects. As far as I know there's not even really a name for a person that functions this way. The closest I've seen is "Business Analyst", but if you just look for positions with that name you find nothing even remotely close to actually doing that sort of thing.
As a developer, it is normal to look at a system and extract the generalities and patterns and systematize them. Then the users start using the system. And they always ask for the same things. Exceptions. The ability to cheat the rules they swore were "always" the case.
If they've got someone on the staff who knows just enough to be dangerous, their system will grow by bits and pieces organically, eventually resulting in a real nightmarish mess. For years I have wanted to try to design a system which actually has this in mind as a primary use case. Something which can be bit-by-bit 'expanded' over time with the special cases, exceptions, etc but which can remain sensible, maintainable, and tractable. It's possible that such a system cannot be made both as flexible as necessary and still usable by the average person, but I think it might be. Anything which accomplished the goal even partially would be pretty successful I imagine.
One problem with putting developers in direct contact with customers is that we developers tend to be more terse, more concrete, more exact, than the average Joe(lla). And that leads us to occasionally use the word "no". And that word infuriates and terrifies average Joe(lla)'s bosses.
I completely agree that good software requires this direct contact, but you have to find the right people.
For what it's worth, the author of the article misses one crucial aspect of the system: it allows customers to reserve online and via third-party applications. Checking in users (clearly) had a bad experience, but the fact that all upcoming reservations were made and listed is still important (and seemed to function quite well).
I think Norman's The Design of Everyday Things rings incredibly true to this story and its lessons.
There are so many examples in that book where users, frustrated or inconvenienced by the (high-tech) complexity of their tools, devise their own (low-tech) way to use a tiny subset of the features that just barely gets the job done for them--though perhaps not as creatively as writing on the screen here. One is the emergence of scrappy post-it-note instruction guides for basic tasks people would tape next to overengineered phone systems in the 90s. He also presents the concept of a 'gulf of evaluation' that makes contextualizes the difference between designer expectations and actual use (or the difficulty of getting feedback that would bridge this gulf).
The book---in its latest version, intentionally---omits discussions about modern software, but it does more than enough to prove its point with simple everyday examples. I'd highly recommend giving it a read to anyone!
I seem to recall reading about something similar regarding field testing of new gear for soldiers.
The generals and sales goons would come up with all kinds of "would it not be useful if they had XYZ on their helmet". but once given field trials the feedback was that while it was nice to have, it made said helmets heavy, leading to neck strain and problems with simply looking around.
If the position of objects in the UI is immutable, you can use the glass as part of the state.
This overlay over the screen reminds me of some video games systems that used transparencies for part of the scene, or at least a measure of color. Vectrex was like this: vector graphics, augmented with a game-specific acetate overlay that you'd put on the screen for that game.
At my old job the food and beverage department used IBM POS. I'm pretty sure it was touch screen but seemed to also have some extra detection from the screen edges.
One day a fly landed on the screen and managed to enter an order for a sandwich and two bottles of pop.
I don't know if there is a name for this law, but is true: every business app will get an 'export to excel' functionality. No matter how well is modeled or close to the user flow, the users will want to export the data in an excel - where they can be creative!
I've seen this before. The customer wanted a huge spread sheet converted into an application. Turns out the spreadsheet changed it's function from week to week. The user was using the spreadsheet to play with numbers and didn't need the application they asked for, they just needed an easy way to get data out of the database so they could play with the numbers and a way to get some data back into the db.
I have been telling this story to UX designers since I first read it. Fun to see it pop up again, it's one of my favorites.
My favorite part of UX is getting to go on site to see people's workflows in action. An example that comes to mind was working on an early iPad app for EMS / first responders. They already had toughbook-style computers in the ambulances, but had lots of complaints. One thing we noticed immediately was that they couldn't use the computers when they were wearing latex gloves. They actually tracked vital signs by writing them on the gloves themselves and attempting to transcribe them when they got back to the computer.
Just did exactly this an hour ago. Much easier than trying to type in those little boxes. I can put any value I want on my glove in any format or order. The computer on the other hand will barf if I try to put 120/80 in the pulse field, or anywhere, because systolic and diastolic pressure are two different fields. Seems like a great application for relatively straightforward pattern recognition, an empty text box and a heuristic that guesses what I mean and asks for approval.
Great story, and he's absolutely right about having the developers talk directly to the end users.
The systems built with customers where we talked to the end users both worked well and were well-accepted.
Other systems, where the managers insisted that we talk to a specified manager who would 'gather and transmit' the end-user requirements typically ended up being the endless projects that never quite worked. Yes, sort of endless billables too, but much less satisfying to both build and use.
If I were still developing software, I'd be at the point of insisting on direct end-user participation as a condition of doing the work, and primarily for the customer's sake.
Yup, I hate when managers do that. Where I can, I always push for direct developer-customer interaction, because it turns out that developers can communicate with customers just fine, and adding an additional indirection layer only loses lots of intangible or non-obvious information about the problem domain in the process.
The book referred to at the end of the blog entry is brilliant; reading case study upon case study on how projects derailed (if they were ever on track in the first place...) is a humbling experience for anyone who has ever found himself in the position of trying to figure out what a customer wants (often not what he says he wants, sigh).
The domain it is hosted on, by the way, translates roughly to bloodyshitesystem.se :)
I recently had a chance to visit a company in Glasgow, Scotland, that develops and sells a restaurant management system.
The owner told me something, that stuck with me.
They only hire people who have worked in the hospitality industry before. They wanted people to know the domain extensively, so they were more likely to understand what their customers were facing in their workday.
During my talks with various roles in the company, formal and informal, almost all of them would refer back to a real-life situation, where they would face a problem - and how they tackle that in their software.
Long story short, the UI devs aren't dogfooding their product, right?
I mean if the company just went out for beers one night and had one person try to use the software to "seat" each employee, they'd figure out pretty quickly that there are too many clicks. Especially if the rule is to take a drink for each employee seated. :)
Precisely. What you suggest here would be a good start - if they took notes, even one evening would pick up probably 20-30 significant UI issues.
Next, get the most attractive member of the waitstaff to go through the same process with your prototype. Ideally offer minimal prompting. Ask them at each step what they expected to see. Take notes. Repeat for the rest of the waitstaff, if possible.
The designer of a UI being able to do everything they need with it quickly and easily is the first step. The intended user being able do so with minimal training is a much later, much more important step.
I think that's a bit dangerous as developers often think differently to non-developers; also they already know how to use their product since they wrote it. Needs to be tested with actual end-users.
You are absolutely right about the danger of knowing your own product too well. On the other hand, a developer is often in a much better position to know how to "make the computer do the work" than the end-user.
Ideally, you'd test with both...several times. It would be wonderful if clients were willing to pay for this level of software perfection!
There is a kind of inverse in certain niche industries where the communication structure of the organizations is a result of the software. Like the people are as rigid/dysfunctional as the software. Sometimes there aren't nice solutions like dry erase marker on screen.
If you work in one of these, it's the most uncomfortable feeling. One benefit is that it can be motivating to create alternative software to claw your way out.
Unless the software mirrors the dysfunctional organization...
If you are carpenter holding a hammer you see nails. We are programmers so we see user flows. Put the hammer down, clear your mind. Look at what the u̶s̶e̶r̶ person is doing.
Reminds me that some time back HN linked an article showing that floppies (the 3.5" type, not the 5.25" kind) were still used in Norway to distribute data to doctors.
Thing that came up in the comments were that said doctors were holding on to and older, DOS based, patient record system, because it was all keyboard operated. This in turn allowed a seasoned doctor to work the UI while maintaining a dialog with the patient.
> [...] Henrik noted that a post-it note covered the upper right corner of the screen. Why?
> Well, when patients are ready, they’re supposed to press a ”Save” button on the screen.
> But a lot of them instead press the Windows’ ”Close” icon in the upper right corner (perhaps they were determined not to let the next person see their entries).
> But this also shut down the machine, and the data they had entered were lost!
> Solution: cover the icon with a piece of paper or tape!
I once worked in an architecture/engineering firm with an old school architect who worked wonders with pencils and inks. He had a cartoon over his desk: "Computer aided drafting." Showed a crusty, bearded architect sitting on top of his computer as though it were a chair, while drawing with pencils as usual.
Back on topic, the solution as I see it is a data store, and different interfaces customized for each employee. Expensive, but the bartender and the hostess don't need the same information.
I was at one of the McDonalds last week with one of their updated computer ording kiosks. They place about 15 feet from the cash register. So if they is a line of 4 people or more, these kiosks are right in you face and tempt you to use them rather wait in line.
So with four people ahead of me I started using the kiosk. But the computer menus for both items I wanted to order where three levels deep. The line moved faster than my use of the kiosk. So I abondoned it a returned to the line.
Having been spoiled by voice assistants, I'd like one I could bark my order to and have it done.
They central probelm here there is no way to satisfy everyone's needs in the POS terminal. The bartender will have differnet needs than the hostess, waiter, manager, or kitchen staff. It would be nearly impossible for everyone to agree.
Simplicity is the key and I found this restaurants solution to be extremely intuitive. More steps to sit a table simply because the technology is there to acquire more data points, is not always the correct solution.
What is important is the business objectives. It does not matter if a whiteboard marker is used or a mouse is used that sends signals to an elegant micro-service architecture.
The customer is always right, and in this case the restaurant is the customer.
This is a great example of that principle and in the end the customer was happy and used a, for their business need, a good system.
Another upshot is that this system with a whiteboard marker is avoiding personal data processing that is not needed (the GDPR data minimization and storage limitation principles).
I hope no one is depending on the reporting from that software to make any sort of decisions (What do you mean no one showed up for their reservation this past month?!?).
Or maybe at the end of their shift, they go in an "clear" the reservations who showed?
My guess is there's no reporting / data analysis on the back end.
At a successful restaurant, they don't care about reporting, data analysis, or who sat in what seat, just that all seats were occupied. That is already accounted for by looking around the rounm and by the numbers at the end of the night. The reservations are for the seating not the take.
If there is any data analysis it has to do with where the next restaurant can be built.
Not true at all. Restaurants definitely care about things like total covers, check average, profit per seat, turnaround time, etc... There's massive profit different between say, 1 turn and 2.5 turns. Simply filling every seat once per night isn't good enough for a lot of restaurants.
My cynical thought on the matter was more along the lines of "any booking that doesn't go into the system is probably easier not to report on your taxes"...
It’s a combination of they bought the wrong system and the designers didn’t listen. If the product is used successfully in thousands of restaurants without the pen hack then it’s more of the former. If this is one of 25 customers using this system then it’s more of the latter.
It's like SAP. They deliver tools that adapt to your business model, as long as you adapt your business model to do everything the way it works in SAP.
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.