---
updateDate: 2026-02-10T00:00:00Z
publishDate: 2024-08-13
publishYear: 2019
name: Novotelekom
title: Редизайн интерфейса мобильного приложения для сервисных инженеров
excerpt: Переделали UI приложения, в котором сервисные инженеры провайдера управляют заказами, настраивают подключения и ведут учет оборудования абонентов.
context: Приложением пользовались сервисные инженеры регионального филиала «Дом.ру», но главный офис решил переделать его и внедрить в федеральную сеть.
logo:
src: ~/assets/images/portfolio/novotelekom/logo.png
alt: Электронный город logo
link: https://2090000.ru/
image: ~/assets/images/portfolio/novotelekom/novotelekom.png
imageAlt: Редизайн интерфейса мобильного приложения для сервисных инженеров
thumbnail:
src: ~/assets/images/portfolio/cards/ecity-pril.svg
src2: ~/assets/images/portfolio/cards-l/ecity-pril_big.svg
alt: Собака Павлова • Электронный город • Редизайн мобильного приложения для сервисных инженеров
isDark: true
doubleSize: true
tags:
- telecom
- ui-redesign
- ux-outsource
- prof
- mob
- ecity
relatedPages:
- text: |
### Вам нужен интерфейс?
#### Заказать дизайн
Напишите нам на [we@sobakapav.ru](mailto:we@sobakapav.ru)
#### Что мы можем сделать?
[UX-дизайн](/ux-design) и [продуктовые исследования](/ux-researches), независимо или [на аутсорсе](/ux-outstaff).
collection: services
page: ui-redesign
- text: |
### Хотите уметь так же?
Научим создавать хорошие интерфейсы.
collection: promo
page: mio
- collection: promo
page: uc
relatedPages2:
- text: |
### Похожие проекты
collection: portfolio
page: e-gorod-mobile
- collection: portfolio
page: e-gorod
- collection: portfolio
page: e-gorod-guide
- collection: portfolio
page: stream-telecom
- collection: portfolio
page: fastvps
- collection: portfolio
page: yota
result:
- text: Убрали из публичного доступа
budget: ~ 1 500 000 ₽
review:
text: Спасибо большое Собаке Павловой за работу, разработали отличный дизайн раньше оговоренного срока. Сотрудники большие профессионалы своего дела. Очень благодарен за помощь в создании моего приложения =)
photo: ~/assets/images/portfolio/novotelekom/person.png
person: Бондаренко Иван,
position: руководитель проекта, управление технической поддержки абонентов
director: Сделали интерфейс для инженеров — выиграли и абоненты, и вся компания «Дом.ру»
metadata:
canonical: https://sobakapav.ru/portfolio/novotelekom
title: Мобильный интерфейс • Приложение для сервисных инженеров
description: "Провели UI-редизайн профессионального мобильного приложения — упростили интерфейс для монтажников и сервисных инженеров провайдера."
robots:
index: true
follow: true
openGraph:
site_name: Собака Павлова
images:
- url: '~/assets/images/portfolio/novotelekom/novotelekom.png'
width: 1968
height: 2244
---
import TOC from '~/components/widgets/TOC.astro';
<TOC>
[Зказчик](#anchor1) • [Бизнес-задача](#anchor2) • [Дизайн-задачи](#anchor3) • [UX-исследование](#anchor4) • [Дизайн-процесс](#anchor5) • [Дизайн интерфейса](#anchor6) • [Веб-интерфейс](#anchor7) • [Результат](#anchor8) • [Отзыв, цены, сроки](#anchor9)
</TOC>
## <a name="anchor1" />Заказчик
[«Электронный город»](https://2090000.ru/) — самый крупный новосибирский телеком-оператор. Недавно он вошел в состав федерального гиганта «Дом.ру».
Мы с ним работали уже не раз и не два — делали [сайт](https://sobakapav.ru/portfolio/e-gorod), [блог](https://blog.2090000.ru/), [интерфейс личного кабинета пользователя](https://sobakapav.ru/publications/how-ux-writer-helps-to-improve-the-product) и [гайд для сотрудников поддержки](https://sobakapav.ru/portfolio/e-gorod-guide).
Именно поэтому «Электронный город» и сильный бренд. Не из-за нас, конечно, а потому что в команде провайдера работают настоящие визионеры. Много ли региональных провайдеров занимаются контент-маркетингом, создают гайды публичного общения для сотрудников, с 2015 года предоставляют технологии умного дома и разрабатывают мобильные приложения? То-то же.
## <a name="anchor2" />Бизнес-задача
Та же команда сделала внутреннее приложение для сервисных инженеров — это люди, которые ходят по квартирам абонентов, проводят интернет и телевидение, все чинят и настраивают. Этакая CRM в кармане, где все заявки.
Приложение называется «РМСИ ЭРТХ». Расшифровывается, как «Рабочее место сервисного инженера компании "Эр-Телеком Холдинг"».
## <a name="anchor3" />Дизайн-задача
Переделали UI приложения, в котором сервисные инженеры провайдера управляют заказами, настраивают подключения и ведут учет оборудования абонентов.
context: Приложением пользовались сервисные инженеры регионального филиала «Дом.ру», но главный офис решил переделать его и внедрить в федеральную сеть.
## <a name="anchor4" />UX-исследование
С чего начать переделывать интерфейс? Заказчик вместо вводных дал нам пользовательскую инструкцию. Без нее в интерфейсе не разобраться — настолько сложное приложение. Эту инструкцию изучают все сервисные инженеры, после чего сдают экзамен на владение приложением. И это не прихоть компании — специалист должен пользоваться софтом каждый день, это его рабочий кабинет.
_Так выглядело приложение до редизайна_
Пока читали инструкцию, готовили список вопросов для разработчиков. Здесь так и должно быть? А это вот как работает? А почему здесь сделали не так, а эдак?
После изучения инструкции мы сели за аналитику. Для начала провели два интервью с пользователями. Оказалось, у них никаких проблем с приложением нет — это логично, они же сдавали экзамен по интерфейсу. Но это только на словах: «Мы работаем и во всем разобрались». А в целом интервью показало, где пользователям неудобно, что могло бы работать быстрее и где чего не хватает.
Изучили инструкцию, поговорили с пользователями и… Не смогли разобраться, как устроено приложение. Сколько мы ни разглядывали интерфейсы, понятнее не становилось. Тогда заказчик скинул установщик приложения для Android с уже вшитыми внутрь данными. Мы попробовали пройти сценарии, которые выявили во время изучения инструкции и интервью, — и все равно не справились. Действительно сложный профессиональный интерфейс.
>Use cases — пользовательские сценарии, сценарии взаимодействия, сценарии использования, пользовательские сценарии — последовательное описание поведения человека при взаимодействии с системой и системы, когда с ней взаимодействует человек. У нас есть [модуль дизайн-задачника «Сценарии взаимодействия»](https://www.eduhund.ru/program/usecases/?utm_source=sobakapav&utm_medium=site&utm_campaign=page) для тех, кто хочет научиться их использовать в дизайне интерфейсов.
Тогда мы задокументировали логику работы приложения и основные сценарии вместе с заказчиком. С этим уже можно начинать работать.
_Легких путей не бывает_
## <a name="anchor5" />Дизайн-процесс
Мы не стали глубоко зарываться в аналитику и быстро приступили к дизайну.
На концептуальном этапе набросали шесть версий дизайна.
_Концепты отличались несильно. В основном — цветами и навигацией_
Дизайн готовили сразу под Android, потому что почти все рабочие смартфоны работают на этой ОС. Нас консультировал разработчик «Электронного города», который и создал это приложение. Позже, уже под конец проекта, компания наняла еще и iOS-разработчика, раз уж софтом будут пользоваться инженеры по всей России.
_Подбираем акцентные цвета в приложении_
Мы с самого начала взяли бодрый темп: делали по одному сценарию со всеми экранами и дважды в неделю созванивались с командой заказчика. Android-разработчик комментировал внешний вид и логику приложения. А менеджер, который в принципе и был идейным вдохновителем проекта, объяснял, что должно быть и в каком виде. Мы быстро вносили правки, передавали дизайн разработчику и переходили к следующему сценарию.
Через три недели такого темпа мы разделили проект на две части. Один дизайнер продолжил делать приложение, другой — веб-часть, в которой тимлид управляет работой инженеров. Раз в неделю мы обсуждали, как их синхронизировать. Не то чтобы это было сложно, скорее для порядка.
Так мы и дошли до финала проекта: прорабатывали один сценарий за другим, созванивались с заказчиком дважды в неделю, обсуждали результаты, доделывали и передавали разработчикам. Менеджер «Электронного города» отлично представлял, что должно получиться, поэтому никаких задержек или недопонимания не было.
И вот что получилось.
## <a name="anchor6" />Дизайн интерфейса
Как только инженер открывает приложение, он попадает в раздел с заказами. Список заказов — это и есть расписание его рабочего дня.
В приложении можно смотреть расписание на три следующих дня. Дальше — нельзя, потому что список часто обновляется. Так, если кто-то из абонентов за эти три дня сам решит проблемы с настройкой роутера, заказ исчезнет.
В карточке заказа инженер может посмотреть, во сколько, куда и к кому ему нужно приехать, что из оборудования с собой взять и какие задания, они же тикеты, выполнить. К примеру, подключение интернета может включать настройку роутера, цифрового ТВ и прокладку кабелей по квартире. Каждый тикет оплачивается отдельно.
Инженер может выбирать заказы сам — они лежат свободными в соседнем разделе. Каждый берет, что ему по душе. Еще заказы может раздавать тимлид — повесит на инженера, и все. Не отвертишься.
_Внутри расписания есть фильтры. Так, инженер может посмотреть, сколько у него сегодня заказов на конкретной улице. Если несколько, но в разное время, почему бы не договориться с абонентами подойти пораньше, чтобы не мотаться туда-сюда с оборудованием?_
До нас расписание выглядело скромнее.
_Скриншот старого интерфейса из пользовательской инструкции. Если нажать на стрелку в черном кружочке, выпадет список тикетов_
Список заказов можно посмотреть и в виде календаря. Они формируют таймлайн, на котором видно, когда нужно работать, а когда можно пойти на обед. По сути то же расписание рабочего дня, только без подробностей.
_Мы не стали изобретать какой-то особенный календарь для инженеров. Взяли обычный гугловский_
В расписании видно список заказов. Если кликнуть по любому заказу, появится всплывающее окно с деталями и тикетами. Но иногда этого мало. Инженер может нажать на надпись «В заказ» в шапке — тогда он попадет на отдельную страницу со всеми подробностями.
_Все тикеты заказа видны сразу_
В прошлой версии страница заказа выглядела так. Третью вкладку вместо «Комментариев» занимала «Диагностика». Мы ее вынесли во вкладку «Заказ».
_В предыдущей версии тикеты нельзя было посмотреть на странице заказа_
Иногда инженеру, настраивающему интернет, нужно выполнить диагностику. Он может это сделать прямо из приложения. Достаточно указать адрес, выбрать подходящие настройки и нажать кнопку. Подключаться к Wi-Fi абонента для этого необязательно — приложение по обычному интернету от мобильного оператора подключается к внутренней системе «Электронного города», а та уже все делает сама.
_Инженер может отметить порты как занятые, свободные или неисправные. Другой инженер, которому через какое-то время достанется заказ на том же адресе, увидит пометки коллеги_
В информацию о заказе автоматически подтягивается и информация об абоненте. Инженер может посмотреть, как зовут клиента компании, его телефон, доступы, баланс, подписки и какое оборудование он использует.
_Не все люди помнят доступы от своих учетных записей. А вот «Электронный город» помнит и хранит — на случай, если абонент забудет_
После того как инженер выполнил работы по заказу, он должен закрыть заказ. Для этого нужно закрыть каждый относящийся к заказу тикет.
В заказе, изображенном ниже, три тикета. По каждому инженер должен отчитаться: провел он работу или нет, какое оборудование установил. Это могут быть роутер, кабель, ТВ-приставка — все что угодно. Оборудование закреплено за инженером, и, если он оставляет какое-то устройство у абонента, он отчитывается за него в форме закрытия тикета.
_Инженер может и не проводить работы по тикету. К примеру, абоненту не успели привезти из Китая телевизор со смарт-ТВ, а он уже заказал подключение и настройку_
Когда инженер закроет все тикеты, он может закрыть и заказ.
_К заказу можно оставить комментарий для других инженеров. Например, где брать ключи от чердака, чтобы добраться до оборудования компании_
Выполнить заказ — основной сценарий приложения. И самый большой. Выглядит он так.
_Нет, инженер не должен пройтись по каждому экрану. Здесь собраны и экраны, и их состояния_
Некоторые заказы назначает тимлид, но большая часть — в свободном доступе. Каждый инженер может выбрать, что ему больше нравится: подключение абонента или снятие оборудования, приемка МЕ или переключение сети. Исключение — аварии. Инженеры должны реагировать на них в первую очередь.
_Лента свободных заказов выглядит как расписание, но каждый помечен зеленым текстом «Свободен»_
В приложении есть карта, которая показывает инженеру, где географически находятся его клиенты, свободные заказы и коллеги по работе. Это удобно, когда есть окно в расписании, — можно взять сразу несколько объектов в одном районе, чтобы не мотаться по городу. Или найти коллегу и попросить его подменить тебя.
_На карте можно выбрать несколько объектов и проложить маршрут_
Во время интервью инженеры рассказали, что общаются между собой в мессенджерах. И им так удобно. Но мы все равно сделали чат — общий для всех сервисных инженеров. Если в компанию устроится новый сотрудник, ему не придется добавлять каждого коллегу в контакты. Еще чат показывает, где произошла авария или отключилась сеть.
_В чатах можно создавать группы на несколько человек — иногда, чтобы устранить аварию, одного инженера недостаточно_
В форме поиска инженер может искать заказы, абонентов и здания. Приложение выдает результат в виде карточек. Так, если вбить в поиск конкретный адрес, можно посмотреть, какие услуги «Электронный город» оказывает в этом доме, много ли абонентов подключено, сколько подъездов, этажей и квартир, где находится оборудование компании — все, что нужно для инженера. Если какого-то поля не хватает, есть форма для комментариев.
_Прежде чем выехать на заказ, инженер может посмотреть всю информацию о здании и абоненте_
В приложении инженер может посмотреть свой рейтинг, сколько работ по плану он уже выполнил и какую часть отпуска отгулял.
_В «Электронном городе» есть внутреннее обучение. Так, инженер может бесплатно прокачать навыки менеджера по продажам или изучить программирование на Python_
Возможно, вы заметили желтый ярлык в нижнем правом углу экрана. Если кликнуть по нему, появится консоль. Она записывает все действия оператора.
_Иногда работы бывает так много, что невозможно вспомнить, что ты делал неделю назад. Например, переносил оборудование или нет? Для таких ситуаций есть консоль_
## <a name="anchor7" />Веб-интерфейс
Командой сервисных инженеров управляет тимлид. Он сидит в офисе и не выезжает на заказы. Его рабочее место — компьютер.
В веб-интерфейсе тимлид может управлять расписанием команды, самой командой и графиком работы инженеров.
Для раздела «Расписание» мы подготовили два варианта интерфейса: горизонтальный и вертикальный.
_В верхней части, где указано время, серо-синий график показывает загрузку команды_
Если кликнуть по заказу, справа появится та же самая информация, что и в приложении у инженера.
_В верхней части, где указано время, серо-синий график показывает загрузку команды_
Для свободных заказов мы сделали канбан-доску. Они не привязаны к конкретному времени, только к дате, потому что их пока никто не взял в работу.
_Если заказ никто не взял, тимлид поручит его одному из инженеров_
«Дом.ру» — федеральная компания, и в каждом регионе инженеры работают по-разному. У кого-то пятидневка, у кого-то график «три через три». Мы учли и это.
Тимлид может сделать индивидуальное расписание для каждого инженера.
_Инженер может взять отпуск на две недели, а может и на пару дней_
Если кто-то неожиданно заболеет или уйдет в отпуск, тимлид сможет передать его работу другому инженеру — просто скопировав расписание. Делается это буквально в пару кликов.
_Расписание — это не только список заказов, но еще и график работы. Если несколько инженеров уйдут на больничный, в работе может образоваться окно, когда компании будет не хватать специалистов. Поэтому тимлид копирует именно расписание, а не заказы_
На карте зеленым цветом выделены свободные заказы, красным — занятые, синим — находящиеся в работе. Инженеры показаны фотографиями в кружочке. Тимлид может посмотреть, где находится каждый инженер, его маршрут и расписание.
## <a name="anchor8" />Результат
В этом проекте мы не трогали UX, только UI. И этого оказалось достаточно. Как мы уже говорили выше, в «Электронном городе» работает сильная команда, и знаний о своих продуктах у них хватает. А такие специфические компетенции, как дизайн интерфейсов, они не наращивают — заказывают на стороне. Выходит проще и дешевле.
«Электронный город» обратился к нам в июне, а уже в августе принял финальный дизайн. И сам тоже не сидел сложа руки. Как только получил первый сценарий, принялся переделывать приложение. А в октябре, через два месяца после завершения дизайна, выпустил приложение в Google Play.
## <a name="anchor9" />