Привет, Хабр! Меня зовут Ксения Ершова. Я работаю UX-проектировщиком облачных баз данных в Selectel. В этой статье я подробнее расскажу, почему минималистичный подход в инженерных продуктах ошибочен и покажу на своем кейсе, почему прозрачность важнее всего. Заглядывайте под кат!
Бытует мнение: если интерфейс перегружен, единственный способ его сделать удобным — это сделать минималистичным. Возможно, в каких-то кейсах это действительно так, но на моем опыте в сложных инженерных продуктах это так работать не будет. Хотя принято считать, что для инженеров интерфейс обычно выглядит, как визуализация слов — перегруженный и нет воздуха.
Показывать(,) нельзя(,) прятать
Прозрачность в интерфейсе — это когда пользователь с легкостью может найти информацию, которая влияет на принятие решений. Такая характеристика особенно значима в продуктах, где инженер работает не с визуальными объектами, а с распределенными системами, статусами, конфигурациями и последствиями, которые могут стоить денег, SLA и сна.
Прозрачность создает предсказуемость. Предсказуемость создает доверие. Доверие — основа UX инженерных продуктов.
Когда я училась в университете и решала продуктовые кейсы, в референсах находила лаконичные интерфейсы. Здесь минимум текста и схем, только самое важное. Их часто добавляют в подборки «как надо».
Насмотренность формируется и через работу с презентациями. Помните, нам рекомендовали делать их полупустыми, оставлять только основные тезисы? Никто не хочет перегрузить внимание слушателя или зрителя. И это валидный подход. Но только до тех пор, пока ты не столкнешься с чем-то действительно сложным и нетривиальным.
Если просто взять и перенести по учебнику минималистичный интерфейс в сложный инженерный продукт, пользователь вынужден будет постоянно открывать вспомогательные элементы, чтобы восстановить контекст. Будет ли красиво? Да. Неудобно? Тоже да. И хорошо, если вспомогательные элементы вообще окажутся в интерфейсе. Бывает, что их нет, как и ссылок на документацию.
Минимализм хорошо работает, когда контекст известен. В инженерных системах он меняется от сервиса к сервису.
Пример из жизни
Мы в облачных базах данных тоже показывали клиентам только самое нужное. Если пользователь заказывал кластер БД с 20 нодами, отображали кластер, а ноды прятали в какой-нибудь из вкладок, чтобы не было громоздко.
Но есть нюанс: инженерные интерфейсы — не место для отдыха от визуального шума. Специалист, который взаимодействует с техническим продуктом, приходит за данными. Если он не находит нужной информации или тратит на это много времени, то ни о каком наслаждении визуалом уже речи не идет. Возникают вопросы:
а где посмотреть нагрузку?
почему я не вижу статусы нод?
да где же найти этот параметр?!
В данном кейсе минималистичный интерфейс не делает систему проще. Он запутает пользователя, а этого нам не нужно.
Как я перестала бояться плотно заполненных интерфейсов
Чем дольше и больше я взаимодействовала с пользователями баз данных и изучала облако, тем чаще приходила к мысли, что задача продуктового дизайнера в инженерном продукте — показать все, что может пригодиться. Когда что-то непонятно — помочь. Само собой, не забываем стандартные «удобно, юзер-френдли, интуитивно», но в инженерных продуктах эти слова означают не пустоту, а структурированность.
Инженеры мыслят моделями системы. Иногда красивый, но не структурированный интерфейс убирает часть модели «куда-нибудь под стрелочку», а в критической ситуации эта часть, будучи на виду, могла бы сэкономить человеку время и нервы. Лучше потратить больше пикселей, чем рабочих часов пользователя.
Облачные базы данных
Создайте готовую базу данных в облаке за 5 минут. Поддерживаем PostgreSQL, MySQL, Redis и не только.
Как переделывали список
Так выглядели облачные базы данных, когда я пришла на практику в Selectel. Как и говорила — только самое нужное.
Пользователи жаловались, что список объектов неинформативен. Было бы слишком просто, если бы нам заодно сказали, что именно нужно добавить. Поэтому необходимо было провести исследование.
Респондентами были сотрудники Selectel, у которых есть опыт взаимодействия с облачными базами данных в рамках задач или pet-проектов. Например, DevOps, техподдержка и тестировщики.
Так как мой опыт работы с базами данных был примерно равен нулю, пришлось сначала разобраться, какие характеристики мы технически можем показать. Я составила пару табличек, выбрала параметры, которые присутствуют у всех СУБД.
Затем эти параметры были помещены в опрос. Он состоял из кейса, который является одним из user story использования сервиса. Например:
«Произошла ситуация с одной из множества баз данных. Ты пока не понимаешь, что случилось: сеть, нагрузка или что-то еще. Ты приходишь в список БД. Какие параметры помогут понять, что из объектов стоит проверить первым?».
Респонденты приоритизировали параметры следующим образом:
В результате было решено добавить в интерфейс параметры:
имя кластера,
регион/пул,
тип СУБД,
статус,
конфигурацию,
количество реплик,
количество баз данных в кластере.
Дополнительно провели интервью: инженеры рассказывали, какие данные они обычно проверяют первыми, какие — в разрезе инцидентов, и какие — для регулярной эксплуатации.
Ответы обработаны, интерфейс спроектирован, провалидирован. Можно идти спать? Да, но недолго.
Он пришел и все сломалось
Все было отлично до того самого дня, пока не пришло время адаптировать таблицу для нового типа СУБД — OpenSearch. Здесь вся логика поехала.
У OpenSearch те же параметры, что и у других СУБД (кроме количества баз), но есть и новые — группы нод. Их необходимо показывать в листинге, потому что это ключевая информация о работоспособности кластера.
Очень не хотелось раздувать таблицу и показывать вместо одной группы нод две, а то и десять, у каждой из которых:
своя конфигурация,
свое количество нод,
своя занятость диска.
Поэтому все было спрятано в маленькую цифру со стрелкой. В комментариях попробуйте догадаться, что хотел сказать автор этой конструкцией :)
Выезжаем из таблиц
Спустя время появился паттерн демонстрации объектов в списке в формате карточек, а компонент, скрывающий информацию, мы обозначили антипаттерном и убрали. Это стало новым витком в работе над списком кластеров баз данных.
На этот раз было решено ничего не скрывать. Нужен ID кластера? Пожалуйста. Нужны все статусы групп нод? Хоть десять.
В сравнении с таблицей нет информации только об IOPS, а все остальные параметры отображаются. Выглядит ли интерфейс перегруженным и сложным? Нет, и это не может не радовать.
Про минималистов тоже не забыли: предусмотрели компактный вид.
Фото моего коллеги DevOps, который теперь видит ID кластеров и все статусы:
Итого
Я решила рассказать об этом кейсе, потому что он изменил мое отношение к работе. Раньше я искренне считала, что моя работа — прибраться, выкинуть лишнее, по моему скромному мнению, и оставить белый лист.
Сейчас я считаю, что цель дизайнера инженерного продукта — не сократить информацию, а структурировать ее таким образом, чтобы инженер мог принимать решения быстрее. И если для этого интерфейс будет выглядеть «плотным», это нормально. Плотность не равно сложность. Плотность иногда — это экономия времени других людей. Забота ❤️
