[patrakov]

While working for one of the previous companies, I hit a regrettable counterexample for the point in the article.

Developers built a web UI for creating containers for the labs, taking the advice from this (then future) article too literally. Their app could only build containers, in the approved way. Yet, not all labs were possible to run in containers, and the app did not account for that (it was a TODO). Worse, people responsible for organizing the labs did not know that not all labs are compatible with containers.

Lab coordinators thus continued to create containers even in cases where it didn't make sense, despite the explicit warning "in cases X, Y, Z, do not proceed, call Alexander instead".

So if you make one button you better make that it is always the right button. People follow the happy-but-wrong path way too easily if there is no other obvious one.

[nemomarx]

Having to read a label and go out of the tool to do something else is basically impossible UX, yeah. You'll never get users to do that, and little in line warnings also won't work unless you block the buttons at the same time I think.

In this example I wonder if the tool was too "MVP" and they didn't evaluate what minimum viable would mean for the users?

[patrakov]

In this case, the product owner had a wrong idea of what's minimum viable, and his idea was faithfully implemented, plus a warning in the app to call me in specific incompatible cases.

Later the missing pieces were added, we had "two buttons" and the resulting user confusion because they did not know and could not be taught whether a container makes sense for a particular lab.