Pull to refresh

Comments 11

Если использовать термин "система для профессионалов" вместо "система для бизнеса", то будет понятнее почему они сложнее для восприятия. При адаптации интерфейса нужно будет учитывать и устоявшиеся привычки работы в конкретной области. У меня был случай, когда мы уменьшили число клавиатурных комбинаций на одну. И пользователи попросили вернуть, так как все операции они делали за устоявшееся число нажатий.

Еще мой опыт показал, что пример с ускорением операций не работает как аргумент. Приведу пример. Вы создаете систему автоматизации согласования на крупном предприятии. Теперь согласования по отделам идут в электронном виде быстрее, чем если бы сам инициатор ходил со списком. Теперь перед клиентом стоит выбор: потратить несколько миллионов на покупку системы, и потом еще сумму на сопровождение, или нанять стажера на 20 т.р., задача которого будет ходить со списком по отделам.

Лучше работает аргумент с уменьшением числа ошибок.

Всё так, любые предлагаемые улучшения пользовательского интерфейса разбиваются об логику "Ну вы же сейчас и так работаете". Пересев с кресла пользователя в кресло продакта делаешь S4U, ведь делаешь для себя.

постоянно повышать удобство использования и упрощать системы

К сожалению, часто это выливается в добавление "воздушного" (раздутого) интерфейса везде, где это не нужно. Вместо привычного расположения элементов получаем кучу пустого незадействованного места с блеклыми нечитаемыми виджетами. А то, что раньше делалось 2-3 нажатиями мышью теперь потребует путешествия по 2-3 подменю.

Дизайнерам дай только волю, и они кинутся чинить то, что хорошо работает, ломая привычки и паттерны работы каждые 2-3 года.

Честное слово, иногда думаешь, что было бы лучше, если бы дизайном интерфейсов снова занимались программисты.

Здесь проблема не в дизайнерах, а в том что в промышленности к дизайнерам отношение (в основном) как к "рисовалкиным" с соответствующим уважением и вознаграждением (то есть очень скромным, даже по меркам отрасли).

Настоящий дизайнер, тот же инженер, который проектирует интерфейс. Делать из любого дизайн "воздушный" или делать подменю ради полменю это дешёвый и провинциальный подход недоучек. Нормальный подход это начинать с целей, потребностей и опыта пользователей (то есть с понимания что для них важно и действительно нужно). И если максимальная эффективность (с точки зрения и бизнеса и пользователя) достигается навороченным интерфейсом с большим количеством деталей на одном экране (как раз работал с такой профессиональной В2В системой), то значит интерфейс такой и будет.

Хороший пример, скрин из WoW ниже: если пользователь получает удовольствие от такого интерфейса — значит дизайнер должен позаботиться об этом и сделать возможность для кастома. В тоже время не надо пугать новичков запутанным интерфейсом в самом начале, это можно делать последовательно. Кстати, также было и в Танках (когда там была хорошая команда дизайнеров) — интерфейс был сложнее чем можно было бы сделать именно потому что ключевая ЦА любит все такое "навороченное". Хорошие дизайнеры, без условно, это учитывают.

Очень жаль что вас окружали не профессионалы, но поверьте, бывает иначе.

не только в корпоративном софте

Этот скрин – практически контрпример посылу статьи про необходимость упрощения систем.

Оригинальный интерфейс WoW гораздо проще. Почти все элементы на этом скрине добавлены или модифицированы САМИМ пользователем с помошью аддонов.

Игроку важнее информативность интерфейса, особенно в динамичной обстановке, чем некая абстрактная юзабилити, которую дизайнеры, разработавшие систему, но никода ей не пользовавшиеся, придумали у себя в голове.

Давайте разделять продукт для каждого и АРМ (автоматизованное рабочее место).

Первое да. Им должен пользоваться любой, этот продукт открывает "двери" и проносит прибыль и все такое

Второй. Начнем с того, что функционала намного больше, под капотом на порядок два больше сущностей, которые надо обрабатывать. Часто интерфейс следствиебизнес логики системы, в которой уже может быть заложена определенная унификация процессов, конфигурабельность и т.д.

Третий. Многие интерфейсы к сожалению банально являются частью системы, которой уже 20+ лет. Их переписывание часто банально сложно из-за отстуствия API (т.е. понятно, что оно есть, но ни фига не то, к которому привык современный фронтенд)

И самое главное. В мире розовых пони, коротких штанишек и леденцов на палочке все просто и понятно. В реальном мире, продукт, который имеет внедрения по всему миру нельяз просто так взять и поменять интерфейс. Так как его надо простетировать в куче конфигураций и на куче клиентов. А если что-то пойдет не так - вполне реальны прилеты на много денег

----------

А так да, в некоторых мирах все очень просто

В реальном мире, у продукта, который имеет внедрения по всему миру нельзя просто так взять и поменять интерфейс.

Ваши бы слова да Майкрософту в уши...

Когда я смотрю, как дети самостоятельно разбираются с интерфейсами программ, которые им нужны, без всякой помощи, при этом я сам не могу с ними разобраться, думается, что ваша статья несколько... пессимистичная.

Нет неудобных интерфейсов, в общем-то. Есть мало необходимости и мало мотивации.

Я полностью поддерживаю тезис, что значительное количество пользовательских интерфейсов профессиональных приложений не от мира сего, "проектировались" теми кто имел очень смутное представление о выполняемых в приложении задачах, и представляют собой нагромождение кнопок, цифирок и менюшек. Иногда просто диву даёшься, это ж какое изменённое сознание надо иметь чтобы так неудобно сделать. С другой стороны, теперь проектированием занялись "профессиональные дизайнеры", и стало ещё хуже, появился "интуитивно понятный интерфейс" с большими кнопками, интервалами, управлением мышкой, скроллингом итп.
Дело не в том, простой интерфейс или сложный, а насколько он соответствует выполняемым задачам. Более того, в хорошо сделанном "сложном" интерфейсе работать быстрее и проще, но это требует обучения и тренировки. Банальные шорткаты абсолютно не интуитивны, но ускоряют работу в разы по сравнению с мышкой. Поэтому надо понимать, хочешь ты сократить усилия на обучение, или улучшить качество работы (ускорить, упростить, уменьшить ошибки, снизить утомляемость..).
При этом само собой необходимо оценивать, ради чего тратятся неслабые деньги - чтобы сотрудник выполнял больше полезной работы, или получил больше времени гонять чаи на кухне? При этом категорически поддерживаю замечание, что мнение пользователей системы обычно мало кого интересует ("менеджеры продают топам").

Юзабилити привязано к пользовательскому сценарию. Нельзя пускать бухгалтера в админку сапа. Для бухгалтера надо делать экран, удобный ему. И нельзя пускать маркетолога в экран бухгалтера - там будут сотни статей и внутренних счетов, понятных и удобных бухгалтеру, нужных ему постоянно. А маркетологу нужно три поля для заведения РО и кнопочка аппрувала.

А если вы делаете одну базу, в которой все сотрудники и РО заводят, и аккруалы считают и бюджет планируют - то конечно будет каша. Но это проблема не разработки интерфейса, а понимания того, как системой будут пользоваться реальные люди.

Sign up to leave a comment.

Articles