3 ms·
This is a really interesting counter-argument. The idea that the design should be dumbed down so, what, a lay-person who has never encountered the system can t
by disillusioned 2y ago
This is a really interesting counter-argument.
The idea that the design should be dumbed down so, what, a lay-person who has never encountered the system can take over and drive the ship accurately? is an appealing one: it makes the case that, all else being equal, simplicity should win out.
I would argue that there's an in-between: good design is not orthogonal to intuitive design. And I would also argue that the human factor component shouldn't be missed here, both in terms of sleep deprivation, but also in terms of being able to easily and quickly identify error states or misconfigurations at a glance, without too much cognitive overload.
Cognitive overload and complex interfaces are solved with training and repetition: we do this regularly in aviation, pilotage, and all sorts of complex interfaces. But I guess it's worth asking aloud, if you can reduce some of the cognitive overload, aren't you effectively defending in depth?
Sure, every complex system could be distilled to a memorized green screen incantation, and peak performance can be reached by fusing the human brain to a well-mapped, ultra-dense information-fest. But the reality of the situation is that, when training and tiredness failed these sailors, the interface further piled on _unnecessarily_. It could have been designed to be a bit more intuitive, and that might very well have saved the lives of 10 people and $223 million dollars of taxpayer money.
"This is a hard problem that you can't get around by just saying 'just design it better'" sure downplays that amount of impact intuitive, clear design can have on, say, preventing the swiss cheese holes from aligning in this particular case.
- karaterobot 2y ago> if you can reduce some of the cognitive overload, aren't you effectively defending in depth? Absolutely. But in practice, cognitive overload rears its head in many ways. When most people think of an intuitive system, they think of a simple system as measured in the density of information on screen ("just show me what I need to know, nothing else") and the paucity of options you have to select from (Hick's law and so forth). But if you have to perform complex activities with such a system, the seeming simplicity results in actual complexity, since you have to do things like (for example) diving into a dozen nested layers of menus and screens to reach an option that was hidden there in order to (try to) reduce cognitive burden. A different, equally valid measurement of simplicity (and cognitive burden) is how few transitions or state changes you have to suffer through to get to the state you want to be in. That is to say: how many steps you have to take to do what you want. And since there's a chance to make an error at each step, it's not even just a question of saving clicks, it can actually be more error prone. I say these measurements are equally valid, but not that either of them are sufficiently robust ways of thinking about good design. I'm also not trying to downplay the impact of clear, intuitive design. The point I'm trying to make is that there is no formula for making designs clear and intuitive; it's actually quite complicated. In fact, in most cases, you can't even do it, you can only find a tradeoff between imperfect solutions. Anecdotally, I have designed dense, complex systems for quantum computing experimentalists—people much smarter than me—and had them tell me "make it simpler!". I've also tried to make simple systems for biomedical researchers, and had them tell me, in so many words, to make the UI denser and more complex. There's no correct level of simplicity you can arrive at a priori, it's different for every case, and you have to reach the right balance through testing. If you don't do enough testing, your users become your testers. The consequences are not usually this grave.
- moring 2y agoIt seems to me that an unspoken assumption in this thread is that "design" is purely theoretical work, performed by a designer. If the behavior of a sleep-deprived sailor is an unknown variable, then the obvious solution is to get a sleep-deprived sailor involved in the design process. This is not particularly complex, and while _some_ money is involved, preventing this accident would basically give you a budget of $223 million, human lives not even taken into account.