The reason you’re not more productive at work? It’s not boredom, it’s bad UX
fastcompany.com
fastcompany.com
I can't count the number of times I've called customer service and have to wait 2-3 minutes for the agent to bring up some screen as they apologize and explain "our systems are really slow". It regularly takes up a majority of the call's time.
Back in the early 1900's, time and motion studies [1] in factories were all the rage. And today Amazon certainly optimizes for the actions warehouse employees are required to do.
But when it comes to the actions people do with computers, I've never once seen a company actually measure wasted time waiting on slow applications. It seems like such an obvious thing to try to optimize. And it's not like it requires constant surveillance or anything -- it's just statistical sampling. Watch 10 randomly selected employees for two hours each or something, with their consent.
In many cases "good UX" is impossible to measure in any conventional sense. But when it comes to repeatable enterprise tasks, the time aspect actually can be measured.
Does anybody know why companies don't? It feels like such low-hanging fruit.
I have a friend who works in a call center. They work 10 hour days with no breaks between calls (the queue is often 40-50 people deep). (They do get the federally-mandated breaks of course.) "Our systems are really slow" is 100% true, but is also probably a welcome break for the agent. So if you are the clever software engineer that goes in and removes the sleep(180s), that's probably great for a few hours until all the call center agents burn out and leave early and use their spare time to start organizing a union. (Of course, if you save 2 minutes a call with software, you can just give people a mandatory 1 minute break between calls and come out ahead -- a true win/win. But that would require that the software team and the call center management team coordinate, and I don't think that's ever happened once in the history of large companies. You'd be the first!)
I would split your point in two dimensions: 1. Software should support efficiency and speed. (We often fail at that.) 2. Tough jobs exist and it’s up to the employer to make them worthwhile and at the least prevent burn-out.
DDG suggests that this is a leading call centre industry publication. This is their article list:
https://www.connectionsmagazine.com/articles/by-topic/
I've skimmed a couple of sections. There are a couple which look at workplace issues (career & self-improvement, workfroce management). Nothing jumps out immediately, but there might be some hints.
Note that what you find in articles and practices on the ground ... may differ.
Vendors advertising workforce-related systems and services (especially monitoring, tracking, recruiting, etc.), or legal / compliance organisations, could also give some possible insights.
Overall, it's a low-wage, low-skill, but also low-hazard environment (no dangerous equipment, encounters, etc.). Much of it is outsourced to low-cost regions with many English speakers (Philippines, India, Mexican border towns, Florida, etc.). Alternative employment may be scarce, unemployment high.
Change any of those dimensions and you might see conditions improve.
I've worked on in a large bank doing sales with slow IT systems, (The Mainframe was awesome quick though, shout out to black screens!). The bank coached staff to use there tools in an order and structure their conversations so they'd have buffer for information and systems to be there when needed.
Warehouse work is very repeatable compared to most work with a computer.
Then I met a UI researcher, hired by Army Corps of Engr to explain the missing productivity, who went way past time & motion to strategies. The interplay between tools and techniques, influencing how people organize their tasks. Matrices to highlight weird noun (line, circle, text) and verb (copy, move, delete) interactions. In other words, he showed how strategies from manually drafting did not translate to CAD and proposed new strategies (metaphors) and training appropriate for the new medium. Then validated his ideas with usability testing. Brilliant stuff. Like facepalm obvious once you see it.
Crickets.
Both Autodesk and Bentley Systems were hostile to user centric design based on real world data and lived experiences. The geeks and sales pukes who had never designed or drafted knew what designers and drafters needed, so piss off.
Besides, they're printing money, validating their efforts. And you aren't. So piss off.
Lather, rinse, repeat.
That's because customer support is the number #1 variable cost on that kind of software.
If you change anything, you start absorbing customer support calls from your enterprise customers.
This is how I knew that Microsoft doesn't carry support costs for Office and Windows--they rearrange GUIs willingly.
My mentor at that time was an AutoCAD dealer. He (eventually) explained the value added reseller racket to me. Very similar to franchising.
Autodesk and others sloughed off most marketing, sales, inventory, shipping, and tech support onto their dealers. Their reasoning, IIRC, was that while dev cost 7% of revenue, those other activities cost 30%. Why not get rubes to cover that overhead?
Further, turnover in the dealer channel was about 1/3 per year. A typical dealer would refinance their house (or whatever) for a few $100k. Burn thru it trying to get established. And there'd be 2 more wannabe dealers waiting to replace them.
It was very hard to not sell AutoCAD for a loss.
There were a few tricks to surviving and profiting. Consulting, training, and hardware, of course. The most capable productized their AutoCAD addons. The most successful of those then matured out of dealerships and formed their own VAR rackets.
My mentor created Rhino 3D. Most of the tech and code started as AutoCAD addons. Until they had bootstrapped a standalone MVP. https://en.wikipedia.org/wiki/Rhinoceros_3D
--
This was the 1990s. Autodesk is now the Computer Associates of abandonware graphics programs. Some of those legacy apps probably have enterprisey support contracts, so you're probably right about that. At a guess, it's probably part of the subscription models (everyone trying to copy Adobe's success).
Quite alright. I don't mind having to defend my positions--downvoters with no comments, however, piss me off. :)
> The most successful of those then matured out of dealerships and formed their own VAR rackets.
Yeowch. :(
I didn't know that Autodesk sloughed off the tech support. I'm not surprised.
Call center jobs are largely exploitative and demeaning. Outsourcing customer service should be illegal, period.
Take Photoshop for instance. Just about anybody who spends even a moderate amount of time in it will tell you that even though it's become more capable in the past 15 years, it's also become a lot more frustrating and bug-ridden. Personally speaking, I would be just as if not more productive using something like Photoshop 7/CS1/CS2 than I would be with Photoshop CC.
I have to use JIRA at work, and it's absolutely awful. Every action takes up to a couple seconds to execute, many tasks have no way to be automated or done in batches, and some seemingly simple actions require jumping through several unintuitive menus to complete.
To me it's clear that the people making this software almost certainly can't be the ones using it, and the people generally choosing and paying for it probably are also not the ones using it heavily day to day. Otherwise there's no way this level of performance would be tolerated.
There are several 'weak' bits of the UI though, like not being able to open a ticket in its own window, having a clunky search and an excessive amount of horizontal scrolling on larger boards.
This might take the form of integrating bitbucket with Jira such that you can assign a commit to a ticket or advance or close a ticket.
A few years ago I was looking at the jira API and managed to dig into the documentation. The result was a small gist which contains some of the harder to figure out actions. Including creating a new ticket.
Once I finish our migration to Jira, other departments will have different screens that require a few more fields like description. My goal is to keep these to an absolute minimum.
Configuring this stuff is a massive pain in the ass but the day to day use is manageable by creating custom boards and saved searches. A some training and documenting for my team takes care of the rest.
For my coworkers, it’s no more painful than the workarounds needed to make a “simpler” system work. GitLab and Github do fuck-all to support our workflow. Jira allows me to tailor it so both my team and management can understand what’s happening.
European countries are at least familiar with the idea of codetermination - having workers vote for board representation. Sweden, the Netherlands, and Germany practice some form of this to different degrees. In the US (and especially in the tech world) we are allergic to the idea that anyone besides the bagholder should have a role in decisionmaking.
Time to load and login to slack: 120-180 seconds with about 7 clicks
... sometimes I even have to wait a while for it to catch up with my typing like i'm superman or something. At which point I usually revert to copy and pasting messages from VIM... that's how slow slack is on a 2 year old laptop.
Also, don't try to automate just now, try to do it few times, then write down the steps, and selectively automate them. It's actually a good way to train yourself to live with boredom. We tend to find hyper stimulus, that's how we were wired. And we waste a lot of energy not in doing the chores but worrying about them.
It occurrred to me that someone once said that learning math and other subjects in school is training yourself to do the mental chores. And patience is such a rare thing to have in this constantly attention-grabbing society.
A balance check is important, do give yourself something else to do when you leave the work.
https://www.kilobitspersecond.com/2020/09/22/people-expect-t...
In the old days of DOS, circa 1992, I worked in a construction company, a program to make public works accounting was bought (at a very dear price BTW).
It soon became evident that the programmers had (maybe) read a couple of (theoretical/outdated) books on that particular type of accounting whilst they never spoke with an experienced accountant, let alone ever done any accounting themselves.
When the program crashed - actually because of an overflow when we reached on a site works for more than Lire 9,999,999,999 - and some two years of accounting had to be recreated manually (imagine 12-14 people scribbling day and night for one week) because we needed to recreate on paper the progress report to get paid as soon as possible (the software company people were on holidays for the month), we decided to become "independent".
We found a freelance programmer that started working side by side with one of our most expert accountants, and he created (if I recall correctly in three months time or so) a simple/rough program (mind you those were dbase III/Clipper days, no program was actually "refined" from a UX viewpoint) that simply worked.
We kept using it until the late '90's switching to a (hardly better) commercial program in Windows 2000 times.
The original clipper program had its own little quirks and you needed to learn a number of combo-keys to work with it, but once got the hang of it, it was much faster to use than any windows based program.
Same thing happened to me with a hotel managing software, the old software had been originally written by someone who had a cash register maintenance business and actually knew how the actual operations are carried in practice, when it was needed to switch to more modern software (mainly because of some changes in the Laws) I tested some 5-6 of the most common professional (commercial) softwares around, and while 3-4 of them were simply jokes, of the 2 remaining we didn't actually choose the "better" one, but rather the "less worse" one.
And still a number of "common enough" operations are incredibly complicated/take too much time when compared to what the old one could do.
I believe there is nowadays this "detachment" between programmers and actual (expert) users that greatly impairs the usability of software.
I don't think this is new. I think it's a long standing issue and a huge issue. I worked on home appraisal software and I regret not learning more about the job up front. After like 2 years of developing the app and getting approximately nowhere in the market, the software team actually went on an appraisal. It was eye-opening.
I've also seen the "expert in the room" hired twice and neither time worked (small sample size). I think you need more info in the brain of the dev team, and to have solutions bounced off a bunch of users. One expert ends up as kind of a silo.
[1] this is a pet peeve of mine, but at my age I can see the difference between seniority (common enough) and experience (quite rare).
In retail and later as a software engineer I've seen that expert systems need keyboard shortcuts. Ideally the fewest possible for the hottest paths. Yet for onboarding you need the most obvious and relatable UI. Windows apps can be both if well designed. Console and terminal based apps generally cannot pack as much into the UI and most folks don't know them before joining.
In windows (or more generally GUI) you usually need to constantly move your hands from keyboard to mouse (to click a button and "go ahead") and then back to keyboard to type soimething, then mouse again, etc.
I believe this is only due because of the choices of the programmers that used some "default" modes.
To give you an example the good ol'Dos program I was talking about used Enter to confirm data typed in a field AND move to next field, to go back to a previous field it was Ctrl+Enter, then you had to press F8 to confirm the whole form and exit to the main menu or F10 to confirm the whole form AND go to the next form of the same type.
When you got to a field like "state" or "country", that need to match an existing database, windows programs mostly have a drop down list (and you need the mouse to open the drop down list and scroll down until you find the one you want), the old program allowed to either enter the two-three letter country id (like IT for Italy, DE for Deutschland, etc.) OR to type the first few letters and then autocomplete with - if I recall correctly - F4.
Dates could be typed without separators, i.e. 22082021 and when you pressed enter the field would be automagically formatted to 22/08/2021, currently in lots of programs (or web sites) you have to click and then a calendar pops up, and you have to click three times for day/month/year, some "smarter" ones have a button for "today" but that, for a field like "date of birth" makes no sense whatever.
This latter is a pet-peeve of mine but 3/4 to 7/8 of all web shops, including those that are clearly national only have a drop down list for countries that invariably starts from Afghanistan, which possibly represents 0,0000000001 % of the orders.
Then you have "tabs", on a huge screen 1024*768 or higher resolution the actual form is a tiny window, and you input name/surname/birthday/address, etc. on it, then you have to switch (why?) to another tab to enter (say) fiscal data and to yet another one to add notes.
Of course there are also better UI's, but the large majority is as I described above.
I can see the advantage to developing something in-house if there aren't options that meet some special need, I just personally haven't seen it work out much. Maybe because of the size of companies I've worked at. I've definitely written helpful software for myself and my own team.
Terminal/3270 screens may have been ugly, but they show about the same amount of information as a modern enterprise app does.
The sheer waste of modern CPU speed is why there isn't anything big coming out of the screenpusher labor economics. Why I have screen lag in a modern PC is mystifying. It should basically NEVER happen.
Seriously, when I was more motivated I used to write code in garbage Xcode which was slow and crashed all the time. I just powered through. Now IntelliJ offers crazy code completion and instant refactoring/navigation, but I space out every time I have to wait 5 seconds for the app to build.
I’m reminded of an HN discussion from a couple of months ago, where we were talking about writing code for computers to run vs. for developers to read. I did a quick calculation¹ of how much time is wasted by some modern dev tools just by having a few seconds of delay before giving results. Spoiler: It’s crazy how much time we waste that way if millions of developers are using the tool regularly.
If one way to be a 10x developer is to help 9 of your colleagues become 2x developers then someone who creates excellent developer tools might be a 100x developer just within a large organisation, or orders of magnitude more if the tool is released openly. Personally, I’m hoping for someone to write a good, comprehensive standard library for JS/TS data structures and algorithms and convince the major browsers to include it out of the box. I don’t know how to measure the amount of time that could be saved firstly by making it easier for millions of web developers to write good code and secondly by severely cutting back the huge dependency trees that result from the current culture of pulling in tiny dependencies to do tiny jobs all over the place. It must be astronomical.
Focus Stealing
I'm using many apps and portals over the internet on Tuesdays, and I would be so much more productive if I could start something in one app, then leave it to do something else and only return to that app when its done thinking.
If I could run all of my work's accounting apps in Linux, I'd be i3 all day long.
What can I say? The last 10 years UIs went ergonomically from bad to worse.
Loading time of screens are to long nowadays. While loading and rendering the browser typically keeps on moving screen elements around. Each of this movements interrupts the search for the relevant information for the eyes. Each of these movements enforces the eye movements, search for a new object to focus and accomodate its lenses.
Nowadays it is in many application not uncommon to have several of these movements in one loading of a page.(This problem comes is actually somehow connected that HTML is a sessionsless protocoll in connection with modern JS which makes increases loading times. Using microservices quite often lead to bad UI because of the uneven loading times).
Other problems are coming from opting into gimmicks like using "effects" or to scrolling instead of paging. While scrolling and paging is ok of websites (in most cases), in most business application you want to avoid this because it is coming with the same problems as slow loading and moving elements on the screen.
Another set of problems coming form bad choices from UX designers. Look at the example in [1]
- Wasting of precious screen real estate for white space leads to searching for information you need and again: scrolling, eyes movement, accommodation.
- Lack of optical guides like lines. Try to set all cells to white background in excel and start working then you see the effect.
- Lack of contrast: Dark grey text on light grey background (which MS Office does as well in their settings menu [4])
- For design purposes the chosen fonts are much to small to be readable in a convenient way
- Header and actual data (i.e. relevant information) are indistinguishable.
Finding Information in the "basic data" section in [1],[2] is a hide and seek game for the user. Assume you seeing this display 50 times a day during your work. You are guaranteed to come home with a headache
Another example of bad UI are the tiles in W10 start menu [6]. Instead of allowing the eye to scan the entry from top to bottom in one line, the eyes are forced in zig-zag of the tiles and they have transverse a bigger space on the screen because you have much less tiles on the same space as lines is the old menu structure.
Another example what causes stress and frustration with software is when the UI of one software does behave differently the others. Your software should generally be designed as what the user expects. An example of a bad UI for this case is MS-Outlook [3]. Some of the more often used navigation elements (switching between mail and calendar) are moved left bottom corner. This is against user expectation. Microsoft Outlook moves its navigation elements to somewhere where no one else put them. No one would design a car with gas an break pedals exchanged and putting the gear shift in the trunk. Microsoft Outlook does so with its navigation elements.
Another common problem is that to many screens in your application look to much alike. While it is desirable that the screen designs meets expectation, it is important that the user can spot immediately in which screen he is working. When for
Nested menus / hidden functionality is an typical issue in software as well [5]
Flat design is generally a stressor because is lacking optical help.
Examples of bad UI:
[1] <https://blogs.sap.com/wp-content/uploads/2017/08/Object-Page...>
[2] <https://experience.sap.com/fiori-design-web/wp-content/uploa...>
[3] <https://topbestalternative.com/wp-content/uploads/2020/08/ou...>
[4] <https://storage.googleapis.com/fe-storage/2020/09/85e03ded-e...>
[5] <https://docs.microsoft.com/en-us/azure/devops/test/media/new...>
[6] https://filestore.community.support.microsoft.com/api/images...
[7] Overloaded screens: <https://www.it-telesis.com/wp-content/uploads/Analytics.png>
Iteration times should be one of the major tenets in our programming books other than the stuff they recommend to derisk your software.
In the end I found a 40 minute work around.
jesus fucking christ its 2021 its still painful, haha.
The speedup happened on the exact same computer - same CPU, same memory, same hard drive. So it had zero to do with hardware, and everything to do with coding. And if you threw faster, better hardware at the problem, it would not change anything for shit.
So never depend on the false hope hardware will solve shitty software design issues. The whole idea that it is cheaper to code fast to get something out fast is bogus. It just takes knowledge on how to do it correctly in the first place. I don't think the coding that I did took any longer than the original coding. The original person just sucked ass.
So, whatever language you code in, you should start watching videos or reading articles on how to maximize your application's speed. It usually is not that difficult, if you spend some time. Most of it you can copy and paste. Do searches on "Top 5 ways to speed up x language". So easy.
That really drilled the lesson home on the importance of the approach to making real fast systems on the design side and not on the hardware side.
There's a lot of low-hanging fruit when it comes to performance and quite often it seems to be left in the tree...
The thing is that once you learn these techniques, everything that one subsequently writes will automatically incorporate them. Once one knows how, it would be super difficult not to use them on every project. But, yeah, I usually like to read "Top 3 ways of optimizing xyz".