5 ms·

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 soluti

by snth 5y ago

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.

jaclaz 5y ago
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 5y ago
  > 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 5y ago
    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).
- paulryanrogers 5y ago
  > 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.
- oblak 5y ago
  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.
  - 5y ago
ssss11 5y ago
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

by snth 5y ago

jaclaz 5y ago

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 5y ago
> 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 5y ago
  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).
paulryanrogers 5y ago
> 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.
oblak 5y ago
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.
- 5y ago

ssss11 5y ago

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