Привет! Меня зовут Саша Чистова, я дизайнер студии pinkman. Сегодня расскажу, как мы создавали внутренний интерфейс для пользователей большой корпорации, которые большую часть жизни работали в Excel и HR ERP.
Отступление про внутренние продукты
Для лучшего понимания давайте взглянем на особенности формирования внутренних продуктов в компаниях.
На первых этапах развития, когда штат сотрудников невелик, многие процессы создаются «на коленке». В таких случаях предприятия используют общедоступные инструменты для организации рабочего пространства, такие как Excel или Notion.
С ростом компании, увеличением бюджета и установлением сложной структуры, предприятия переходят на готовые B2B-решения — например, SAP или Atlassian. Такие инструменты обычно ориентированы на потребности крупного бизнеса и предоставляют достаточное пространство для гибкости, чтобы адаптироваться под кастомные процессы. Но их настройка — это длительный и сложный процесс, требующий значительных ресурсов. Поэтому компании обращаются к разработке внутренних продуктов.
Вводные
Мы работаем над внутренним продуктом, который специализируется на управлении ресурсами для большой корпорации в области ритейла.
Осенью 2021 года к нам пришел запрос на создание интерфейса для управления штатным расписанием*. На тот момент оно представляло собой громоздкую таблицу в Excel с 185 столбцами, которую активно использовал отдел из 8-10 человек. 75% данных таблицы экспортировалось из другой ERP системы, а затем файл дополняли информацией, которую было невозможно вести в этой системе.
Наша основная задача была в создании единого цифрового следа. Помимо этого были и другие цели:
- обеспечить единую историю данных;
- сократить время работы с файлом, избавившись от ручного обновления информации;
- минимизировать количество ошибок, вызванных человеческим фактором.
Как разбирались в задаче
Для начала мы совместно с бизнес-аналитиком провели несколько установочных встреч, на которых внимательно изучили, как сотрудники взаимодействуют со штатным расписанием и какие повседневные задачи они там выполняют. Некоторые из основных и регулярных задач, которые мы выявили:
- оценка возможности ввода новых позиций, внутренних переводов и организационных перестановок;
- расчет финансовых прогнозов и управление персоналом для достижения финансовых метрик;
- актуализация состава сотрудников.
В ходе обсуждений также выяснилось, что каждой из этих задач занимаются разные сотрудники. Интересная особенность — несмотря на наличие отдельных ролей для каждой задачи в отделе, сотрудники взаимозаменяемы и ведут работу в едином файле. Помимо регулярных, существует ряд точечных задач, с которыми сталкиваются сотрудники ежедневно.
Соответственно, разбить таблицу на несколько разделов в соответствии с задачами и ролями не получилось бы. Нужно было разработать гибкий инструмент, способный учитывать все аспекты работы сразу для всех пользователей.
Первая концепция
В первом подходе мы решили полностью пересмотреть инструмент и отказаться от таблицы. Мы рассматривали таблицу как вынужденное решение, обусловленное особенностями Excel, и считали его использование слишком сложным. Вместо этого мы представили штатное расписание в форме «галереи» должностей, где каждая представлена карточкой, удобно сгруппированной согласно оргструктуре компании. Внутри карточек поместили все существующие атрибуты.
Учитывая, что часть данных в таблице регулярно обновляется из ERP HR-системы, мы также предложили избавиться от ручного труда и автоматизировать процесс. Для этого предложили настроить интеграцию с ERP HR и обновлять данные автоматически каждый день, что избавило бы сотрудников от необходимости ежемесячно обновлять файл вручную через Excel.
Затем мы собрали кликабельный прототип и с аналитиками пошли к пользователям для сбора обратной связи. Из исследования стало понятно, что есть еще одна сложность — в привычках пользователей, сложившихся за годы использования Excel. Полное изменение данных запутывало их, они не могли быстро найти нужные атрибуты и инструменты. Это, в свою очередь, создавало риск замедления рабочих процессов.
Чтобы избежать этого, мы с командой продукта решили постепенно внедрять новый инструмент: в качестве MVP оставить привычный вид таблицы и шаг за шагом внедрять новые механики и функции.
Вторая концепция
После определения рабочего вектора концепта, нам предстояло работать над техническими ограничениями и улучшением пользовательского опыта работы с таблицей.
Во-первых, мы должны были уменьшить таблицу, потому что компонент таблицы не был адаптирован для большого числа столбцов, что замедляло загрузку страницы. Во-вторых, важно было учесть контекст использования, избегая радикальных изменений и опираясь на текущие возможности продукта.
1. Первые 32 столбца таблицы представляли собой уровни оргструктуры, которые использовались для фильтрации. Поэтому мы преобразили столбы в боковой фильтр-древо по оргструктуре.
2. Также мы обнаружили 24 столбца по месяцам со значениями от 0 до 1, напоминающие два календаря. Нам понадобилось провести 3 встречи, чтобы понять, для чего каждый из них используется:
- Первый «календарь» (или Расчетный план численности) использовался как отображение дат ввода и вывода позиции. Такой вид сложился исторически и со временем утратил необходимость, поэтому мы решили заменить его на 2 столбца «дата открытия» и «дата закрытия»;
- Второй «календарь» (или Бюджетный план численности) отражал объем работ, выполняемых сотрудником ежемесячно. Например, если человек работал на полную ставку в мае, в соответствующий столбец ставили значение 1. Эти данные обычно заполнялись при создании позиции и редко изменялись. Поэтому мы решили удалить эти столбцы из основной таблицы, поместив их на страницу должности, и создали отдельную таблицу для массовой работы с этими данными.
3. Затем мы рассмотрели 7 блоков таблицы, каждый из которых состоял из 12 столбцов по месяцам, образуя в общей сложности 84 столбца. Каждый из них содержал какую-то из статей затрат (например, оклад или премия), разбитых по месяцам. Данные рассчитывались автоматически и зависели от значений, внесенных в Бюджетный план численности.
Мы выяснили, что этими данными занимались другие сотрудники, а для работы со Штатным расписанием эти данные не требовались. Поэтому вынесли эту часть в отдельный инструмент.
4. Кроме того, в таблице было еще 6 столбцов для заметок. Здесь мы выявили точечную боль — сотрудники часто пропускают эти заметки, потому что они сливаются с остальным массивом данных. Поэтому мы преобразовали шесть столбцов в два:
a) закрепленный при скролле столбец с комментариями, который включал в себя индикацию прочтения для каждого пользователя;
b) столбец с цветными тегами.
Помимо сокращения размера таблицы, предложили несколько решений для более удобной работы с инструментом:
- Мы упростили навигацию в большом количестве столбцов, разделив их на блоки по темам. Теперь можно скрывать ненужные блоки, когда они не используются при выполнении конкретной задачи.
- Так как разные сотрудники выполняют разные задачи с одними данными, мы добавили возможность настройки таблицы по своему усмотрению. Теперь можно скрывать, раскрывать и перетаскивать столбцы, а также сохранять свои предпочтения в виде кастомной таблицы.
- Для обогащения Штатного расписания данными через нашу систему было важно добавить возможность редактирования данных. Учитывая большой объем данных в таблице (предполагалось около 5000 строк), редактирование ячеек могло негативно сказаться на производительности. Мы перенесли настройку и редактирование данных в сайдпейдж. Таким образом мы выделили отдельную рабочую область для пользователя и не перегружаем систему, оставляя таблицу нередактируемой.
- Для создания цифрового следа разработали гибкий компонент истории изменений, который теперь команда использует и во многих других разделах и даже продуктах.
В ходе второй итерации мы провели значительное улучшение, сократив объем таблицы со 185 до 56 столбцов, после чего передали инструмент в разработку. Хотя процесс полного перехода сотрудников из Excel в наш продукт занял около полугода, результаты оказались впечатляющими — команда получила много положительной обратной связи.
Сейчас мы с командой продолжаем активно выявлять точки роста и ожидаем выработки пользовательских паттернов, чтобы плавно перейти к следующему этапу развития инструмента.
Подводим итоги: Как разрабатывать крутые интерфейсные решения для пользователей с определенными пользовательскими паттернами
Создавая любое решение, будь то мелкая доработка или создание концепции нового инструмента, очень важно погрузиться в контекст как можно более глубоко. У каждого дизайнера, выступающего в роли пользователя какого-либо сервиса, когда-то была мысль «вот я бы тут порядок навел».
Так и пользователи — дай им наши возможности и умения, они бы сделали для себя идеальный интерфейс. Поэтому постарайтесь погрузиться в задачу так, чтобы вы сами могли ее решить. Даже если вам кажется, что решение лежит на поверхности.
Инновации это круто, однако важно подавать их постепенно. Избегайте резких изменений, когда речь идет о трансформации уже существующих процессов. Учитывайте устоявшиеся пользовательские паттерны и давайте людям время на адаптацию, чтобы сохранить эффективность рабочих процессов.
Помните, что хороший дизайн тот, который решает проблемы, а не создает их.
Больше полезного и красивого у нас в телеграме.
