Идея
Сделать удобный продукт для управляющих компаний и жителей, чтобы они могли и хотели общаться, с помощью нашего сервиса. Концепт создан в рамках дипломного проекта в соавторстве с одногруппницей.
Ожидания
После введения продукта на рынок мы ожидаем получить:
- Прозрачные финансовые операции и ценообразование
- Время затраченное на коммуникацию – минимальное
- Сервис и услуги более высокого уровня
- Положительные эмоции в решении бытовых и рабочих вопросов
Решение
Для полного взаимодействия между всеми участниками процесса было создано три приложения.
1
Декстопный веб-интерфейс для диспетчера.
Один из важнейших сценариев – это взаимодействие УК, собственника и работника в процессе обработки и выполнении заявки.
Задачей было решить проблему с наглядностью и прозрачностью процесса, избавить УК от работы сотрудников вне кассы и создать условия для хранения и сортировки заявок.
2
Приложение для рабочих УК
Работник может принимать заявки и оставлять комментарии диспетчеру о переносе даты или уточнению каких-то деталей.
При изменении условий выполнения заявки (покупка материалов, изменение цены) сотрудник меняет данные в заявке со своей стороны, а собственник в своем приложении подтверждает изменения.
Это позволит сделать процесс прозрачным и понятным для всех сторон.
3
Приложение для собственников
В сценарии взаимодействия собственник создает заявку и отслеживает ее статус, видит кто и когда придет выполнять услугу. Все это без необходимости звонить. С помощью уведомлений собственник будет узнавать об изменениях. Если в процессе работы происходят непредвиденные обстоятельства, собственнику необходимо дать согласие на изменения в работе, чтобы диспетчер отслеживал процесс. Так и у собственника доверия больше и ответственность сотрудника выше.
Процесс
Перед началом работы мы изучили конкурентов, почитали комментарии и поняли, что для того, чтобы распространить приложение, нам нужно создать удобный интерфейс именно для сотрудников УК. Поэтому проработке этой части работы над сервисом мы уделили наибольшее внимание.
Для начала мы определили ЦА и разделили ее на сегменты и критерии.
Персонажи
Проект рассчитан на две аудитории: B2B и В2С. Из широкой аудитории владельцев недвижимости мы выделили шесть ключевых персонажей и троих персонажей сотрудников УК.
Создание персонажей помогло выявить те проблемы, которые не могли прийти в голову сходу до начала проектирования. Например такие, как страх одинокой женщине приглашать работника себе домой, страх старшего поколения, что их обманут в интернете, как контролировать сотрудников, чтобы они не работали мимо кассы и другие.
Описание диспетчера, для которого создавался интерфейс в рамках MVP:
Цели, фичи
Описав персоны, мы определили их цели и задачи, а также продумали фичи, которые приведут к достижению цели.
MVP
Затем было необходимо определить, что мы реализуем в MVP, а что осуществим в последующих итерациях.
Мы создали таблицу, указав персоны и фичи, затем по балльной системе указали степень необходимости фичи каждой персоне. Отдельной графой шли интересы бизнеса, которые добавляли баллы. Далее мы разделили проект на релизы, иногда с удивлением обнаружив, что нашим пользователям какие-то фичи нужнее, чем нам казалось.
Сценарии
До начала создания архитектуры сервиса, мы описали сценарии, по которым наши пользователи будут решать свои задачи. С помощью этого этапа нами были продуманы еще множество необходимых фич, которые нужно включить в наш сервис.
Фрагмент сценария, который помог нам предусмотреть такие фичи, как «шаблоны заявок», «резюме сотрудника», развитие сценария контроля над заявкой «подтверждение измененной цены».
После создания архитектуры сервиса, мы перешли к рисованию user flow и созданию макетов.