5 ms·

Just a little personal anecdote but - A while back I had a week long stay in the hospital, after some small talk with one of my nurses she learned I write softw

Just a little personal anecdote but - A while back I had a week long stay in the hospital, after some small talk with one of my nurses she learned I write software. She told me a bunch of things they hated about Epic and gave me a quick tour of the interface they have to use. The main complaint seemed to be that things they need to do hundreds of times a day require way too many input actions. And it did indeed look incredibly cluttered. I love getting little tours of software I'll likely never use even though I'm not in a position to fix any of the problems. It's just interesting.

bena 6y ago
You know why? Because every doctor, nurse, tech, etc has a goddamn opinion on what's important. They're of the opinion that everything needs to be "as few clicks" as possible. As if "number of clicks" was the only worthwhile message. Nobody would read a book where the keyboard was pressed as few times as possible. Sometimes, complex actions require complex input. We should be shooting for discoverability, not "number of clicks".
- im3w1l 6y ago
  Vim isn't known for its discoverability but remains popular.
  - lsiebert 6y ago
    This sounds like it's way less configurable than vim
- somehnguy 6y ago
  Sure. Discoverability is great for new users to software. After the initial learning period I care far more about ease of performing repetitive actions. Discoverability is useless to me when I've already established a workflow and just want to perform known actions. I was specifically talking about things they do hundreds of times a day (at least) like dispensing medication, requesting medication, inputting vitals, taking notes, etc. Those things shouldn't require 10-15 clicks and 4 different modals/menus each time. They're extremely common use cases that a nurse will likely be performing a number of times in every single room they enter. And why shouldn't they have an opinion on what is important? They're the ones using the software all day!
  - Scoundreller 6y ago
    > After the initial learning period I care far more about ease of performing repetitive actions. Discoverability is useless to me when I've already established a workflow and just want to perform known actions. I once got in trouble for using autohotkey for something like this. Like, wow were they upset with me.
    - wrkronmiller 6y ago
      Why were "they" upset? What as the context?
  - bena 6y ago
    In a clinic or hospital setting, there's always going to be someone on an initial learning period. So while discoverability may be "useless" to you, it's not useless to everyone. The issue is also what's important for one use is not important for another. The person dispensing medication may not be the same person taking vitals, etc. And it might be the common use case for that nurse, but another nurse may have a different workflow. What works for cardiovascular doesn't work for ophthalmology. And all these people think they're equally important. They all want the same priority. Not to mention, most people are bad at UX design. So while they should have opinions, they should not be the only consideration.
    - Aeolun 6y ago
      Isn’t it our job as engineers/UX designers/architects to make it happen? If my software takes 10-15 clicks to do something any of the users does 100s of times a day, I’d consider that a failure on my part.
      - bena 6y ago
        First, counting clicks is a fool's game. 1, 2, 15, 100, the number of clicks doesn't really matter. It's like measuring code quality by line count. It's Spinal Tap. "But it's one less click, innit?" If it takes you 10 seconds to find the one place to click or requires such heavy front-loading that it slows down the system on every click, you've already failed. Doing more of the thing that caused you to fail is a hole with no bottom. Second, the engineers and UX designers aren't the people really driving the design process. That's a problem. The people driving the design process don't know what they're doing. Because everyone things UX design is easy. It's not. It's hard. People think they know what they want, but the don't really. What they know is what they want to do. But they get it wrapped up in their mind that what and how are interchangeable. So "I want to prescribe medicine easy." becomes "Prescriptions need to be one click". Maybe they don't really. Maybe to make them easier to do, they need to be in a context menu or something else. I don't know either. I'm not a UX designer by trade. Because I know it's hard.
- rscho 6y ago
  You would have a different opinion if you were the one having to wait 3 seconds for things to load between each mouse click...
  - bena 6y ago
    That's a different problem. That's not solved through just putting all the functions of the application one click away.
    - rscho 6y ago
      Batch loads are usually faster. Regardless, no it's not a different problem. It's THE problem. Clinicians need to go fast, and EMRs slow them down. If everything is a single click away from the landing page, they'll go much faster and in their eyes it's the only thing that matters even if it goes against any kind of common sense.
  - Aeolun 6y ago
    I see you use JIRA too!
- throwaway4220 6y ago
  At the end of the day, it's a simple record of the patient, not an IDE. Nurses need to see stuff, MDs need to see stuff. FWIW, my goddamn opinion: Epic is probably the best EMR I've used, but I can still see some random dude's dog in Bolivia on FB faster than I can pull up a patient's critical lab values during a procedure. Not too worried about missing out on "Now your EMR comes with customizable colors! [dismiss]"
  - bena 6y ago
    This could also be a factor of how much hardware is thrown at the problem. I guarantee that Facebook has more computing power dedicated to showing you Bolivian dogs than any hospital has to showing you patient data.
josephpmay 6y ago
Epic just unveiled a new user interface for nurses trying to address this exact issue. The problem, and another commenter pointed out, becomes everybody has a different idea of what they need quickest access to, and many hospitals want to customize to fit their existing workflows, even when that’s not ideal for speed of use.
- Aeolun 6y ago
  > many hospitals want to customize to fit their existing workflows This is probably my single largest source of frustration with building/implementing any enterprise product.

bena 6y ago

You know why? Because every doctor, nurse, tech, etc has a goddamn opinion on what's important. They're of the opinion that everything needs to be "as few clicks" as possible. As if "number of clicks" was the only worthwhile message. Nobody would read a book where the keyboard was pressed as few times as possible. Sometimes, complex actions require complex input. We should be shooting for discoverability, not "number of clicks".

im3w1l 6y ago
Vim isn't known for its discoverability but remains popular.
- lsiebert 6y ago
  This sounds like it's way less configurable than vim
somehnguy 6y ago
Sure. Discoverability is great for new users to software. After the initial learning period I care far more about ease of performing repetitive actions. Discoverability is useless to me when I've already established a workflow and just want to perform known actions. I was specifically talking about things they do hundreds of times a day (at least) like dispensing medication, requesting medication, inputting vitals, taking notes, etc. Those things shouldn't require 10-15 clicks and 4 different modals/menus each time. They're extremely common use cases that a nurse will likely be performing a number of times in every single room they enter. And why shouldn't they have an opinion on what is important? They're the ones using the software all day!
- Scoundreller 6y ago
  > After the initial learning period I care far more about ease of performing repetitive actions. Discoverability is useless to me when I've already established a workflow and just want to perform known actions. I once got in trouble for using autohotkey for something like this. Like, wow were they upset with me.
  - wrkronmiller 6y ago
    Why were "they" upset? What as the context?
- bena 6y ago
  In a clinic or hospital setting, there's always going to be someone on an initial learning period. So while discoverability may be "useless" to you, it's not useless to everyone. The issue is also what's important for one use is not important for another. The person dispensing medication may not be the same person taking vitals, etc. And it might be the common use case for that nurse, but another nurse may have a different workflow. What works for cardiovascular doesn't work for ophthalmology. And all these people think they're equally important. They all want the same priority. Not to mention, most people are bad at UX design. So while they should have opinions, they should not be the only consideration.
  - Aeolun 6y ago
    Isn’t it our job as engineers/UX designers/architects to make it happen? If my software takes 10-15 clicks to do something any of the users does 100s of times a day, I’d consider that a failure on my part.
    - bena 6y ago
      First, counting clicks is a fool's game. 1, 2, 15, 100, the number of clicks doesn't really matter. It's like measuring code quality by line count. It's Spinal Tap. "But it's one less click, innit?" If it takes you 10 seconds to find the one place to click or requires such heavy front-loading that it slows down the system on every click, you've already failed. Doing more of the thing that caused you to fail is a hole with no bottom. Second, the engineers and UX designers aren't the people really driving the design process. That's a problem. The people driving the design process don't know what they're doing. Because everyone things UX design is easy. It's not. It's hard. People think they know what they want, but the don't really. What they know is what they want to do. But they get it wrapped up in their mind that what and how are interchangeable. So "I want to prescribe medicine easy." becomes "Prescriptions need to be one click". Maybe they don't really. Maybe to make them easier to do, they need to be in a context menu or something else. I don't know either. I'm not a UX designer by trade. Because I know it's hard.
rscho 6y ago
You would have a different opinion if you were the one having to wait 3 seconds for things to load between each mouse click...
- bena 6y ago
  That's a different problem. That's not solved through just putting all the functions of the application one click away.
  - rscho 6y ago
    Batch loads are usually faster. Regardless, no it's not a different problem. It's THE problem. Clinicians need to go fast, and EMRs slow them down. If everything is a single click away from the landing page, they'll go much faster and in their eyes it's the only thing that matters even if it goes against any kind of common sense.
- Aeolun 6y ago
  I see you use JIRA too!
throwaway4220 6y ago
At the end of the day, it's a simple record of the patient, not an IDE. Nurses need to see stuff, MDs need to see stuff. FWIW, my goddamn opinion: Epic is probably the best EMR I've used, but I can still see some random dude's dog in Bolivia on FB faster than I can pull up a patient's critical lab values during a procedure. Not too worried about missing out on "Now your EMR comes with customizable colors! [dismiss]"
- bena 6y ago
  This could also be a factor of how much hardware is thrown at the problem. I guarantee that Facebook has more computing power dedicated to showing you Bolivian dogs than any hospital has to showing you patient data.

josephpmay 6y ago

Epic just unveiled a new user interface for nurses trying to address this exact issue. The problem, and another commenter pointed out, becomes everybody has a different idea of what they need quickest access to, and many hospitals want to customize to fit their existing workflows, even when that’s not ideal for speed of use.

Aeolun 6y ago
> many hospitals want to customize to fit their existing workflows This is probably my single largest source of frustration with building/implementing any enterprise product.