Таблица для цеха отличается от обычной таблицы. Очень сильно:

— «Модные» тонкие шрифты — сразу на свалку. Числа должны читаться даже в маске сварщика.

— Освещение в цехах адаптировано под специфику задач: почти всегда нужна ночная тема.

— Минимум цветов, новый цвет — только привлечь внимание к реально критичной вещи.

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

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

Cтандартные подходы не всегда решали эти задачи.

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

Меня зовут Рамазан Нурулаев, я ведущий UX-дизайнер НЛМК. Над этим проектом мы работали большой командой дизайнеров под руководством Head of design НЛМК Анны Труфановой, а также при участии дизайнера-стажёра Никиты Синицина.

Раньше использовали в основном Excel и Oracle-системы, это было привычно. Сейчас по большей части это таблицы внутри наших интерфейсов. 

Как работают с таблицами в НЛМК и что от них требуется

Условно у нас есть два основных типа таблиц, с которыми на производстве работают по нескольким сценариям:

1.       Расчётные нередактируемые таблицы. В них нельзя менять данные, удалять строки или ячейки. В основном по ним выполняются расчёты различных данных, например, стоимость валков, приёмка железнодорожных составов.

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

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

Когда мы всё это свели в систему, получилось несколько основных требований:

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

·         Моментальное считывание данных. Это чтобы пользователь мог бегло бросить взгляд на таблицу и сразу понять, что происходит и нужно ли предпринять какие-то действия. Даже если он находится на некотором отдалении от экрана и занимается другими задачами.

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

·         Предсказуемая цветовая индикация. Зелёный — всё хорошо, жёлтый — нужно обратить внимание, красный — что-то случилось и требует срочного вмешательства. Причём эта индикация — системная, стандартизированная, чтобы выбранные цвета одинаково использовались у всех работников на производстве.

·         Кастомизация. У пользователя должна быть возможность настроить таблицы под себя, конкретно под свои задачи. То есть выбрать, например, количество отображаемых столбцов и строк, отфильтровать нужные данные, выбрать тёмную или светлую тему, настроить свои локальные цвета (системные не меняются) и т. д.

А что не так с готовыми решениями?

Мы пробовали взять Excel и подогнать его под нужды производства. Но у такого подхода есть несколько проблем:

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

·         Гибкость готовых решений. При наличии в готовых решениях разнообразия настроек и функционала в них не всегда есть те вещи, которые учитывают производственные реалии. Например, в большинстве готовых решений используются «модные» тонкие и блёклые шрифты. Они прекрасно выглядят на хороших мониторах в офисах, но в производственном цеху не работают.

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

В общем, нам нужно было уйти от Excel и Oracle в пользу собственных решений. Мы ездили на производство, собирали все необходимые вводные, подготовили основу и взялись за дело.

Правила проектирования таблиц для производства

Мы оттолкнулись от требований к таблицам на производстве и разработали несколько правил:

·         Цветовая схема. Она включает в себя три основных цвета: красный (опасность), жёлтый («Внимание!») и зелёный (нормальное состояние), а также их настраиваемые вариации, которые пользователь может выбрать сам. Эти цвета должны сочетаться друг с другом так, чтобы все активные элементы хорошо выделялись и были хорошо различимы как на светлой, так и на тёмной теме. Если пользователь применяет более трёх цветов, то должна быть легенда, где указаны её значения, чтобы ему не пришлось их запоминать.

·         Моноширинные шрифты. Если использовать пропорциональные шрифты, где символы разной ширины, числа могут выглядеть искажённо. Число 11111111 (восемь знаков) кажется короче по сравнению с 9999999 (семь знаков) из-за различной ширины цифр. Это может искажать восприятие при быстром сравнении значений. Использование моноширинного шрифта устраняет эту проблему: все цифры имеют одинаковую ширину, что делает таблицы более наглядными и точными.

·         Выравнивание. Числовые данные выравниваются по правому краю для удобства сравнения, а текстовые (наименования, комментарии и т. д.) — по левому.

·         Высота строк. Основной размер — 40 пкс, увеличенный — 56 пкс, компактный — 32 пкс. Это нужно для оптимальной компоновки информации и её читаемости. Изначально мы использовали размер в 28 пкс, но потом поняли, что это слишком мелко. В ячейках могут быть ещё кнопки, иконки, различные бейджи. При таком размере строки они будут плохо различимы.

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

Проблемы и решения

Самой главной проблемой, с которой мы столкнулись, была перегруженность интерфейса. Таблицы надо как-то разместить на ограниченном пространстве экрана, но так, чтобы это не сливалось в кашу.

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

Ещё с помощью фильтров можно сортировать текст по алфавиту, количеству, начальному тексту и другим критериям. Это помогает быстрее ориентироваться в таблице, находить нужные колонки или строки.

Второй способ — скрытые кнопки, которые появляются только при наведении на строку или как контекстное меню при правом клике мыши на строку.

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

Третий способ — уменьшить высоту строк. В первых вариантах таблицы высота строки была 56 пикселей, из-за чего на экране помещалось мало данных. В итоге высоту уменьшили до стандартных 40 и 32 пикселей, чтобы вместить больше информации.

Наконец, четвёртый способ — просто сократить сами наименования колонок или придумать им другие, более короткие названия (например, вместо «Положение плавки» — «Плавка»).

Вложенные таблицы

Вторая большая проблема — вложенные таблицы, которые выпадают из строки при наведении на неё. Некоторые строки содержали несколько, иногда до 10–15, уровней таких вложений, и пользователям было неудобно с ними работать. Мы заменили разворачиваемые строки на боковые панели и сделали разворот в две таблицы. В них пользователь может дополнительно развернуть сбоку ещё три-четыре таблицы.

Редактирование данных

Третья проблема касалась редактирования строк: пользователям было непонятно, что можно менять в данных. Мы сделали отдельную кнопку «Редактировать», клик на которую вызывает с помощью компонента Alert уведомление о том, что в данный момент строки редактируются, и дополнили кнопками «Сохранить» или «Отменить». Второй вариант был аналогичен по механике первому с тем отличием, что сама кнопка «Редактировать» размещается в редактируемой ячейке. А чтобы пользователь знал, что данные в конкретной ячейке изменены, они подсвечиваются жёлтым цветом.

Заголовки столбцов

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

Цветовые решения

Некоторые трудности возникли с цветовой индикацией на первой ДС’ке. Там были блёклые цвета, из-за чего пользователи просто не видели индикацию в силу особенностей освещения, калибровки и яркости своих экранов. Поэтому мы сделали цвета более контрастными.

Как тестировали и внедряли

Мы не зря ездили на производство и общались с людьми на этапе предварительного проектирования. Каких-то больших нареканий на стадии внедрения и тестирования таблицы не вызвали.

Все правила для своих таблиц мы разрабатывали с учётом тех условий, где они будут применяться. Смотрели, как работают пользователи, что им было удобно, а что — нет, как на всё это влияют уровень освещённости, характеристики рабочих мониторов и т. д.

По мере внедрения мы добавляли всё новые функции: улучшенные фильтры, вложенные таблицы и т. д.

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

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

Эти цвета тоже можно кастомизировать, но мы рекомендуем вот такой стандарт. Ещё мы перевели часть старых цветов для некоторых показателей в новую палитру: эти значения тоже будут кочевать из таблицы в таблицу.

Естественно, что-то мы дорабатывали уже после внедрения, когда получили обратную связь от пользователей. Например, были моменты, когда они не понимали, как настраивать таблицу, как убирать или выделять колонки. Мы всё это разъясняли и сделали обучающий экран при первом входе.

Ещё были нарекания по поводу легенды. В некоторых моментах мы её не прописывали, если пользователю это было не нужно в работе. Однако они видели, например, индикацию цвета хаки, но не понимали, что именно это значит, поэтому в таких местах мы дописывали легенду. Даже если пользователю в его работе она будет не нужна, всё равно пусть легенда покажет, что именно выделено и зачем.

Чему нас научил этот опыт

Из всей этой истории мы сделали для себя следующие выводы:

·         Универсальные готовые решения для узкоспециализированных задач не подходят: широкий функционал в какой-то степени мешает в решении производственных задач.

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

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

·         Дизайн в промышленных системах — это и про эстетику, и про функциональность. Оба этих аспекта оказались глубоко связанными друг с другом.

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

Что дальше

В планах — усовершенствовать решения для планшетных устройств и внедрить таблицы на как можно большее количество проектов. Будем собирать обратную связь и добавлять новый необходимый функционал, например, на днях пришёл запрос на выделение недавно добавленных строк в системе.

Ну и мы готовы делиться наработками — вы уже можете применять наш опыт у себя на проектах. Берите и пользуйтесь:

·         Табличный компонент в сторибук.
·         NLMK Table.
·         NLMK UI.
·         GitHub.