Всем привет. Меня зовут Андрей, я джуниор-дизайнер и пока что в поиске работы. Сегодня хотел рассказать вам о своем концепте приложения для жильцов дома, созданном для упрощения общения с управляющей компанией.
Я не проверял, есть ли уже такого рода приложения, поэтому начал разработку интерфейса, положившись на свой опыт и свои пожелания. Соответсвенно, у меня не было референсов и не было возможности произвести анализ конкурентов.
Проблема
Проблема заключалась в том, что иногда я не мог дозвониться до УК для решения каких-либо вопросов, связанных с моим ЖК. Если отключался свет, его телефон надрывался от звонков всех жильцов по поводу света, и мне, например, по абсолютно другой проблеме было до них просто не дозвониться.
Решение
Я подумал, что большинство проблем не требуют разговора с оператором колл-центра: вещи, связанные с уборкой, ремонтом или установкой, можно решить, не затрагивая оператора.
Соответственно, я решил исключить ненужное время для разговора по телефону и разработать приложение, в котором можно максимально быстро оставлять заявки, удобно отслеживать новости своего ЖК и в целом района.
Wireframing
Я начал накидывать функциональность, которую хочу видеть, и попутно общался со знакомыми и анализировал их потребности и запросы. На основе всего этого я начал рисовать примерный прототип и пытаться грамотно уместить все функции.
Имея на руках нужные мне функции и примерное расположение элементов дизайна, я начал создавать user flow и накидать разные сценарии, чтобы понять, как со всем этим взаимодействовать.
Отрисовка экранов
Получив какой-никакой UX, я перешел к UI.
На первом экране нас встречают новости нашего ЖК (туда входят и в целом новости района, которые напрямую касаются нашего дома, и других ЖК поблизости).
- Первый экран — новости. Они всегда встречают пользователя при первом открытии приложения.
- Второй экран — профиль.
- Третий экран — моя УК.
По центру экрана, внизу, всегда находится кнопка для начала оформления быстрой заявки (уже после начала оформления заявки, она выступает в роли кнопки отмены, «+» превращается в «х»)
По нажатию появляются основные пункты, которые я задумывал в такого рода приложении.
К слову, о тестировании. Без девушек у меня не появилось бы пункта вызвать мастера, потому что, как оказалось, не все девушки компетентны в специальностях и в поломках. Поэтому в заявке нужно будет всегда описывать свою проблему, и УК уже самостоятельно определит род проблемы и направит нужного мастера
Так вот, после выбора мастера нас встречает форма подтверждения личных данных: если в квартире проживают два человека, можно было бы менять данные, так как там будут указаны телефон для связи и ФИО жильца.
После подтверждения мы выбираем время, когда хотим, чтобы пришел мастер, и оставляем комментарий для УК. Это обязательно, ведь проблема может быть не только у вас, но в целой парадной. В таком случае после оформления заявки с вами свяжется УК и сообщит о дальнейших действиях.
После нас встречает надпись, что заявка оформлена. Посмотреть заявку мы можем в истории заявок. Также там мы можем ее либо отменить (либо опять активировать после отмены), либо оставить отзыв или удалить после ее выполнения.
Проверка
По моему мнению, данная фича очень интересна и очень практична.
Чтобы УК была уверена в своих сотрудниках, у пользователя в истории заявок у активной заявки есть кнопка «Проблема решена».
Нажав ее, пользователь получает QR-код, который должен отсканировать мастер. Только в этом случае заявка будет закрыта.
Пока ваша заявка не будет отработана на 100%, вы не должны показывать этот код мастеру. Без этого QR-кода мастеру не будет оплачена данная заявка. Тут удовлетворены все стороны.
Пользователь (житель) получает качественную работу, мастер получает прозрачную систему оплату труда, ведь каждый заказ можно отследить, а компания контролирует работу мастеров и получает обратную связь, что также позволяет премировать мастеров или штрафовать.
Заключение
Я знаю, что дизайн не идеален и можно долго работать с цветами и типографикой, но для меня на первом месте стоит удобство использования и пользовательский опыт. Я постарался выявить проблему, сделать анализ и подготовить решение.
Я буду дорабатывать данный проект и стараться делать его еще удобнее и логичнее. Ведь я только начинаю свой путь в мире мобильных интерфейсов, поэтому, если вам было интересно и если вам не сложно, поддержите меня стрелкой вверх.
Спасибо за внимание!
Цвета и типографика, очень сильно влияют на пользовательский опыт. В ваших мокапах текст в карточках очень мелкий.
Вам правильно советуют, что круто было бы изучить гайды популярных платформ - это позволит избежать множества ошибок, в типографике уж точно)
В целом для джуна вы демонстрируете отличный подход: сценарии, диаграммы, прототипы. Но не достаточно хорошо ищете референсы, которые легко гуглятся в сети.
Так же могу с уверенностью сказать, что такая штука будет удобно в больших жк, и будет неудобна в одиночных домах, объединенных одной УК, где все вопросы решаются в вотсапе (или чат, или тет-а-тет) с представителем управляющей компании. Возможно стоит еще поработать над ценностью для пользователя.
На экране создания заявки лично мне непонятно чем отличается мастер от электрика.
Вероятнее всего для внедрения такого мобильного приложения, управляющей компании потребуется и внедрение другого софта, который будет агрегировать в себе заявки поступающие из приложения, иметь возможность управлять новостями и. т.д. Потому что процессы в управляющей не соответствуют на 100% вашим сценариям.
Как правило сначала появляется софт для ук, а потом уже к нему моюильное приложение, и это в больших управляйка пика, юита и других.
Для маленьких ук наверняка был бы интересен saas облачный сервис, с возможность интеграции с популярными системами ук. Чтобы сократить стоимость внедрения. в этом случае нужно помимо работы с ценностями для конечного пользователя, прорабатывать ценность для управляющей компании, а они довольно медленные, и консервативны. Особенно в регионах)
Для джуна однозначно плюс, и как работа в портфолио - хорошо. Но вопросов после работы вы оставляете больше, чем ответов)))
Спасибо за такой развернутый ответ. Хотел бы уточнить в чем проблема типографики? Использовал вроде из гайда эпл. Для навбара 17, потом 10 и 13 для основного контента и заголовков, отступы тоже вроде по гайду, так что хочу понять где допустил ошибку. А по поводу мастера, я вроде писал что этот пункт идет для девушек, которые не особо разбираются в роде своей поломки, поэтому они выбирают мастера, потом в комментарии пишут свою проблему и УК уже выбирает вид данной проблемы и направляет нужного мастера.
10 мелко для основного текста, когда его много. Текста новости для завтравки слишком много. Серый цвет нивелируют читаемость.
Вы неправильно используете слово "нивелировать".
да, вы правы. Прошу прощения. заменим это слово на "усложняет"