Интерфейс рабочего места администратора
Графический интерфейс панели администрирования вместо старой доброй командной строки понадобился нашему заказчику, чтобы упростить настройку программного продукта и снизить количество ошибок при установке и изменении параметров.
~ 850 000 ₽
Разработали графический интерфейс панели администратора.
Контекст
Результат
Бюджет
2017
Центр речевых технологий (ЦРТ) — российская компания, которая занимается разработкой систем синтеза и распознавания речи, анализа аудио- и видеоинформации, мультимодальной биометрии. Один из продуктов — система голосовой авторизации абонента. Например, для банков — чтобы узнавать клиента по голосу и проводить авторизацию для операций через телефонный банк.
С технической точки зрения, это сложная система с тремя уровнями настроек. Разворачивается она на нескольких серверах. Короче, с внедрением нужно повозиться. Занимаются этим администраторы ЦРТ через командную строку, понимающую формат JSON. Что еще нужно админу для счастья? Оказалось, что нужен графический интерфейс. Не в формате «нам хотелось бы», а в виде вполне конкретного и обоснованного запроса. Во-первых, в консоли проще сделать ошибку и сложнее отловить, во-вторых, админы в принципе не рвутся разбираться с командной строкой ради одного внедрения. За разработкой интерфейса ЦРТ пришли к нам. Мы оценили плюсы и минусы.
Подробная документация
Мы создавали интерфейс для уже существующего и подробно документированного продукта.
Не на словах, а на деле. Клиент не пропадет на пару недель, мы будем держать друг друга в ритме.
Четкий дедлайн
Это технически сложный продукт, и он требовал от проектировщика инженерного подхода, понимания, что такое администрирование и конфигурирование серверов.
Сложность системы
Это не первое обращение к поставщикам UX-услуг. Наш партнер понимает суть работы.
Опытный заказчик
Делаем для людей
Нужна только обертка под уже работающую систему. Не будет внезапного изменения вводных и вопросов, которые еще не успела обсудить команда разработчиков.
Стабильная функциональность
Изначально мы не были уверены, что сможем получить доступ к реальным пользователям (то есть администраторам).
Доступ к пользователям
Через два месяца мы уже должны отдать заказчику результат, который не стыдно показать на конференции.
Сроки
+
+
−
+
+
+
−
−
Не нужно искать компромиссные решения, которые неизбежно возникают в интерфейсах, рассчитанных на разные роли.
Одна пользовательская роль
+
Никто не ожидает в панели администратора обилия креативных и модных решений.
Разумные ожидания к эстетике
+
Дедлайн был приурочен к отраслевой выставке, где заказчик хотел поразить всех новым интерфейсом.
Ожидание wow-результата
−
Заказчик, невзирая на весь свой технический бэкграунд, умеет и хочет разговаривать про людей, а не про профессиональные роли.
Процесс
При разработке профессиональных интерфейсов аналитическая часть превращается из изучения людей в изучение документации. Про людей мы еще вспомним, конечно. А пока с участием заказчика стали вникать в систему. В помощь нам — техническое задание для программистов и инструкции для администраторов. Почитали, поговорили, осознали и описали основные задачи администратора, которые он будет выполнять с помощью нашего интерфейса.
Основные задачи администратора
Параллельно с этим думали, как организовать работу с трехуровневой структурой настроек.
- Глобальные настройки распространяются на все компоненты комплекса.
- Настройки сервисов — на все экземпляры определенного сервиса. Настройки, заданные на этом уровне, переопределяют глобальные параметры.
- Настройки экземпляра сервиса — на конкретный экземпляр сервиса.
Настройки, заданные на младшем уровне, переопределяют параметры, полученные с верхних уровней.
Вот так выглядит процесс передачи знаний из головы менеджера в голову проектировщика
Кстати, сразу видны зачатки интерфейсных решений и логики работы: подсказки, «проброс» параметров по уровням вложенности и т. д. Осталось перенести это в кликабельный эскиз, и можно обсуждать с заказчиком.
Эскиз будущей панели администрирования
Концептуально утвердили, по содержанию — долго и предметно разговаривали со всеми, до кого могли дотянуться. Вот тут и появились те самые живые пользователи — администраторы системы. Они высказали свои соображения о том, насколько наши наброски соответствуют реальной архитектуре программного комплекса и в какой мере они увязаны с задачами и привычными сценариями настройки.
Пока менеджер с проектировщиком вникали в жизнь инженеров и администраторов, аналитик не давал забыть о мирских реалиях и комментировал эскизы с точки зрения простого человека. Нет, без технического бэкграунда никто в эти настройки не полезет, но ведь сисадмин не перестает быть человеком. И заказчик получил еще одну порцию вопросов.
- Бывает ли так, что работа идет не по этим шагам? Например, что-то сокращается, или, наоборот, нужны какие-то дополнительные действия. Нельзя ли сделать какие-то шаблоны?
- Учтены ли все возможные ошибки на каждом этапе? Может быть, прописать сценарии для работы с ошибками?
- Какая информация требуется для работы на каждом из этапов? Важно, чтобы эта информация присутствовала в интерфейсе.
- Нужно ли постоянно мониторить какую-то информацию? Если сисадмин должен периодически что-то проверять, удобно вывести эти параметры на один экран.
- Где важно предусмотреть возможность перехода на ручной режим в экстренных ситуациях?
Детализируем
Теперь предстояла самая сложная и долгая часть работы — детальная проработка дизайна интерфейса. Сложная, потому что нужно вникать в документацию уже не на уровне поверхностного понимания «тут у нас три уровня вложенности и должен быть „проброс“ параметров», а вчитываясь в каждую строчку. Фактически проектировщик брал из инструкции кусок кода, вычленял оттуда аргументы и превращал в элементы интерфейса.
Интерфейс подсказывает администратору рекомендуемые параметры
Графический интерфейс, конечно, делается не красоты ради, а упрощения для. Недостаточно просто взять и запихнуть параметры в формочки и кнопочки. Уже на этапе эскизов мы продумывали решения, способные упростить работу администратора (то есть полностью оправдать переход с ламповой командной строки на GUI).
Самое сложное при настройке — учитывать наследование параметров для вложенных уровней
- В наследовании параметров легко запутаться. Мы придумали подсвечивать поля, значение в которых отличается от родительского. Серым шрифтом — значение родительского параметра и уточнение, откуда он «прокинут» (С — настройки компонента, G — глобальные настройки).
- Здесь же — пиктограммы для «прокидывания» значения на нижние уровни или, наоборот, подстановки родительского.
- Каждому параметру можно задать подсказку.
- По умолчанию показываются только основные поля настроек. Какие именно — определяют разработчики. Но, конечно, предусмотрена возможность развернуть скрытые параметры и вообще показать все поля на странице.
Все это по большому счету решает одну глобальную задачу — снизить вероятность ошибок при настройке.
Настройки группируются по компонентам или по серверам, смотря что нужно сделать администратору
- Изначально параметры сгруппированы по компонентам — именно так идет настройка. Но предусмотрена группировка и по серверам, когда нужно посмотреть, какими компонентами какая машина забита.
- В подзаголовке — краткая сводка по серверам, возле каждого сервера и компонента — пиктограмма со статусом (запущен, обновляется, остановлен).
Легенда в правом верхнем углу отражает структуру настроек
И еще несколько штрихов.
- Как вы, наверное, уже заметили, группы параметров — вложенные. В правом верхнем
углу мы добавили что-то вроде легенды, чтобы администратор мог одним взглядом оценить структуру настроек, не листая страницу вверх-вниз. Длина полоски показывает вложенность, синяя полоса — текущее место, красная — место, где есть ошибки.
- Подсветка полей — красная точка слева — указывает, какие параметры были изменены в этот сеанс работы администратора.
Вроде все хорошо, но чего-то не хватает? Ах да, настоящей айтишной брутальности.
Темная тема для админов старой школы. Скорее в шутку, чем всерьез
Это шутка, конечно. Но она наглядно демонстрирует, что цвета — штука второстепенная.
Отдельно про JSON-строку. Еще на этапе эскизов мы решили, что администратору нужно дать возможность «залезть руками в код».
От возможности администрировать систему старой доброй JSON-строкой мы в итоге отказались
В финальный прототип консоль не попала. Мы поговорили с заказчиком и выяснили, что сисадмины старой закалки (которых меньшинство) в принципе обойдутся без наших интерфейсов. Остальные же, вопреки нашим благоговейным представлениям, предпочитают кликать мышкой.
Результат
У чисто инженерной задачи получился чисто инженерный результат. Интерфейс панели администратора. Готовый к верстке — художества тут не нужны, а эстетика была заложена сразу.
Смысл
Решая инженерную задачу для инженеров, часто забывают про людей. Мы же тут все свои, мы же все разбираемся в сложных штуках, мы же не для секретарши соцсеть пилим. А если где неудобно получилось — наш брат-айтишник потерпит. Нет, не надо так. Даже если речь идет о профессиональном интерфейсе, даже если главное — соблюсти все пункты ТЗ и учесть все технические нюансы, нужно помнить о человеке. То есть отталкиваться от сценариев, продумывать мелочи, упрощающие жизнь. Тогда даже в жестких рамках получаются дружелюбные — для вполне конкретной аудитории — интерфейсы. Вот что говорит о нашей работе заказчик.
~ 850 000 ₽
Бюджет
«В целом по всем пунктам работы с вами и команда и я полностью довольны. Надеюсь, что при появлении новых проектов и мы с вами поработаем».
Дмитрий Щетинин
Руководитель управления «ЦРТ-инновации»
Графический интерфейс защищает администратора от случайных ошибок.
Результат
Другие кейсы