[HN Gopher] The reason you're not more productive at work? It's ...
___________________________________________________________________
The reason you're not more productive at work? It's not boredom,
it's bad UX
Author : hiddencache
Score : 80 points
Date : 2021-08-21 13:03 UTC (9 hours ago)
(HTM) web link (www.fastcompany.com)
(TXT) w3m dump (www.fastcompany.com)
| crazygringo wrote:
| I've sometimes wondered why it seems companies aren't measuring
| time wasted by slow applications.
|
| 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.
|
| [1] https://en.wikipedia.org/wiki/Time_and_motion_study
| gonzo41 wrote:
| In contrast, look at AutoCad or Photoshop, and ArcGis. Mega
| complex ui's, what they do is more like programming than office
| productivity. So user workflow is going to be more difficult.
|
| 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.
| specialist wrote:
| I used to joke "AutoCAD is an 800lb angry gorilla sitting
| between you and your work."
|
| 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.
| b3morales wrote:
| I've become a bit skeptical that the "loading, please wait"
| delays are real. It seems like they're often used for upselling
| me to some other product, while I'm just trying to get my
| current one fixed.
| kitsunesoba wrote:
| Similar observations could be made about jankiness/glitchiness
| in software. The amount of time burned on fighting misbehaving
| software has to astronomical, in some cases eclipsing the
| productivity brought by the features that dev energy was spent
| on instead of general stability and quality.
|
| 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.
| georgewsinger wrote:
| Interesting point.
| jrockway wrote:
| > 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"
|
| 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!)
| wjnc wrote:
| Perhaps I'm totally going Euro but shouldn't the MBA in
| charge at least try to measure employee happiness, churn and
| absence to try and measure if the work is fulfilling? I work
| at a large listed insurer and I know nobody shits on the hard
| work customer facing colleagues do. It's hard work, with
| often old IT and usually customers outside of the fast track
| that have unique needs. Our senior management is motivated to
| help say once a year to keep a feeling for both customer and
| colleagues etc.
|
| 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.
| ant6n wrote:
| I'm reading this comment because I task-switched away from
| VSCode which is hanging again. Waiting for glitchy software
| takes you out of the zone and makes it more likely to go to
| reddit/Twitter/hn and lose a lot more time than the glitch.
| LocalH wrote:
| Call center metrics are _all about_ average call length.
| However, the slowness of the software is largely ignored, in my
| experience. I worked at a call center once where logging in to
| the network would take approximately _fifteen minutes_ ,
| depending on workstation, before you could actually start
| working. They just didn't care. At this particular call center,
| average handle time was expected to be kept under 6 minutes.
| One day I had a very good average of under 5 minutes per call,
| and I received a single inbound call that required use of their
| translation service (which was a number with which you would
| dial and initiate a three-way call, and that would translate
| between you and the caller, with all the requisite delay
| between communications that one would imagine). That call
| ballooned into a 45-60 minute ordeal that totally screwed my
| handle time for the day. The shit cherry on top? The next day,
| _I got bitched at because my handle time for the previous day
| was too high_. When I said "well, that one call was a
| translator and took like an hour" the only response was "your
| handle time is too high, don't let it happen again". By the
| time another week had passed, I had already left the position.
|
| Call center jobs are largely exploitative and demeaning.
| Outsourcing customer service should be illegal, period.
| oblak wrote:
| There only two things I remember about my first day at a
| large telco. The one relevant to this topic was the call
| centre. I had never seen cubicles in real life before. Looked
| absolutely horrible even from the outside. What really made
| an impression on me, though, was the fact that they had this
| printed owl on the door. Immediately told everything I needed
| to know about the place
| tomp wrote:
| In my free time / personal projects, I've slowly been moving
| towards this mentality as well. Whenever I start some new, long,
| dreadful task, I always ask myself, "how can I make this as fun
| as possible", then start creating better and pseudo-GUIs (Trello
| or Jupyter usually being the first iteration!) to help me get the
| job done!
| tomxor wrote:
| Time to boot my laptop and open browser: 5-10 seconds
|
| 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.
| adzm wrote:
| A huge factor in moving on from my previous position was that I
| had to use Salesforce all the time, which has a terribly count
| clunky and slow UI and half-baked knowledge base and search
| stuff, ugh.
| oxymoran wrote:
| Enterprise software is not going to ever be fixed until people
| start to realize that the people that actually do the work need
| to be heavily involved in the design process and the developers
| need to be embedded in the actual underlying job more thoroughly.
| The idea that some developers and process people can make high
| quality insurance claims software for instance, without actually
| knowing who's to handle an insurance claim is preposterous to me.
| jdgoesmarching wrote:
| Agree completely. When you prioritize the requirements of
| infinite shareholder growth over people who actually make the
| product and do the processes, you're not optimizing for the
| best product or processes.
|
| 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.
| skohan wrote:
| Couldn't agree more.
|
| 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.
| dheera wrote:
| Absolutely. JIRA has one of the worst UX I have ever seen.
| Creating a ticket itself is so painful that it's easy to be
| lazy to not do it.
| petepete wrote:
| Definitely going the GitHub route next time time I'm moved
| onto a new project. The past two have used Jira and Trello
| and both are just a continuous source of frustration for
| me.
| th5 wrote:
| Curious what you don't like about Trello. I rather enjoy
| it. It's the only "proj mgmt" software I keep coming back
| to for the last decade.
| TheMightyLlama wrote:
| I've got to say that this is a problem with relying on the
| UI itself. When working with a development team I always
| provide as many options as possible to automate that
| worklflow.
|
| 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.
|
| https://gist.github.com/TheMightyLlama/9427202
| kayodelycaon wrote:
| It can be easy to create tickets in Jira using company-
| managed projects. The problem is the people who set up Jira
| see all of these knobs and buttons and feel like they need
| to use them. Creating tickets in my department require two
| things: ticket type, summary. We use procedures, not
| software to enforce the rules.
|
| 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.
| kwertyoowiyop wrote:
| Ugh, Jira is just the worst. I've used a lot of software but
| Jira's slowness and lag made it the one I dreaded most. Every
| - single - thing - needed - three - to - twenty - seconds.
| MilStdJunkie wrote:
| Making a new system recently I did exactly this. I basically
| joined the group as a low-level doc-pushing twerp and worked
| through everyone's jobs. _Then_ we started sketching out the
| system, having seen the pinch points and dead ends.
| Unfortunately, leadership later threw out all our design
| decisions, because they had a "Perfect Product Architecture"
| they were trying to enforce at the time.
| menotyou wrote:
| I studied computer science with a minor in psychology. It's long
| ago, but at that time I some courses on the topic of ergonomic
| design of UIs. Shortly speaking every UI which stops the user
| from be interrupted in is workflow by waiting or searching is a
| microstressing event. (Interruptions are the most important of
| all stressors when working). Many microstressing events leads to
| stress and stress leads to bad productivity.
|
| 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>
| nobody0 wrote:
| And also inertia, I found a simple trick that gets me into a
| quasi-flow state zone, which is telling myself that I will just
| do it for ten minutes. Then I don't have to analyze and do the
| inner talking for another ten minutes.
|
| 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.
| armchairhacker wrote:
| Bad UX absolutely hurts productivity, but the reason I'm not
| productive is still boredom and short attention span :)
|
| 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.
| snth wrote:
| I agree with this article that the UX of the software I have to
| use for work is terrible, and it's very frustrating and
| demotivating. But their proposed solution at the end- internally
| developed software, seems to be the worst offender. The worst
| software I have to use tends to be internally developed, poorly
| documented, supported, and designed copies of widely used
| software like bug trackers, project management tools, CI systems,
| etc. The justification for reimplementing these internally is
| often security, scalability, or integration requirements though,
| not UX.
| ssss11 wrote:
| It might depend on the internal talent, but, ERP vendors are
| always going to be incentivised to deliver "just good enough"
| software and then sit back and take in the cash.. so I'd think
| with an internal team you _may_ have the opportunity to do
| better
| jaclaz wrote:
| I agree while disagreeing, it depends greatly, some anecdata.
|
| 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.
| travisjungroth wrote:
| > 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.
| jaclaz wrote:
| Sure, there are several issues in the process (hence it is
| so difficult) the expert(s) must be actually expert (not
| that easy[1]) and the software house programmer(s) and
| manager(s) need to be open-minded and willing not to take
| the (usual) shortcuts.
|
| [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).
| oblak wrote:
| I was so impressed the first time I saw a relative use their
| government mandated accounting software for DOS. That woman
| was going through forms faster than me doing mortal kombat 3
| combos. Not sure that would be possible these days with
| remote databases and such.
| paulryanrogers wrote:
| > it was much faster to use than any windows based program.
|
| 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.
| Aune wrote:
| I spent 5 hours doing a 15 minute task this week. The program
| kept crashing, then you have to wait for five minutes since the
| program runs a net liscence that needs to time out before you can
| restart.
|
| In the end I found a 40 minute work around.
| AtlasBarfed wrote:
| I recall another recent story lamenting that software had not
| produced massive gains in productivity in essentially the 2000s.
|
| 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.
| simonbarker87 wrote:
| This is my primary gripe with MS Teams, it might be free with
| Office 365 or whatever but I'm pretty sure the time lost due to
| its flakiness and rubbish UX costs more than Slack or similar.
| ssss11 wrote:
| It's UX is unbearable! Individual functionality is pretty good
| - teams channels, chat, video, but the UX bringing these things
| together is total garbage!
| animesh wrote:
| Thank you for saying this. It's become so much of an annoyance,
| that I am actively seeking to read people talk about how much
| it sucks.
| perryizgr8 wrote:
| Same with Google chat. It is bundled with gsuite so company
| thinks it is a waste to pay for something property like slack.
| But Google chat is literally the worst software I've used.
| Something as simple as search is broken every other week.
| geysersam wrote:
| Google Cloud web UI. Navigating between different
| products/settings is super slow. I don't understand why it is
| loading that much. The CLI is good though
| travisjungroth wrote:
| Internal tools also help get around the "9 babies can't make an
| engineer in a month" (or whatever it is) problem. Netflix (where
| I work, listed in the article) is maybe the best example. There's
| a limit to how many engineers you can have working on Netflix's
| _1_ flagship service (it 's a big limit). You can increase that
| limit by having other engineers come in and build tools for the
| whole company. I'm also surprised what percentage of engineering
| teams are directly "developer experience" at big orgs. It's
| probably < 1% but I think it should be more like 5% (probably an
| obscenely wrong opinion).
| Chris_Newton wrote:
| I agree. Developer experience is just user experience for one
| specific type of user, so we definitely shouldn't underestimate
| it.
|
| 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 calculation1 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.
|
| 1 https://news.ycombinator.com/item?id=27420500
___________________________________________________________________
(page generated 2021-08-21 23:02 UTC)