I might work in a “Hacker News bubble” but this type of story in 2023 actually surprises me. Software development has become product-driven, some may say even a little too much, and data-driven, both progress around user and stakeholder feedback. Who are these charlatans that still make applications that function so horribly?
> Who are these charlatans that still make applications that function so horribly?
Ever used any Microsoft product recently ? Or the new xsnow which has a config screen when it starts ? Or Google with warning messages occupying half the screen ?
The world of medical software is, from everything I've seen and heard (from clinicians and prospective new entrants) a deep dark pit of dispair. The barriers to entry are so high that almost nobody can improve on the mess that has bled everywhere, and those supplying the mess crank the money machine at will.
My mom once managed to get into the hospital in a weird enough way that she got a bed assigned by the management software, but no food. "Software issue, can't do anything about it". I ended up bringing groceries to her room each second day.
Having worked almost exclusively in customer-facing roles for software companies for the last six years, it doesn't surprise me at all that a developer would be surprised by this story.
As far as I can tell, the number one rule of being a UX or UI specialist is that one must never, under any circumstances, actually talk with a U, nor consult the team whose job it is to assist U's with the X the designers and developers swear up and down is so intuitive it should never require explanation.
Most applications are still horrible and unintuitive to the people expected to use them, especially when they're built for niche users. This is the normal experience of using software as a non-developer.
Almost every company has customer support people who are beating their heads against their desks trying desperately to surface this feedback in a way that anyone in the company will care about, but support agents "aren't technical," so the developers don't think they could possibly have anything useful to say about their work.
It's a vicious circle. It doesn't have to be this way. But I'm all put of ideas about how to change it.
I would absolutely very much appreciate it as a developer, because nowadays,the motivational structures put in place rarely do anything for me but this would be a great: problem -> effort -> feedback -> closure -> motivation; loop element
Isn't this sort of the theory behind scrum - having rapid feedback loops with the product owner that is (supposedly) the one that has the deep necessary insight into the problem?
I've tried pushing for that idea to my manager at least quarterly at each of the last three companies I've worked for. Manager always agrees it would be a great idea. Engineers are never willing to do it.
In a previous job I did support in a very niche business with very niche software. The job sucked in most ways, but the positive thing was that if we discovered a bug or noticed users didn't understand the workflow or whatever we could send an e-mail directly to the sole developer of the software. As long as we explained the problem it would be fixed or changed within reasonable time.
My experience in startups has been that improvements or bug fixes are often ignored in favor of projects that have some long-shot possibility of increasing revenue, even if the existing customers threaten to and do leave over the bugs and hate the new features.
"We have replaced the old UI with a new UI. You're going to love the new UI, we promise! But, just in case, you can still have the old UI."
"We notice you're all still using the old UI and talking about how bad the new UI is when it's actually great! You don't need those features that aren't accessible from the new UI anyway. We're going to default everyone to the new UI now and you'll have to manually change the setting back if you want to."
"Ok you're all still using the old UI, even though the new UI is obviously better, so we're going to turn off the old UI at the end of the month"
"Oooooops! A bunch of people said they'd stop paying us if we turned off the old UI so we will now keep the old UI on until the end of the year"
"The Old UI is gone now. Where did all our customers go?"
This is the best I've heard it put. People dismiss complaints about UI changes wity the argument that the UI isn't better, people are just used to the old, worse way of doing things. And when that's true, which it isn't usually but sometimes it is, what you said is of paramount importance.
Give your support agents access to a functioning dev version. They'll happily tell you dozens of things they're going to have to explain to the customers, and find dozens more ways to break things.
Speaking from my personal position, I spend most of my time writing software and firmware for a product that we designed to satisfy our internal needs and which we have now developed a product. This is in a deeply domain specific area. I make decisions daily that have quite far reaching UX/UI consequences and even with about as deep a knowledge of the user domain as its possible to have (or perhaps because of that), I agonise over those decisions. I pity anyone trying to work on this kind of software without that direct first hand domain specific knowledge. You either implement the spec as-is, filling in the gaps by guessing or you get super stressed by the lack of insight - neither is a good place to be.
Probably the solution is to have the developers get as deep an insight as possible into the problem area they are trying to solve, and work very closely with users at every stage.
These type of software is regulated, and hospitals and clinics can't easily move to a competitor if they are not happy with their current system.
Journal systems "is a thing" with lots of hairy issues such as integrations between different hospitals and primary care givers, privacy issues etc.
These are not really solved yet, (even on a regional basis) and on top of this comes the probably most important thing, UX for the actual users such as doctors and nurses.
>>Who are these charlatans that still make applications that function so horribly?
The people selling this software and buying this software are ultimately not the people that use it. In developers minds and according to their spec sheets, the sofware might actually be amazing and flawless.
Healthcare is it's own thing, what happens outside it software wise isn't always applicable to healthcare.
The system in question is electronic health records (EHR). These are vast systems, really the comparison is "SAP for medical records" as they typically handle scheduling, billing, coding, store reports, notes, results (blood tests, as the tip of the ice berg). The tie ins to other systems are complex. And all of it is critical, as in patient injury or death if sole things go wrong. And much of it can fall under various federal laws, HIPAA is just the start.
These are long lived systems, upgraded over time. Replacing one can be a multi year effort for even a small organization. So replacing one isn't done because a new shiny one exists. New entries face a long battle into the industry, and the needs of a family physician are very different from a hospital or large group of hospitals.
If you want an idea of the scale and scope, the NYC Health and Hospitals project for their Epic EHR ran $1 billion over budget. Might have been more that that.
Its telling how corrupt the medical field is when the government is more advanced technologically than the medical industry.
No its not just Big Pharma/Insurance, its every member of the medical cartel. From Physicians to Hospitals, to everyone in pharma, to BCBS.
The whole system is designed to stay exactly the same, with 5% Medicare raises every year(despite CPI being 2%/yr).
We own a practice and the billing practices make me sick. We blame insurance companies, but its really us, we could bill less, instead we bill the moon and let them 'adjust'. The licensure system is so bad, terrible students get through because every school wants a 99.9% graduation rate. Do not let anyone pretend that doctors in the US are better than elsewhere, we have terrible terrible doctors who did unethical things with full blown licenses. Everything in pharma is amazing to watch, there are so many unnecessary layers. Everyone makes crazy money in medical, anyone who complains about debt is just pretending they are wealthy to be more in-touch with the common person.
ASCII or even UTF-8/16/whatever is not even close to have as much metadata as a written letter. Every people writing have its different "font-set", while computer text is uniformed. Sometimes you see somebody's prescription in the medical card and understand the mood of the doctor while writing this. Mathematics have developed TeX/LaTeX but this notation system is not for doctors by any stretch of imagination.
And also there is no a single software thing except of maybe Common Lisp which scripts can overcome tens of years with keeping backward compatibility as a primary goal, I mean try to run any scripts from '10s '00s '90s in any other language except of CL. Software industry produces too shortliving things being promoted with bold and click-bait statements and when it breaks, typically because of becoming a legacy, they say you that you just need more software because your one is too old!
I’m torn on this article. I understand where the doctor is coming from. However, I also disagree entirely with the “should’ve been super skeuomorphic” conclusion. From my experience, that just does not work. It could’ve been a temporary thing to facilitate the transition at best.
In fact, I do not see a single argument that supports the “bad software” claim. Instead, I see something else: part of the information was not in the files that were digitized, but instead in the doctors head. This information is no longer applicable.
When you decide to go digital, the workflow changes, period. There’s no easy solution, it may take quite some time to let go of the old ways and embrace the new system.
No? The doctor's frustration seems pretty simple - just let them go left/right for newer/older notes on the patient's health. Seems simple enough to me.
I would be tremendously surprised if this were not possible. I have seen many programs at various doctors’ offices and all of them could do this.
I suspect that instead the doctor was not properly taught how to operate the software. Of course this could also mean the UX is bad, yes. I’m not convinced yet however.
The fact the doctor struggles is literally the definition of a bad UX. I don't understand how you can suggest anything else. It might be the doctor can learn a new workflow which is as good as or better than previously, but you can't just impose that on someone.
I can easily imagine how it is both possible and bad solution. You only see one piece of information at a time, out of context. Here it's painfully obvious to me how nobody bothered with formatting the whole patient record as a document that can be read at once without mad clicking. No skeuomorphy is necessary at all, just a scrollable document-like output with all the information visible and sanely formatted.
It might even have been suggested and rejected because that UI is against someone's "no scrollbars" or such dogma...
When the purpose of the software is to support the existing practice, if the users don't see the benefit then the software has failed. If this is the end result of going digital, the correct solution is to not go digital.
Skeuomorphism may or may not be the right answer -- I suspect not, but anything's possible. What the doctor appears to miss, though, is the time-based context of a document. It might be significantly easier to find a single record (especially if you don't know when something was recorded) but whoever specified the software missed the utility of a time-based context.
Or possibly failed to train the doctor on how to do with the software what they were used to doing with a physical file, but that would still count as a failure of the digitisation effort.
Most doctors practice in clinics where software is mandated by the administration, which in turn has pressures from insurance companies that the software was likely chosen to satisfy.
Put more simply: Doctors these days likely cannot choose to avoid going digital.
There's a key point missing from most of the discussion: "In the USA".
Also, whether or not it's the choice of the doctors is only tangentially relevant to whether or not it's a failure of the system. Even if money is the only consideration, I'd question whether the system as described is the most effective. Ultimately, a US-based medical administration bills on being able to show that they've done things that they can justify having done. Hobbling the doctors' capacity to actually carry out work impedes that process, regardless of any questions around medical effectiveness.
And of course, "going digital" doesn't strictly imply moving to a broken system either.
Take your workflow, whatever it is. Probably it works for you. Now, artificially limit the things you used to do. For example, if you have 2 monitors, drop to one smaller screen. If you used emacs, uninstall it and restrict yourself to notepad++.
Will you reach the same level of comfort and productivity?
Programmers tend to have rather personalized setups that they've developed over the years but software companies tend to produce one-size-fits-all solutions. A new doctor might be used to working within the confines of Epic, but an older doctor is used to being able to have the pieces of paper in front of them, tactile, movable, etc. Going to a system with a screen for problem list, a separate screen for visit, a third screen for prescriptions, a fourth screen for labs, means that doctor is no longer allowed to organize their thoughts the same way.
> IT professionals try to radically alter the workflow of medical professionals, without their input
That’s because, as I understand it, EHRs are made primarily for insurance companies, not medical staff. This is a huge problem. IT staff should not be blamed.
My company does EMR and practice management. Yeah, insurance companies definitely are insinuating themselves further and further into the encounter and it’s very gross on top of distracting. We’re also spending a lot of time on Meaningful Use/CURES (regulatory) and interoperability and not as much time innovating and addressing core issues (usability, performance, stability). But sometimes we just plain miss by modeling solutions that sound fine from the engineering side but are impractical in the practice. On the other hand, it’s incredibly frustrating to try to build solutions when each doctor can have a radically different idea of an essential workflow (and often are inconsistent or obstinate about it). I think there’s a plenty of blame to spread around, but I think vendors (i.e. me) have a hell of a lot of room for improvement.
> This sort of "design blindness" happens whenever system designers prioritize the needs of the IT system, rather than its users. My specialist is therefore forced to deal with a client interface barely pasted over some sort of database. The data is shaped to fit the design of that database, rather than the other way around.
I wrote my graduate thesis on digital medical record systems in family practice over a decade ago, user experience was a huge issue then as well. Having training sessions alone isn't enough.
The problem isn't going to be solved because doctors are not the primary customer for these systems, the procurement department is. They will care more about HIPAA compliance than whether the end-user can effectively replace their workflow with this new tool.
> The problem isn't going to be solved because doctors are not the primary customer for these systems
Agreed!
> the procurement department is.
But I disagree here.
From what I’ve seen in ambulatory EHRs, they are finely tuned for billing workflows. The key outcome is that a patient encounter is tied cleanly to an ICD. Actually tracking patient information in a useful way seems to be an afterthought.
This seems like this might lead to some interesting second-order benefits of single-payer healthcare schemes; is the state of EHRs as bad in the UK? If so, is it because they're buying American EHRs?
Afaik, this is further exacerbated by the extraordinary pace at which private practices are getting swallowed up by major hospital networks, like HCA (nationally) and large regionals like Baylor Scott and White in DFW. [0].
The craziest thing about EMR systems like this is that you would _think_ that their adoption would help bolster universal patient records that transfer from doctor to doctor (useful now in the world of services like ZocDoc where booking care is ubiquitous). But that's not the case at all!
I’ve been working in healthcare, specifically EMR and practice management for over 20 years. I think the sector is a mess, honestly. It’s too big of a topic for me to get into here.
However, there is large amount of variance in how users access and work with medical records, from person to person, role to role, specialty to specialty, hospital type to hospital type, org to org and it gets even worse when users are transitioning from paper. Skeuomorphism might be attractive to non-technical users in transition, but in my experience (this approach isn’t novel) it falls apart very quickly because a) as I previously suggested, there isn’t one model to replicate and skeuomorphic approaches tend to be rigid, and b) users usually very quickly grow out of analog processes as they adapt to software. It’s important to allow practices to customize views for roles and allow users to override so they can put the most important information at their fingertips, and make it quick and easy to jump into the rest of the full details of their record. It’s an information dense problem area, so your fluffy, padded, pretty commerce-focused user patterns are often an anti-pattern. Automation, driven by rules specified by practice and doctors, to help error check their records or point out patient issues (“patient has disease x but we don’t have record that they’ve done y and z preventative measures”, etc.) can help reduce cognitive load and simple mistakes. Dynamic, annotated notation systems driven by templates selected based on the appointment reason and patient history where they do more simply tapping/clicking checkboxes and less typing let doctors focus on interacting with the patient during encounters. Automatically pull in data collected by sensors (weight, blood pressure, whatever) speeds things up, especially for overworked supporting staff. Speed, stability, and consistency over everything.
Skeuomorphism really doesn’t help any of that. It was mostly a sales tool like 10-15 years ago.
Not sure about the skeuomorphism angle. I'm no UX specialist or anything but I would have thought the best practice would be to use 'standard' (well understood, probably familiar for potential users already) UI elements which are an appropriate analogy for the use case.
If you're flicking through paper, it might be easier to e.g. scroll through records for a specific patient and to have some kind of contextual search. But I think the obvious issue is really that they haven't validated and iterated on the design with actual users or even had somebody on the team responsible for caring about this stuff.
You see this everywhere nowadays, in everything. Bad UX. All over the place. Even things that once had fantastic UX are breaking it.
I want to know what they're teaching these designers in design school because theyre fucking everything up. Or is it management making design decisions for them and they just go along with it for the paycheck? Are people in these companies deliberately sabotaging products? I don't know what it is but I'm sick of it.
I'll give you an example. When Android came out, one of the first, most important sets of requirements was that it do everything a normal cell phone could do the way a normal cell phone would do it. If you turn the volume all the way down, it must stay all the way down, period. And it worked like that, perfectly, for years. But recently, every so often, you want to play a video silently, and a chirp happens at the very beginning. Someone at some point changed the code where the volume control doesnt control the volume, it saves a variable that's read by the audio decoding software asynchronously and sometimes you get a race condition where audio starts before it is read. Why was this changed? Why is ensuring this functionality no longer a top priority?
That's just a tiny little example. With android, side scrolling menus, pages in the recent apps that take up the whole screen, little race conditions here and there. And that's just android, probably the least offensive software UX wise that there is. Hamburger menus, border less flat elements, nests upon nests, you see UX crumbling everywhere you look. I don't know what to make of it.
Want to buy some audiobooks for a long drive? You'll need to sign up for their subscription service!
Want to buy individual books? Well, for that, you'll OBVIOUSLY need to open Amazon.com _in desktop mode_ and click through a submenu to purchase them individually!
> This sort of "design blindness" happens whenever system designers prioritize the needs of the IT system, rather than its users. My specialist is therefore forced to deal with a client interface barely pasted over some sort of database. The data is shaped to fit the design of that database, rather than the other way around.
I just finished listening to The Pragmatic Programmer (EXCELLENT as an audiobook), and the authors talk about this pretty explicitly:
> As soon as you have an executable user interface or prototype, you need to answer an all-important question: the users told you what they wanted, but is it what they need?
> Does it meet the functional requirements of the system? This, too, needs to be tested. A bug-free system that answers the wrong ques tion isn't very useful.
So it looks like some programmers need to read this book for homework!
59 comments
[ 4.4 ms ] story [ 117 ms ] threadEver used any Microsoft product recently ? Or the new xsnow which has a config screen when it starts ? Or Google with warning messages occupying half the screen ?
This is the trend since about 15 years.
Literally more windows 7 would be an upgrade over windows 11.
Whatever stuff they have going on in the background is not worth the anti-user crap.
As far as I can tell, the number one rule of being a UX or UI specialist is that one must never, under any circumstances, actually talk with a U, nor consult the team whose job it is to assist U's with the X the designers and developers swear up and down is so intuitive it should never require explanation.
Most applications are still horrible and unintuitive to the people expected to use them, especially when they're built for niche users. This is the normal experience of using software as a non-developer.
Almost every company has customer support people who are beating their heads against their desks trying desperately to surface this feedback in a way that anyone in the company will care about, but support agents "aren't technical," so the developers don't think they could possibly have anything useful to say about their work.
It's a vicious circle. It doesn't have to be this way. But I'm all put of ideas about how to change it.
Instead of stand-ups let developers spend 15 minutes each day in a call with a customer who has a problem or feature request.
Extreme Programming got that part covered much better.
My experience in startups has been that improvements or bug fixes are often ignored in favor of projects that have some long-shot possibility of increasing revenue, even if the existing customers threaten to and do leave over the bugs and hate the new features.
At least occasionally look at how actual users are using software?
In case of paying for software system I would require it as part of a contract.
If I would be decision maker on software project I would also demand it.
"We notice you're all still using the old UI and talking about how bad the new UI is when it's actually great! You don't need those features that aren't accessible from the new UI anyway. We're going to default everyone to the new UI now and you'll have to manually change the setting back if you want to."
"Ok you're all still using the old UI, even though the new UI is obviously better, so we're going to turn off the old UI at the end of the month"
"Oooooops! A bunch of people said they'd stop paying us if we turned off the old UI so we will now keep the old UI on until the end of the year"
"The Old UI is gone now. Where did all our customers go?"
In my personal experience, this only happens after the development. We have found no way to obtain useful feedback during the design phase.
Exactly as I said, it's already too late. For it to be most effective, such advice must arrive before I start coding.
Probably the solution is to have the developers get as deep an insight as possible into the problem area they are trying to solve, and work very closely with users at every stage.
Some even expect magical abilities from software to turn bad user data in correct data without any work by U. Address data comes to my mind.
Or I want to see all data at once but why does it take so long and doesn't fit on one page and is incomprehensible?
Journal systems "is a thing" with lots of hairy issues such as integrations between different hospitals and primary care givers, privacy issues etc.
These are not really solved yet, (even on a regional basis) and on top of this comes the probably most important thing, UX for the actual users such as doctors and nurses.
The people selling this software and buying this software are ultimately not the people that use it. In developers minds and according to their spec sheets, the sofware might actually be amazing and flawless.
The system in question is electronic health records (EHR). These are vast systems, really the comparison is "SAP for medical records" as they typically handle scheduling, billing, coding, store reports, notes, results (blood tests, as the tip of the ice berg). The tie ins to other systems are complex. And all of it is critical, as in patient injury or death if sole things go wrong. And much of it can fall under various federal laws, HIPAA is just the start.
These are long lived systems, upgraded over time. Replacing one can be a multi year effort for even a small organization. So replacing one isn't done because a new shiny one exists. New entries face a long battle into the industry, and the needs of a family physician are very different from a hospital or large group of hospitals.
If you want an idea of the scale and scope, the NYC Health and Hospitals project for their Epic EHR ran $1 billion over budget. Might have been more that that.
No its not just Big Pharma/Insurance, its every member of the medical cartel. From Physicians to Hospitals, to everyone in pharma, to BCBS.
The whole system is designed to stay exactly the same, with 5% Medicare raises every year(despite CPI being 2%/yr).
We own a practice and the billing practices make me sick. We blame insurance companies, but its really us, we could bill less, instead we bill the moon and let them 'adjust'. The licensure system is so bad, terrible students get through because every school wants a 99.9% graduation rate. Do not let anyone pretend that doctors in the US are better than elsewhere, we have terrible terrible doctors who did unethical things with full blown licenses. Everything in pharma is amazing to watch, there are so many unnecessary layers. Everyone makes crazy money in medical, anyone who complains about debt is just pretending they are wealthy to be more in-touch with the common person.
And also there is no a single software thing except of maybe Common Lisp which scripts can overcome tens of years with keeping backward compatibility as a primary goal, I mean try to run any scripts from '10s '00s '90s in any other language except of CL. Software industry produces too shortliving things being promoted with bold and click-bait statements and when it breaks, typically because of becoming a legacy, they say you that you just need more software because your one is too old!
In fact, I do not see a single argument that supports the “bad software” claim. Instead, I see something else: part of the information was not in the files that were digitized, but instead in the doctors head. This information is no longer applicable.
When you decide to go digital, the workflow changes, period. There’s no easy solution, it may take quite some time to let go of the old ways and embrace the new system.
What is bad in this article is not the software. It is a software.
No? The doctor's frustration seems pretty simple - just let them go left/right for newer/older notes on the patient's health. Seems simple enough to me.
I suspect that instead the doctor was not properly taught how to operate the software. Of course this could also mean the UX is bad, yes. I’m not convinced yet however.
It might even have been suggested and rejected because that UI is against someone's "no scrollbars" or such dogma...
Skeuomorphism may or may not be the right answer -- I suspect not, but anything's possible. What the doctor appears to miss, though, is the time-based context of a document. It might be significantly easier to find a single record (especially if you don't know when something was recorded) but whoever specified the software missed the utility of a time-based context.
Or possibly failed to train the doctor on how to do with the software what they were used to doing with a physical file, but that would still count as a failure of the digitisation effort.
Put more simply: Doctors these days likely cannot choose to avoid going digital.
Also, whether or not it's the choice of the doctors is only tangentially relevant to whether or not it's a failure of the system. Even if money is the only consideration, I'd question whether the system as described is the most effective. Ultimately, a US-based medical administration bills on being able to show that they've done things that they can justify having done. Hobbling the doctors' capacity to actually carry out work impedes that process, regardless of any questions around medical effectiveness.
And of course, "going digital" doesn't strictly imply moving to a broken system either.
Will you reach the same level of comfort and productivity?
Programmers tend to have rather personalized setups that they've developed over the years but software companies tend to produce one-size-fits-all solutions. A new doctor might be used to working within the confines of Epic, but an older doctor is used to being able to have the pieces of paper in front of them, tactile, movable, etc. Going to a system with a screen for problem list, a separate screen for visit, a third screen for prescriptions, a fourth screen for labs, means that doctor is no longer allowed to organize their thoughts the same way.
Given time to adjust? Sure. This type of thing is a time limited problem.
You cannot mechanically return to the same level of productivity with that tool degradation, so I don't think so.
That’s because, as I understand it, EHRs are made primarily for insurance companies, not medical staff. This is a huge problem. IT staff should not be blamed.
I wrote my graduate thesis on digital medical record systems in family practice over a decade ago, user experience was a huge issue then as well. Having training sessions alone isn't enough.
The problem isn't going to be solved because doctors are not the primary customer for these systems, the procurement department is. They will care more about HIPAA compliance than whether the end-user can effectively replace their workflow with this new tool.
Agreed!
> the procurement department is.
But I disagree here.
From what I’ve seen in ambulatory EHRs, they are finely tuned for billing workflows. The key outcome is that a patient encounter is tied cleanly to an ICD. Actually tracking patient information in a useful way seems to be an afterthought.
[0] https://www.statnews.com/2020/02/27/physician-practice-conso...
However, there is large amount of variance in how users access and work with medical records, from person to person, role to role, specialty to specialty, hospital type to hospital type, org to org and it gets even worse when users are transitioning from paper. Skeuomorphism might be attractive to non-technical users in transition, but in my experience (this approach isn’t novel) it falls apart very quickly because a) as I previously suggested, there isn’t one model to replicate and skeuomorphic approaches tend to be rigid, and b) users usually very quickly grow out of analog processes as they adapt to software. It’s important to allow practices to customize views for roles and allow users to override so they can put the most important information at their fingertips, and make it quick and easy to jump into the rest of the full details of their record. It’s an information dense problem area, so your fluffy, padded, pretty commerce-focused user patterns are often an anti-pattern. Automation, driven by rules specified by practice and doctors, to help error check their records or point out patient issues (“patient has disease x but we don’t have record that they’ve done y and z preventative measures”, etc.) can help reduce cognitive load and simple mistakes. Dynamic, annotated notation systems driven by templates selected based on the appointment reason and patient history where they do more simply tapping/clicking checkboxes and less typing let doctors focus on interacting with the patient during encounters. Automatically pull in data collected by sensors (weight, blood pressure, whatever) speeds things up, especially for overworked supporting staff. Speed, stability, and consistency over everything.
Skeuomorphism really doesn’t help any of that. It was mostly a sales tool like 10-15 years ago.
[0] https://www.amazon.com/Recoding-America-Government-Failing-D... — it was recommended on another HN thread.
If you're flicking through paper, it might be easier to e.g. scroll through records for a specific patient and to have some kind of contextual search. But I think the obvious issue is really that they haven't validated and iterated on the design with actual users or even had somebody on the team responsible for caring about this stuff.
I want to know what they're teaching these designers in design school because theyre fucking everything up. Or is it management making design decisions for them and they just go along with it for the paycheck? Are people in these companies deliberately sabotaging products? I don't know what it is but I'm sick of it.
I'll give you an example. When Android came out, one of the first, most important sets of requirements was that it do everything a normal cell phone could do the way a normal cell phone would do it. If you turn the volume all the way down, it must stay all the way down, period. And it worked like that, perfectly, for years. But recently, every so often, you want to play a video silently, and a chirp happens at the very beginning. Someone at some point changed the code where the volume control doesnt control the volume, it saves a variable that's read by the audio decoding software asynchronously and sometimes you get a race condition where audio starts before it is read. Why was this changed? Why is ensuring this functionality no longer a top priority?
That's just a tiny little example. With android, side scrolling menus, pages in the recent apps that take up the whole screen, little race conditions here and there. And that's just android, probably the least offensive software UX wise that there is. Hamburger menus, border less flat elements, nests upon nests, you see UX crumbling everywhere you look. I don't know what to make of it.
Want to buy some audiobooks for a long drive? You'll need to sign up for their subscription service!
Want to buy individual books? Well, for that, you'll OBVIOUSLY need to open Amazon.com _in desktop mode_ and click through a submenu to purchase them individually!
I just finished listening to The Pragmatic Programmer (EXCELLENT as an audiobook), and the authors talk about this pretty explicitly:
> As soon as you have an executable user interface or prototype, you need to answer an all-important question: the users told you what they wanted, but is it what they need?
> Does it meet the functional requirements of the system? This, too, needs to be tested. A bug-free system that answers the wrong ques tion isn't very useful.
So it looks like some programmers need to read this book for homework!