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