Interface ergonomics: automation isn't just about time saved | Hacker News Reader

Interface ergonomics: automation isn't just about time saved

macoy.me

60 pointsmakuto21 comments

> Automation not only saves you time, it changes what you do.

This bears repeating. When you automate a task, you often push it over a "breakpoint" where it suddenly makes certain things profitable in terms of effort. For example, say you fill up a water bottle and place it within arm's reach, instead of running to the tap every time you're thirsty. You save maybe 10 seconds per sip, but the real win is that you can now consider behaviors like "drink water every 5 minutes" that previously you would have considered too much effort.

In the software development realm, the biggest spot I see automation paying off is when it fosters consistency.

To take an example from operations: To me (admittedly speaking from the developer side of things), the overwhelming benefit of containerization has nothing to do with elasticity or scaling or really any of the marketing buzzwords. The real benefit is that Docker and friends encourage presenting a much more consistent management surface to the operations team. In the short run, this is just the price of automation. In the long run, this greatly reduces the mental burden of understanding how all the individual pieces are configured and deployed.

Most of that was never anything but incidental complexity. I doubt that ops's job has actually become any easier over the past 20 years. But, even so, if they're spending less time just shaving yaks, that suggests that a greater proportion of what they're doing is genuinely valuable.

As someone in operations, totally this. Consistency is the biggest thing.

I've worked with plenty of wizards that can figure anything/everything out, but these deviations have a hidden cost.

The farm of resources no longer behaves like cattle, it's all pets - with their own identities, personalities, etc.

Containers abstract most of this away, a simple runtime and any host can be just like another with a tiny amount of automation.

We get things like scale from this, but if it 'works on your machine' but not ours, we're no further.

Something that seemed somewhat implicit in this article, but never fully stated, is that it also increases the quality of the work, or in other words, decreases the probability of bugs and errors. Every time you do a manual process, you introduce the possibility for a lot of human error. That's where a lot of the "willingness" vs. "unwillingness" comes in (aside from just the "time" aspect, or partially as a cause of the "time" aspect). The more boring the task, the more likely you are to sleepwalk through it and not be thorough in checking things. This leads to bugs, and can either (ideally) increase the time of the task since they immediately surface and then you are "shaken awake" and have to dig around for what you mistyped, or in the worst case, go in undetected. Like everything computers do, and kind of the whole point of programming, a script can go into the task with the same "willingness" every time. That weird edge case you found when you did the task the first time when it was still interesting can get coded in and checked for. Future weird bugs can then be trivially added to the automation script vs. just noted as a "WARNING" in a README that will never get read. If there's no existing tool, then the activation energy to create that tool just to account for that weird thing that happened that one time is always beyond the "fuck it, let's just make a note" boundary. As such, it's best to just bite the bullet in the beginning. The unfortunate thing is that this is really a indictment of our workflows in general. Much of what we do is so close to programming as it is, it sucks that "putting it into a literal program" can be such a chore (and it very much is).

Another important is that automation can solve the problem of passing the knowledge (on how to do something).

This happens when the person that uses the automation no longer needs to learn how to do the task.

Teaching people is actually extremely expensive even if you forget about reliability of entire process.

People have limited ability to learn stuff. So being able to automate certain tasks not only allows people to do more in less time or do it better, it can actually allow doing more things that the person would ever be able to learn, without need of learning.

Not only that, but they can use the automation (assuming it was written for others to read) to teach themselves if needed/desired.

Another thing is - automation is documentation. It might just be three 1-line bash commands that you have as muscle memory that you do once a week - so there's no time save.

But automation will save you a lot of time and stress if you had long vacations or worked on a different project for half a year. Suddenly the muscle memory isn't there and you have to learn the hard way AGAIN if it's not automated.

As you make something cheaper demand for it goes up. Easy to forget about it when you try to calculate the value of automation. I'd say in most cases automation pays off if you do it properly, not to do the intended task but to do all the unintended tasks, reusing the automation code for later, reducing errors from manual work and opens up doors for new product design paths in the future.

This assumes that you actually own the product, if you don't own the product and just have a job to do then why bother about saving time, so in this case you should still automate it because automation is more fun.

Right, so we have a number of advantages of automation that aren't captured in a simplistic time calculation like the "Is It Worth the Time?" XKCD:

- if you can do something more quickly you might also choose to do it more often

- automation can reduce human errors

- once something is fully automated it can be used as a building block in a larger piece of automation

I can think of one more:

- automation can make it easier to hand over work to someone else, or increase the number of people who are able to do it

But also one disadvantage:

- automating something can lose a human "sanity check" (for example, you could generate reports full of missing data and maybe nobody will notice for a while)

Any more?

> - automating something can lose a human "sanity check" (for example, you could generate reports full of missing data and maybe nobody will notice for a while)

Yeah, you shouldn't automate things that you don't know how to automate. Don't use ML for automation for example.

We had a build process that took half an hour, so people only ran it a couple times a day. I cut it to fifteen minutes, saving half an hour a day per person.

Then I cut it to 7 minutes, saving an additional 30+ minutes, because everyone was now running the build 4-5 times a day.

What I really saved was wasting each other’s time and goodwill by reducing the frequency and severity of people checking in broken code that blocked everyone else. Because they were expected to test more often, and they made smaller commits because it wasn’t so painful.

>This is an example of an unethical interface. One week of programmer time would have easily saved multiple weeks of designer time...

>When developing things which have a human interacting with it, you should consider how much you value your life time, and have empathy for your users' life time.

Well articulated. Outside of software and technology, people have to use software tools that they have little control over - tools assigned for their job. When authors take the time to understand how their tools are used, it can have a profound impact on the daily work for a huge number of people.

For example, I interact my electronic medical records system between 2-5+ hours each day. To write a document requires 15 mouse clicks, with a 1+ second load time after each click. It's painful. I would use the author's words to describe this as an unethical interface. If the devs who wrote this software had to use it for their daily work, I imagine that they would demand new tools or leave in frustration. But for us, as users without a choice, it contributes to dissatisfaction at work and ultimately to burn-out.

Hmmm, not sure I agree. They might just think this is how it is (in “their” industry). Like the elementary school teacher who thinks math is hard.

Often those devs have subpar development environments too and don't know to look for better or does not have the skills/time to up level themselves.

> Cakelisp was a revelation because it was my chance to escape from these limitations. I had to pay my time in order to make something I consider better, but it was absolutely worth it. I was now in charge of the interface. I shaped the language, the language didn't shape me.

We are tool makers, making tools that we use in tool making so that the act of making tools for our tools is more enjoyable.

As a UX practitioner with engineering experience, I'm happy to see an article like this, but also a bit disheartened that in 2021 it's still a revelation for many that frustration, satisfaction, and cognitive load are key considerations in prioritization in addition to raw efficiency.

How can you live? I took two classes in UX in college 20 years ago. I still can't walk into a kitchen without cursing the bad UX of the stove.

Sounds similar to the consequences of reading Don Norman's «The Design of Everyday Things»...

That book was part of my classes

Are you implying that all stoves in all kitchens are bad? At least that's what it looks like you are saying.

Almost without exception. There is no way of knowing without careful study which burner will turn on when you turn a knob. (generally you know the side, but not front/back) Every time I move I need to figure out a different stove, and so I'm often turning on the wrong burner because I have the wrong habit. Most people think "opps, I'm stupid again" when that happens, but I have enough UX background to know that the real problem is the UX is terrible.

How often do you use a different hob? As long as it is not awkward surely once you have used it a couple of times you have it in muscle memory. Over the last 30 years I have only had two hobs so it hasn't been a big burden to learn a the correspondence between the five burners and the knobs on a new one.

Reply on news.ycombinator.com