Ну вот вы видите, что в поле ввода цифры при вводе показываются слева и мигает курсор. А нажимаете Enter - цифра перемещается направо и курсор исчезает. Опытный пользователь вообще не задумывается. Проблема в том, что далеко не все преподаватели - опытные пользователи.
На самом деле, этот паттерн тоже размывается, по мере того как юзабилити других сервисов улучшается. И новое поколение "опытных пользователей" уже ожидает от системы, что она сохраняет все их действия.
Проблема в плохо спроектированном компоненте «таблица», который позволяет терять введённые данные. Пользователи, как вы верно заметили, действовали интуитивно - как в Excel.
Но как пример «неинтуитивности» очень хорошо, спасибо.
Проблема в том, что в команде не было юзабилиста. Программисты не считали компонент плохо спроектированным, потому что он прекрасно реализует нужные им функции.
В приведенном кейсе с таблицей это не интуитивно понятное поведение. Но если в ТЗ заявлено интуитивно понятный, а в проект взяли такой компонент таблицы и не было тесткейса для тестировщика, то это косяк исполнителя как по мне. И с формулировкой "интуитивно понятно" даже в этом кейсе все норм) если со здравым смыслом подходить.
К сожалению это не одиночный кейс. Таким образом в продукты и попадают неудобные виджеты для календаря или компоненты редактирования содержимого поля. Сам тому свидетель.
А тестировщика порой кажется полностью играют за разработчиков. Фиксируя только явные баги, или формальное несоответствие спецификации. Особенно это чувствуется в проектах и продуктах, где нет ролей, отвечающих за ux или контроль качества.
Это было бы смешно, если бы я не слышал про "здравый смысл" от руководителя и владельца одной компании, разрабатывающей банковское ПО. Юзабилиста там тоже не было. Ну, то есть, была, но её уволили за ненадобностью.
В компаниях, где я работал и работаю нет юзабелиста) именно потому что "не нужен". И это чувствуется, увы. Но это же не проблема формулировки "интуитивно понятный" в ТЗ?