Технологи — особенные пользователи. У них огромная ответственность, руки в перчатках, на лице — защитные очки. В цехе полутемно или светится раскалённый металл, а им нужно отследить сотни параметров техпроцесса. И им очень хочется, чтобы всё работало как часы. Правда, представления об идеальной работе у них сильно отличаются от привычного UI/UX.
Некоторые мастера внезапно просили нас усложнить интерфейсы.
Прямо реально усложнить: добавить меню, подменю, передвинуть кнопку, сделать крупнее. Ответ очень простой: они привыкли к старой оракловой системе с интерфейсами из кучи выпадающих меню. Некоторые по 20 лет тыкали в эти менюшки и сформировали мышечную память. Где-то людей просто бесил порядок кнопок, например: «Кнопка «Отменить» всегда была справа. Переставьте, пожалуйста!»
Аналогично — с горячими клавишами. Если восемь лет назад мастер запомнил, что Ctrl+R означает «Контроль реза», то так и будет нажимать в новой системе, рассчитывая на знакомое поведение. Поэтому мы подняли все старые комбинации и добавили их в новый софт. Теперь работают и новые горячие клавиши, и привычные опытным мастерам аккорды.

А тут — хороший пример ещё одного принципа. Верх страницы для технологов — визуальный мусор. На макете заголовок смотрится очень хорошо. На практике эту страницу они открывают на мониторе на стене либо каждый день видят много тысяч раз. Им важно, что находится на экране внутри контентной области. То есть заголовок в интерфейсе в такой ситуации надо делать не просто маленьким, а очень маленьким, чтобы он не занимал драгоценного места.
В цехах мы узнали ещё много нового про UI/UX, а заодно про себя и свою работу.

Зачем мы это делаем
Удобные и понятные интерфейсы снижают риски на заводе. Речь идёт, конечно, не про спасённые жизни (такой статистики особо нет), а про уменьшение ошибок.
Сначала мы разработали специальные интерфейсы для завода, а потом начали наблюдать, что технологи делают с ними в цехах.
Напомню, что в самом начале мы адаптировали цветовую палитру для работы в цехах, повысили читаемость шрифтов, поработали с таблицами, и это почти всем понравилось. С того момента, как мы начали, прошло четыре года, три больших исследования на производстве и появилось много нового фронта.
Вот здесь — первый пост про палитру и другие детали.
Вот примеры того, что важно:
1. Многие терминалы стоят в местах с не очень хорошим освещением (иногда — вообще прямо в цехах выплавки или проката, иногда — в кабинах карьерных экскаваторов и так далее). Нужна палитра, которая не слепит при многочасовой работе.
2. Необходимо, чтобы интерфейс был спокойным и акцентами подсвечивались только значимые вещи. Условно пять часов вы смотрите на таблицу 20 х 20 ячеек с параметрами техпроцесса, и когда один из них начнёт выходить за пределы, надо подсветить его жёлтым, а когда выйдет — сделать алерт и подсветить красным. Сейчас я утрирую, но никаких других жёлтых акцентов быть не должно. Для технолога жёлтый в этом интерфейсе — признак проблемы. Если так не делать, то пользователь вовремя не отреагирует.

3. Многие используют аналоги диспетчерских экранов: выводят страницу на монитор на стене и смотрят. Многие не могут проскроллить вниз из-за перчаток или других СИЗов. Поэтому в идеале вся важная информация должна умещаться на первом экране без скролла.

4. Почти нет мобильных устройств (точнее, есть планшеты, но это другие интерфейсы), а экраны — крупные и длинные. Большая часть сложных работ идёт с таблицами, которые должны быть оптимизированы под такие экраны.
Но давайте я продолжу про практику с конкретными примерами.
Не оставлять пользователя в когнитивном тупике
Машинист пожаловался, что он не понимает новой системы. Разбираемся и видим вот такое:

Это явный баг. Но проблема тут не только в баге, а ещё в том, как показывается ошибка. Машинист — не айтишник. Код ошибки ему ничего не скажет. Тут нужно писать конкретное действие, которое ему необходимо предпринять, например: «Попробуй через пять минут», «Включи и выключи», «Позвони в поддержку» и так далее.
Ещё пример: это паспорт плавки. Пользователь говорит, что поля пустые, а это ошибка. На самом деле просто ещё не пришёл химический анализ из лаборатории. Соответственно, пользователь думает, что система не работает. То есть мы здесь ошиблись в том, что не написали статус «Ждём из лаборатории» напротив каждого «пустого» показателя.

В целом это базовый принцип — не оставлять пользователя на экране без понимания того, что там делать. Вместо пустых плашек или плашек «Нет информации» должны быть статусы или какие-то пояснения вроде «Тут будут письма, но пока их ещё нет» или «Сюда придёт лабораторный анализ».
«Долго грузит»
Вот тут другой технолог пожаловался, что система «медленно грузит»:

Речь идёт про таблицу на экране слева. Дело вот в чём: у него на втором экране открыта мнемосхема цеха, где в реальном времени движутся агрегаты. Это поведение мнемосхемы натолкнуло технолога на ощущение, что всё обновляется в реальном времени. Таблица обновляется либо по F5, либо раз в 10 минут сама. 10 минут — слишком долго для него, он хочет видеть данные сразу. Про F5 он не знает, т. к. интуитивно ожидает, что таблица будет обновляться сразу после изменения данных.
Это знание помогло всем нашим интерфейсам: теперь у нас ячейки динамически обновляются, и мы следим за тем, чтобы все таблицы работали именно так. Если это по каким-то причинам происходит по-другому, то это должно быть явно обозначено.
Технологи ждут именно оперативной обстановки: это сложнее сделать, но это то поведение, которое они интуитивно ожидают от интерфейса.
Можно просто сказать

Здесь на участке внепечной обработки цеховые попросили подсветить серу жёлтым, когда значение ещё не превышено, но уже и не на нижней границе. Они посовещались и решили, что начиная с порога в 25 единиц надо что-то делать. И попросили, чтобы интерфейс показывал эту границу. Собственно, мы подсветили и ещё добавили возможность для пользователя самостоятельно выбрать цвет, а легенду разместили рядом с диаграммой или таблицей, чтобы не нужно было заходить в справку:

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


В ферросплавном рабочие часто выделяли строки и считали их вручную. Мы сделали счётчик выделенных строк.
Ещё ситуации

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

Сидим, смотрим за человеком, каждый раз он забивает дату плавки заново. Его это вообще не смущает: он привык, что интерфейсы неудобные. Каждый раз это сегодняшняя дата. Спрашиваем, будет ли удобно, если будем по умолчанию её показывать. Сначала оператор даже не понял, а потом прямо просиял: а что, так можно было?
Были ещё случаи, когда какие-то данные вносились дважды, хотя их можно было взять с предыдущей формы, где-то из номера заказа можно было вытащить дату (то есть не надо было её вводить, потому что она уже есть в базе) и так далее. Пользователи не всегда понимают, что всё это может быть автоматизировано, но очень рады, когда потом видят различия: система как будто стала умнее.
Тут очень странная ситуация. Красный индикатор — ЧЗК без обработки на УДЧ, оранжевый — ЧЗК был обработан на УДЧ:

Бригадир сказал, что издалека плохо видно разницу между этими оттенками, к тому же оранжевый не совсем логичен в данном случае: ассоциируется с предупреждением или не до конца выполненной операцией. Возможно, это как раз потому, что в прошлой системе статус готовности был оранжевым, и кто-то внёс это в требования к новой.
Мы решили руководствоваться логикой и подсветили зелёным обработанный ЧЗК на УДЧ.

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

Мы делали ещё много всего после такой практики на производстве. Где-то шли по запросам пользователей, где-то наблюдали и понимали, что чего-то не хватает. Вот, например, тут мастер надевал очки каждый раз, когда ему надо было внимательно присмотреться к бункеру. Это прямо очень яркий пример, что с индикацией что-то не так: ему нужно вычитывать что-то вместо понятного статуса. Стало ясно, что необходимы иконки состояний типа вот таких:

Интересно, что в паре аналогичных случаев пригодилась бы звуковая индикация событий, но в цехах очень шумно, поэтому эта часть UI/UX, увы, просто неприменима.
Где-то оценивали, насколько удобнее будет смотреть схемы оборудования в 3D — за редкими исключениями почти всегда удобнее хорошо нарисованная 2D-схема.
Ну а где-то просто приходили, смотрели на нас, понимали, кто мы и что делаем, и говорили спасибо. Вообще, за последний год такое случается всё чаще, потому что люди начали разбираться в интерфейсах: есть возможность сравнить легаси-системы с новыми, и люди привыкают к хорошему. Очень приятно, что нашу работу теперь понимают и рады ей.
Наша команда с последнего выезда:

Кстати, теперь большинство компонентов дизайн-системы НЛМК можно протестировать вживую: UI-кит для дизайнеров доступен в Figma Community.
ссылка на оригинал статьи https://habr.com/ru/articles/862092/
Добавить комментарий