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