В начале июня я модерировал конференцию «ИТ в промышленности». На круглом столе по обучению персонала возник интересный вопрос: можно ли создать промышленную программу с простым интерфейсом?
Если упростить интерфейс, то и обучать сотрудников не надо. Можно сравнить SAP, в интерфейсе которого нет ничего человеческого, и Убер. Почему-то никто же запускает курсы «как пользоваться убером»? А вот для SAP такие курсы необходимы.
На круглом столе пришли к мнению: нет, нельзя! У нас в управлении сложные системы со сложными процессами, которые нельзя упростить до Убера. Да и денег на это нет!
К сожалению, формат круглого стола не предполагал больших дискуссий, и обсудить детально тезис не получилось. Но, на мой взгляд, это ошибочное мнение. Давайте разберем почему.
Можно ли упростить интерфейсы?
Есть множество примеров, что упрощения интерфейсов. Компьютеры прошли от перфокарт до nocode. Куча кнопок в мобильном телефоне превратилась в добавить-убавить звук, стилус исчез. Раньше, чтобы управлять машиной, нужно было уметь менять свечи. Сейчас люди управляют машиной иногда не понимая, как залить воду в бачок омывателя, я уж не говорю про доливку масла.
То есть, примеров упрощения интерфейсов много. Почему же про промышленные системы получилось мнение, что упрощение невозможно?
Почему системы сложные?
Системы можно разделить на два класса:
системы для пользователя, S4U — systems for users. Это то, что используем мы с вами как конечные пользователи: айфон, убер, букинг.ком, айр-би-эн-би, легковые автомобили и так далее.
системы для бизнеса, S4B — systems for business. Это то, что компания поручает нам использовать: SAP, Oracle, 1C, самолеты и т.д.
Эти классы систем отличаются по направлениям развития:
1. Конечный пользователь не может добровольно отказаться от систем для бизнеса (S4B), в отличие от систем для пользователя (S4U). Если нам не нравится айфон — мы покупаем андроид, или наоборот. Мне не нравится приложение для заметок — я перехожу на другое, это полностью мое решение.
В системах для бизнеса не так. Сотрудники прикованы к системам для бизнеса трудовым договорами и должностными инструкциями. Мне не нравится интерфейс 1С — но я не могу отказаться от использования 1С.
2. Конечный пользователь не участвует в выборе систем для бизнеса (S4B). И даже если участвует, то фактор юзабилити не играет решающей роли при выборе системы. Сейлзы, которые не работают с системой, продают систему топ-менеджерам, которые тоже с системой не работают. Максимум смотрят отчеты в системе.
Системы для пользователей не могут не обращать внимание на удобство использования. Если бы интерфейс Убера был бы похож на интерфейс SAPа — то стартап бы умер, даже не начавшись. А если бы пользовательский опыт от айфона походил бы на использование компьютера с перфокартой — мы бы до сих пор сидели на телефонах с кнопками.
Системы для пользователей отбираются и эволюционируют, в том числе, по удобству использования. Оцениваются неправильные действия пользователей, как они влияют на опыт работы с приложением, повторные заказы и т.д., то есть интерфейс постоянно подстраивается под пользователя.
Системам для бизнеса, по большей части, наплевать на поведение пользователей — для них это вторая линия целей. Если пользователь что-то в системе не понимает, то это проблема конкретной компании и конкретного сотрудника: обучайте сотрудников тщательнее, вот вам инструкции (если повезет, то понятные и удобные), внедряйте наставничество и так далее.
Я как-то обсуждал личный кабинет сотрудника в одной из компаний. Я беспокоился, что люди не станут его использовать, так как интерфейс был достаточно сложным. На что получил прекрасный ответ: «Не надо беспокоиться! Мы им просто прикажем!!!» Подобный ответ я слышал и в других компаниях.
Работа с ошибками пользователей
Ошибка пользователя в системах для бизнеса всегда остается ответственностью самого пользователя. В 2005 году брокер японской компании вместо продажи 1 акции по цене 610 тыс. йен ввел приказ на продажу 610 тыс. акций по цене 1 йена. Ущерб составил 27 млрд. йен. При анализе этой ситуации никто не говорит про юзабилити софта, все говорят про ошибку брокера.
В моей практике был пример, когда оператор ввела цену товара 2500,00 вместо 25,00 руб.: заела запятая на клавиатуре или отвлекли. Эту цену согласовали коммерческий, финансовый и генеральный директора. Заметил только кладовщик — объем заказа не соотносился с суммой заказа.
После этого мы переработали портал ввода цен: ввели пробелы между разрядами, увеличили шрифт, добавили предупреждения и другие действия, чтобы снизить вероятность неправильного ввода цены. Неожиданно, как мне сказали операторы, работать с новой системой оказалось на порядок удобней!
Так что системы для бизнеса такие уродливые и неудобные не потому, что их нельзя сделать проще, а потому что компаниям и разработчикам наплевать на конечных пользователей. Главное: отчеты, производительность, масштабируемость и так далее.
Сколько стоит удобство
Как можно оценить удобство использования системы? Специалисты по промышленному дизайну скажут, что удобный интерфейс приносит огромное количество выгод: сокращение времени, снижение ошибок, меньше утомляемость и т.д.
Можно оценить юзабилити на простом примере. Предположим, что мы упростили одну операцию с 35 секунд до 5. Пользователь выполняет эту операцию 10 раз в день. То есть, экономия времени составит 5 минут в день: 30 секунд умножить на десять.
Экономия времени в год на одного пользователя составит: 5 минут на 240 рабочих дней, что дает нам 1200 минут или 20 часов или 2,5 рабочих дня. Если предположить, что в компании 1000 пользователей, то мы приходим к экономии в год 2500 рабочих дня, или 10 штатных единиц.
Если перевести это в деньги, то получается достаточно внушительная сумма. Если еще предположить, что для новой операции не нужно обучения и количество ошибок снижается в несколько раз, то эффективность простого изменения может быть просто гигантской.
Бизнес-логика
Но такая оценка наталкивается на суровую логику: как доказать эти расчеты?
Как мне сказал один из топов: Смотри, мы же не станем платить сотрудникам меньше от того, что они станут работать меньше? Значит, экономической выгоды нет. Так зачем же тратить деньги на проект, где нет экономической выгоды?
В чем-то эта логика правильная. Если у нас сотрудник работал ровно 8 часов, а сейчас он работает 7 часов 55 минут — мы все равно должны будем заплатить ему за 8 часов работы. Если следовать этой логике, то выгода от сокращения одной минуты равна нулю. Ну, компания же с этого ничего не выиграет!
Подобная оценка приводит к негативному эффекту: стоимость добавления еще одной минуты к рабочему времени тоже принимается равной нулю. Ну, сотрудник же не все 8 часов в день работает. Он болтает с коллегами, пьет чай, ходит в туалет! Значит, запас времени есть, и можно добавить еще минуты две-три, или даже 10 минут.
В моей практике был проект на 500 млн. руб, который не работал, так как не предусмотрели, кто будет тратить 5 (реально 5) минут в день. Система анализировала разные потоки данных, выдавала потенциально вредные ситуации, которые надо было разделить на безопасные и вредные. Как всегда бывает, это возложили на директора магазина, у которого и так была куча обязанностей — ему было не до этого. В итоге навороченная система генерировала поток данных, которые никто никак не использовал!
Возрастающая нагрузка
— Сколько у вас стоит капелька водки?
— Капелька? нисколько!
— Тогда накапайте мне стаканчик!
Системы для бизнеса постоянно расширяются. В компании может быть несколько проектов, каждый из которых добавляет одну-две или больше операций, никак это в затратах не показывая. Что в конечном итоге приводит к перегрузке сотрудников.
Сотрудники, конечно, будут жаловаться на возрастающий объем работы. Но тут вступает другая логика: раньше же все успевали! Тут всего лишь пару простых операций в системе добавили. Вы просто не хотите или не умеете работать. А если какую-нибудь операцию сотрудники выполняют за 10 минут, то все будут говорить про неразвитое поколение, кривую обучения, некачественную подготовку сотрудников и т.д. А система? Система воспринимается как данность: в других компаниях же работают!
Рост нагрузки на сотрудника в конечном итоге приводит к повышению текучести персонала. Текучесть персонала измеряется просто, но доказать причинно-следственную связь между неудобными программами и текучестью фактически невозможно! На текучесть влияет множество факторов, и выделить влияние одной операции на уход сотрудника — нужны масштабные исследования, на которые нужны время и деньги.
В сухом остатке получается, что хотя эффективность и выгода от повышения юзабилити значительна, но доказать ее мы не можем. В таком случае более значимыми становятся проекты, в которых проще рассчитать показатели, нежели проекты, которые могут кардинально поменять работу в компании. В этом случае бизнес-поговорка: «если ты не можешь что-то измерить, то ты не можешь этим управлять» превращается в «ты управляешь тем, что проще всего измерить».
Заключение
Повышение юзабилити систем приводит к значительным выгодам: экономится время сотрудников, уменьшается время на обучение, снижается количество ошибок и так далее. Чем больше компания — тем значительнее будет эффект.
Текущие практики оценки проектов не позволяют доказать выгоды от повышения юзабилити:
1. Если мы сократим время одной операции — то мы не уволим никого из сотрудников.
2. Если сотрудник не успевает что-то сделать — это его ответственность.
3. Влияние прочих факторов доказать сложно, поэтому их в расчет не принимают.
Чтобы избежать подобной логики, нужно говорить не про количество штатных единиц, а про пул рабочего времени в распоряжении компании. Мы сократили время работы с системой на 2500 человекодней в год? Значит, мы увеличили возможности компании на это время. То, как компания использует этот пул времени — это вопрос эффективности операционных процедур компании, но не вопрос эффективности повышения юзабилити.
На мой взгляд, все должны взять как цель доведение интерфейса S4B до уровня S4U. Да, заказ такси всегда будет проще, чем управление атомной электростанцией. Разработать для всех систем софт, подобный уберу, скорее всего невозможно. Но цель не в том, чтобы довести интерфейсы всех систем до уровня одной кнопки, а в том, чтобы постоянно повышать удобство использования и упрощать системы. Даже если повысить юзабилити систем на 10-20 %, то будет просто круто.
Сама посылка, что системы для бизнеса нельзя привести к уровню убера — вредна, так как не двигает системы в правильном направлении.
Автор: Алексей Коряков
Комментарии (11)
HumanBearPig
01.08.2024 12:45Всё так, любые предлагаемые улучшения пользовательского интерфейса разбиваются об логику "Ну вы же сейчас и так работаете". Пересев с кресла пользователя в кресло продакта делаешь S4U, ведь делаешь для себя.
erydit
01.08.2024 12:45+4постоянно повышать удобство использования и упрощать системы
К сожалению, часто это выливается в добавление "воздушного" (раздутого) интерфейса везде, где это не нужно. Вместо привычного расположения элементов получаем кучу пустого незадействованного места с блеклыми нечитаемыми виджетами. А то, что раньше делалось 2-3 нажатиями мышью теперь потребует путешествия по 2-3 подменю.
Дизайнерам дай только волю, и они кинутся чинить то, что хорошо работает, ломая привычки и паттерны работы каждые 2-3 года.
Честное слово, иногда думаешь, что было бы лучше, если бы дизайном интерфейсов снова занимались программисты.
Swordman85
01.08.2024 12:45Здесь проблема не в дизайнерах, а в том что в промышленности к дизайнерам отношение (в основном) как к "рисовалкиным" с соответствующим уважением и вознаграждением (то есть очень скромным, даже по меркам отрасли).
Настоящий дизайнер, тот же инженер, который проектирует интерфейс. Делать из любого дизайн "воздушный" или делать подменю ради полменю это дешёвый и провинциальный подход недоучек. Нормальный подход это начинать с целей, потребностей и опыта пользователей (то есть с понимания что для них важно и действительно нужно). И если максимальная эффективность (с точки зрения и бизнеса и пользователя) достигается навороченным интерфейсом с большим количеством деталей на одном экране (как раз работал с такой профессиональной В2В системой), то значит интерфейс такой и будет.
Хороший пример, скрин из WoW ниже: если пользователь получает удовольствие от такого интерфейса — значит дизайнер должен позаботиться об этом и сделать возможность для кастома. В тоже время не надо пугать новичков запутанным интерфейсом в самом начале, это можно делать последовательно. Кстати, также было и в Танках (когда там была хорошая команда дизайнеров) — интерфейс был сложнее чем можно было бы сделать именно потому что ключевая ЦА любит все такое "навороченное". Хорошие дизайнеры, без условно, это учитывают.
Очень жаль что вас окружали не профессионалы, но поверьте, бывает иначе.
wmlab
01.08.2024 12:45+2не только в корпоративном софте
erydit
01.08.2024 12:45+2Этот скрин – практически контрпример посылу статьи про необходимость упрощения систем.
Оригинальный интерфейс WoW гораздо проще. Почти все элементы на этом скрине добавлены или модифицированы САМИМ пользователем с помошью аддонов.
Игроку важнее информативность интерфейса, особенно в динамичной обстановке, чем некая абстрактная юзабилити, которую дизайнеры, разработавшие систему, но никода ей не пользовавшиеся, придумали у себя в голове.
Batalmv
01.08.2024 12:45+2Давайте разделять продукт для каждого и АРМ (автоматизованное рабочее место).
Первое да. Им должен пользоваться любой, этот продукт открывает "двери" и проносит прибыль и все такое
Второй. Начнем с того, что функционала намного больше, под капотом на порядок два больше сущностей, которые надо обрабатывать. Часто интерфейс следствиебизнес логики системы, в которой уже может быть заложена определенная унификация процессов, конфигурабельность и т.д.
Третий. Многие интерфейсы к сожалению банально являются частью системы, которой уже 20+ лет. Их переписывание часто банально сложно из-за отстуствия API (т.е. понятно, что оно есть, но ни фига не то, к которому привык современный фронтенд)
И самое главное. В мире розовых пони, коротких штанишек и леденцов на палочке все просто и понятно. В реальном мире, продукт, который имеет внедрения по всему миру нельяз просто так взять и поменять интерфейс. Так как его надо простетировать в куче конфигураций и на куче клиентов. А если что-то пойдет не так - вполне реальны прилеты на много денег
----------
А так да, в некоторых мирах все очень просто
Wizard_of_light
01.08.2024 12:45В реальном мире, у продукта, который имеет внедрения по всему миру нельзя просто так взять и поменять интерфейс.
Ваши бы слова да Майкрософту в уши...
DenSigma
01.08.2024 12:45Когда я смотрю, как дети самостоятельно разбираются с интерфейсами программ, которые им нужны, без всякой помощи, при этом я сам не могу с ними разобраться, думается, что ваша статья несколько... пессимистичная.
Нет неудобных интерфейсов, в общем-то. Есть мало необходимости и мало мотивации.
wolodik
01.08.2024 12:45Я полностью поддерживаю тезис, что значительное количество пользовательских интерфейсов профессиональных приложений не от мира сего, "проектировались" теми кто имел очень смутное представление о выполняемых в приложении задачах, и представляют собой нагромождение кнопок, цифирок и менюшек. Иногда просто диву даёшься, это ж какое изменённое сознание надо иметь чтобы так неудобно сделать. С другой стороны, теперь проектированием занялись "профессиональные дизайнеры", и стало ещё хуже, появился "интуитивно понятный интерфейс" с большими кнопками, интервалами, управлением мышкой, скроллингом итп.
Дело не в том, простой интерфейс или сложный, а насколько он соответствует выполняемым задачам. Более того, в хорошо сделанном "сложном" интерфейсе работать быстрее и проще, но это требует обучения и тренировки. Банальные шорткаты абсолютно не интуитивны, но ускоряют работу в разы по сравнению с мышкой. Поэтому надо понимать, хочешь ты сократить усилия на обучение, или улучшить качество работы (ускорить, упростить, уменьшить ошибки, снизить утомляемость..).
При этом само собой необходимо оценивать, ради чего тратятся неслабые деньги - чтобы сотрудник выполнял больше полезной работы, или получил больше времени гонять чаи на кухне? При этом категорически поддерживаю замечание, что мнение пользователей системы обычно мало кого интересует ("менеджеры продают топам").
Asterris
01.08.2024 12:45Юзабилити привязано к пользовательскому сценарию. Нельзя пускать бухгалтера в админку сапа. Для бухгалтера надо делать экран, удобный ему. И нельзя пускать маркетолога в экран бухгалтера - там будут сотни статей и внутренних счетов, понятных и удобных бухгалтеру, нужных ему постоянно. А маркетологу нужно три поля для заведения РО и кнопочка аппрувала.
А если вы делаете одну базу, в которой все сотрудники и РО заводят, и аккруалы считают и бюджет планируют - то конечно будет каша. Но это проблема не разработки интерфейса, а понимания того, как системой будут пользоваться реальные люди.
MikhailZakharov
Если использовать термин "система для профессионалов" вместо "система для бизнеса", то будет понятнее почему они сложнее для восприятия. При адаптации интерфейса нужно будет учитывать и устоявшиеся привычки работы в конкретной области. У меня был случай, когда мы уменьшили число клавиатурных комбинаций на одну. И пользователи попросили вернуть, так как все операции они делали за устоявшееся число нажатий.
Еще мой опыт показал, что пример с ускорением операций не работает как аргумент. Приведу пример. Вы создаете систему автоматизации согласования на крупном предприятии. Теперь согласования по отделам идут в электронном виде быстрее, чем если бы сам инициатор ходил со списком. Теперь перед клиентом стоит выбор: потратить несколько миллионов на покупку системы, и потом еще сумму на сопровождение, или нанять стажера на 20 т.р., задача которого будет ходить со списком по отделам.
Лучше работает аргумент с уменьшением числа ошибок.