Comments 12
Татьяна, спасибо за ваш комментарий.
Я не участвовал в проектировании описанных вами интерфейсов и не знаю причин, которые побудили разработчиков вносить подобные изменения. Но могу порассуждать о факторах, которые могли оказать влияние на принятые решения:
Унификация дизайна между разделами системы.
Влияние отдела маркетинга. Если произошел ребрендинг, или выпустили обновленный фирменный стиль, все разделы системы подлежат адаптации под него. У маркетологов свои причины на такие изменения.
Смена команды разработчиков.
Я согласен с вами в том, что
а) глобальное изменение ранее устоявшегося дизайна должно быть опциональным: пользователю необходимо предоставлять выбор между старым и новым интерфейсом.
б) непреднамеренная потеря функциональности интерфейса при таких изменениях недопустима.
В то же время из опыта внедрения я знаю, что любые изменения в привычных решениях всегда изначально тяжело воспринимаются любым человеком. Иногда нужно дать им время (шанс) на раскрытие потенциала полезности.
Что касается недостаточной информированности после действия пользователя: этого точно можно было избежать, следуя советам из моей статьи.
Самое прикольное в том, что "вид снизу" на самой первой картинке (с младенцем и игрушками) - неправильный. Порядок игрушек-животных как в виде сверху, то есть наоборот.
Статья как попытка оправдать необходимость в своей работе.
Добрый вечер, приведите аргументы, пожалуйста. Почему вы считаете, что работу аналитика или дизайнера нужно оправдывать?
Потому что, чем больше впечатляющей аналитики создается вокруг проекта и чем больше людей, участвующих в принятии решения, тем хуже будет результат. Обычно это все надо только для того, чтобы убедить инвестора раскошелиться, в реальной же жизни это только помеха. Нужен один ЛПР и один-два спеца (дизайнер и продуктовнер). Для себя PO конечно должен проводить исследования (выступать как маркетолог) но для дизайнера нужны только выводы. Ну и дизайнер должен находиться в условиях, кода ему платят не за количество "краски", а за конечный результат (повышение конверсии сайта например). Все остальное от лукавого. Более того, если это "все остальное" требуют, то значит компания уже стала жертвой административной бюрократии. В таком случае там плодятся и множаться должности, отвечающие за исследования, разработку, внедрение и обратную связь. Каждый шаг приходится обосновывать графиками и таблицами и т.д. Ну вы в общем все это прекрасно описали) Сочувствую вам, что приходится работать в таких условиях.
"PO конечно должен проводить исследования" - это основное, что я пытался донести в статье. Потому что в корпоративной разработке аналитик работает и за продуктовнера, и за дизайнера. А ситуация в статье описана прямо противоположная административной бюрократии и избыточности артефактов.
Спасибо за обратную связь.
"Сразу отметаю «интуитивно понятный» – это требование, которое невозможно формализовать." - очень даже можно, особенно если вы делаете UI для нового модуля системы, которая уже имеет N реализованных модулей. Ваш UI должен использовать ранее принятые приемы и решения, шрифты, цвета, подходы к отображению ошибок валидации данных и т.д...
Если же вы делаете с UI нуля, то в понятность входят общепринятые подходы к решению определенных ситуаций, вроде:
при удалении объекта должна отображаться форма подтверждения удаления.
при выполнении запросов должен отображаться индикатор.
поля, не прошедшие валидацию должны иметь индикацию.
поля для выбора даты должны иметь возможность вызвать datepicker.
поля для выбора значения из списка должны предоставлять варианты значения для введенного фрагмента.
если кнопка или поле заблокированы, то при наведении должна отображаться причина блокировки.
и прочая прочая... вплоть до того, в каких ситуациях текст должен выравниваться по левому краю, в каких по ширине и какие шрифты и цветовые пары использовать...
Сюда же входит "отзывчивость" - при нажатии кнопки системы должна реагировать в течении N секунд, иначе пользователю работать некомфортно или он вообще входит в ступор. Вполне измеряемая характеристика...
Если бы была возможность, я бы ещё раз сходила на этот доклад!
Спасибо, что формализовали в статью =)
Как сделать доступный UI, несмотря на хорошее ТЗ