---
updateDate: 2026-02-05T00:00:00Z
publishDate: 2024-07-24
publishYear: 2017
name: Crt panel administratora
title: Интерфейс рабочего места администратора
excerpt: Разработали графический интерфейс панели администратора.
context: Графический интерфейс панели администрирования вместо старой доброй командной строки понадобился нашему заказчику, чтобы упростить настройку программного продукта и снизить количество ошибок при установке и изменении параметров.
logo:
src: ~/assets/images/portfolio/center-rechevyh-technologiy/logo.png
alt: Центр речевых технологий (ЦРТ) logo
link: https://www.speechpro.ru/
image: ~/assets/images/portfolio/crt-panel-administratora/crt-panel-administratora.png
imageAlt: Интерфейс рабочего места администратора
thumbnail:
src: ~/assets/images/portfolio/cards/crt.svg
alt: Собака Павлова • ЦРТ • Дизайн интерфейса рабочего места администратора
tags:
- it
- gos
- ux-design
- new-features
- prof
relatedPages:
- text: |
### Вам нужен интерфейс?
#### Заказать дизайн
Напишите нам на [we@sobakapav.ru](mailto:we@sobakapav.ru)
#### Что мы можем сделать?
[UX-дизайн под ключ](/services/ux-audit), как в этом кейсе. И [многое другое](/services).
collection: services
page: ux-design
- text: |
### Хотите уметь так же?
Научим создавать хорошие интерфейсы.
collection: promo
page: mio
- collection: promo
page: uc
relatedPages2:
- text: |
### Похожие проекты
collection: portfolio
page: pangeo
- collection: portfolio
page: alfa-arm
- collection: portfolio
page: novotelekom
- collection: portfolio
page: atol
- collection: portfolio
page: electronika
- collection: portfolio
page: alfa
- collection: portfolio
page: center-rechevyh-technologiy
- collection: portfolio
page: amber
result:
- src: ~/assets/images/portfolio/png.png
text: Финальный дизайн
link: https://drive.google.com/drive/u/1/folders/1_jklEAz00JsGyBXCr5LN9JwscnBb2CZf?ths=true
budget: ~ 850 000 ₽
review:
text: «В целом по всем пунктам работы с вами и команда и я полностью довольны. Надеюсь, что при появлении новых проектов и мы с вами поработаем».
photo: ~/assets/images/portfolio/crt-panel-administratora/person.png
person: Дмитрий Щетинин
position: Руководитель управления «ЦРТ-инновации»
director: Графический интерфейс защищает администратора от случайных ошибок.
metadata:
canonical: https://sobakapav.ru/portfolio/crt-panel-administratora
title: АРМ • Интерфейс автоматизированного рабочего места администратора
description: "Разработали профессиональный интерфейс администратора — графическую панель, которая заменит командную строку. Макеты — внутри."
robots:
index: true
follow: true
openGraph:
site_name: Собака Павлова
images:
- url: '~/assets/images/portfolio/crt-panel-administratora/crt-panel-administratora.png'
width: 1124
height: 835
---
import Image from '~/components/common/Image.astro';
import TOC from '~/components/widgets/TOC.astro';
<TOC>
[Задача](#anchor1) • [Дизайн-процесс](#anchor2) • [Детализация](#anchor3) • [Результат](#anchor4) • [Смысл](#anchor5) • [Цены и сроки](#anchor6)
</TOC>
## <a name="anchor1" />Задача
[Центр речевых технологий (ЦРТ)](https://www.speechpro.ru/) — российская компания, которая занимается разработкой систем синтеза и распознавания речи, анализа аудио- и видеоинформации, мультимодальной биометрии. Один из продуктов — [система голосовой авторизации абонента](https://www.speechpro.ru/product/sistemy-zapisi-telefonnykh-razgovorov/nezabudka-2). Например, для банков — чтобы узнавать клиента по голосу и проводить авторизацию для операций через телефонный банк.
С технической точки зрения, это сложная система с тремя уровнями настроек. Разворачивается она на нескольких серверах. Короче, с внедрением нужно повозиться. Занимаются этим администраторы ЦРТ через командную строку, понимающую [формат JSON](https://ru.wikipedia.org/wiki/JSON). Что еще нужно админу для счастья? Оказалось, что нужен графический интерфейс. Не в формате «нам хотелось бы», а в виде вполне конкретного и обоснованного запроса. Во-первых, в консоли проще сделать ошибку и сложнее отловить, во-вторых, админы в принципе не рвутся разбираться с командной строкой ради одного внедрения. За разработкой интерфейса ЦРТ пришли к нам. Мы оценили плюсы и минусы.
>+ **Подробная документация**
>Мы создавали интерфейс для уже существующего и подробно документированного продукта.
>+ **Четкий дедлайн**
>Не на словах, а на деле. Клиент не пропадет на пару недель, мы будем держать друг друга в ритме.
>+ **Опытный заказчик**
>Это не первое обращение к поставщикам UX-услуг. Наш партнер понимает суть работы.
>+ **Делаем для людей**
>Заказчик, невзирая на весь свой технический бэкграунд, умеет и хочет разговаривать про людей, а не про профессиональные роли.
>+ **Стабильная функциональность**
>Нужна только обертка под уже работающую систему. Не будет внезапного изменения вводных и вопросов, которые еще не успела обсудить команда разработчиков.
>+ **Одна пользовательская роль**
>Не нужно искать компромиссные решения, которые неизбежно возникают в интерфейсах, рассчитанных на разные роли.
>+ **Разумные ожидания к эстетике**
>Никто не ожидает в панели администратора обилия креативных и модных решений.
>- **Сложность системы**
>Это технически сложный продукт, и он требовал от проектировщика инженерного подхода, понимания, что такое администрирование и конфигурирование серверов.
>- **Доступ к пользователям**
>Изначально мы не были уверены, что сможем получить доступ к реальным пользователям (то есть администраторам).
>- **Сроки**
>Через два месяца мы уже должны отдать заказчику результат, который не стыдно показать на конференции.
>- **Ожидание wow-результата**
>Дедлайн был приурочен к отраслевой выставке, где заказчик хотел поразить всех новым интерфейсом.
## <a name="anchor1" />Дизайн-процесс
При разработке профессиональных интерфейсов аналитическая часть превращается из изучения людей в изучение документации. Про людей мы еще вспомним, конечно. А пока с участием заказчика стали вникать в систему. В помощь нам — техническое задание для программистов и инструкции для администраторов. Почитали, поговорили, осознали и описали основные задачи администратора, которые он будет выполнять с помощью нашего интерфейса.
_Основные задачи администратора_
Параллельно с этим думали, как организовать работу с трехуровневой структурой настроек.
- Глобальные настройки распространяются на все компоненты комплекса.
- Настройки сервисов — на все экземпляры определенного сервиса. Настройки, заданные на этом уровне, переопределяют глобальные параметры.
- Настройки экземпляра сервиса — на конкретный экземпляр сервиса.
Настройки, заданные на младшем уровне, переопределяют параметры, полученные с верхних уровней.
_Вот так выглядит процесс передачи знаний из головы менеджера в голову проектировщика_
Кстати, сразу видны зачатки интерфейсных решений и логики работы: подсказки, «проброс» параметров по уровням вложенности и т. д. Осталось перенести это в кликабельный эскиз, и можно обсуждать с заказчиком.
_Эскиз будущей панели администрирования_
Концептуально утвердили, по содержанию — долго и предметно разговаривали со всеми, до кого могли дотянуться. Вот тут и появились те самые живые пользователи — администраторы системы. Они высказали свои соображения о том, насколько наши наброски соответствуют реальной архитектуре программного комплекса и в какой мере они увязаны с задачами и привычными сценариями настройки.
>Use cases — пользовательские сценарии, сценарии взаимодействия, сценарии использования, пользовательские сценарии — последовательное описание поведения человека при взаимодействии с системой и системы, когда с ней взаимодействует человек. У нас есть [модуль дизайн-задачника «Сценарии взаимодействия»](https://www.eduhund.ru/program/usecases/?utm_source=sobakapav&utm_medium=site&utm_campaign=page) для тех, кто хочет научиться их использовать в дизайне интерфейсов.
Пока менеджер с проектировщиком вникали в жизнь инженеров и администраторов, аналитик не давал забыть о мирских реалиях и комментировал эскизы с точки зрения простого человека. Нет, без технического бэкграунда никто в эти настройки не полезет, но ведь сисадмин не перестает быть человеком. И заказчик получил еще одну порцию вопросов.
1. Бывает ли так, что работа идет не по этим шагам? Например, что-то сокращается, или, наоборот, нужны какие-то дополнительные действия. Нельзя ли сделать какие-то шаблоны?
2. Учтены ли все возможные ошибки на каждом этапе? Может быть, прописать сценарии для работы с ошибками?
3. Какая информация требуется для работы на каждом из этапов? Важно, чтобы эта информация присутствовала в интерфейсе.
4. Нужно ли постоянно мониторить какую-то информацию? Если сисадмин должен периодически что-то проверять, удобно вывести эти параметры на один экран.
5. Где важно предусмотреть возможность перехода на ручной режим в экстренных ситуациях?
## <a name="anchor3" />Детализация
Теперь предстояла самая сложная и долгая часть работы — детальная проработка дизайна интерфейса. Сложная, потому что нужно вникать в документацию уже не на уровне поверхностного понимания «тут у нас три уровня вложенности и должен быть „проброс“ параметров», а вчитываясь в каждую строчку. Фактически проектировщик брал из инструкции кусок кода, вычленял оттуда аргументы и превращал в элементы интерфейса.
_Интерфейс подсказывает администратору рекомендуемые параметры_
Графический интерфейс, конечно, делается не красоты ради, а упрощения для. Недостаточно просто взять и запихнуть параметры в формочки и кнопочки. Уже на этапе эскизов мы продумывали решения, способные упростить работу администратора (то есть полностью оправдать переход с ламповой командной строки на GUI).
_Самое сложное при настройке — учитывать наследование параметров для вложенных уровней_
- В наследовании параметров легко запутаться. Мы придумали подсвечивать поля, значение в которых отличается от родительского. Серым шрифтом — значение родительского параметра и уточнение, откуда он «прокинут» (С — настройки компонента, G — глобальные настройки).
- Здесь же — пиктограммы для «прокидывания» значения на нижние уровни или, наоборот, подстановки родительского.
- Каждому параметру можно задать подсказку.
- По умолчанию показываются только основные поля настроек. Какие именно — определяют разработчики. Но, конечно, предусмотрена возможность развернуть скрытые параметры и вообще показать все поля на странице.
Все это по большому счету решает одну глобальную задачу — снизить вероятность ошибок при настройке.
_Настройки группируются по компонентам или по серверам, смотря что нужно сделать администратору_
- Изначально параметры сгруппированы по компонентам — именно так идет настройка. Но предусмотрена группировка и по серверам, когда нужно посмотреть, какими компонентами какая машина забита.
- В подзаголовке — краткая сводка по серверам, возле каждого сервера и компонента — пиктограмма со статусом (запущен, обновляется, остановлен).
_Легенда в правом верхнем углу отражает структуру настроек_
И еще несколько штрихов.
- Как вы, наверное, уже заметили, группы параметров — вложенные. В правом верхнем
углу мы добавили что-то вроде легенды, чтобы администратор мог одним взглядом оценить структуру настроек, не листая страницу вверх-вниз. Длина полоски показывает вложенность, синяя полоса — текущее место, красная — место, где есть ошибки.
- Подсветка полей — красная точка слева — указывает, какие параметры были изменены в этот сеанс работы администратора.
Вроде все хорошо, но чего-то не хватает? Ах да, настоящей айтишной брутальности.
_Темная тема для админов старой школы. Скорее в шутку, чем всерьез_
Это шутка, конечно. Но она наглядно демонстрирует, что цвета — штука второстепенная.
Отдельно про JSON-строку. Еще на этапе эскизов мы решили, что администратору нужно дать возможность «залезть руками в код».
_От возможности администрировать систему старой доброй JSON-строкой мы в итоге отказались_
В финальный прототип консоль не попала. Мы поговорили с заказчиком и выяснили, что сисадмины старой закалки (которых меньшинство) в принципе обойдутся без наших интерфейсов. Остальные же, вопреки нашим благоговейным представлениям, предпочитают кликать мышкой.
## <a name="anchor4" />Результат
У чисто инженерной задачи получился чисто инженерный результат. Интерфейс панели администратора. Готовый к верстке — художества тут не нужны, а эстетика была заложена сразу.
## <a name="anchor5" />Смысл
Решая инженерную задачу для инженеров, часто забывают про людей. Мы же тут все свои, мы же все разбираемся в сложных штуках, мы же не для секретарши соцсеть пилим. А если где неудобно получилось — наш брат-айтишник потерпит. Нет, не надо так. Даже если речь идет о профессиональном интерфейсе, даже если главное — соблюсти все пункты ТЗ и учесть все технические нюансы, нужно помнить о человеке. То есть отталкиваться от сценариев, продумывать мелочи, упрощающие жизнь. Тогда даже в жестких рамках получаются дружелюбные — для вполне конкретной аудитории — интерфейсы. Вот что говорит о нашей работе заказчик.
## <a name="anchor6" />