Учебный проект: потребности пользователей (часть 2/6)
Вторая часть рассказа о моей дипломной работе по курсу Нетологии «UX-писатель». Расскажу, как я изучал потребностей пользователей и какие функции продукта сформулировал на их основе.
Рекомендую начать с первой части. Там о работе UX-писателя, курсе Нетологии и продуктовых гипотезах проекта.
Для дипломного проекта я придумал заказчика и задачу: современного застройщика, которому нужно мобильное приложение. В приложении жильцы общаются с управляющей компанией, передают показания счётчиков и взаимодействуют с домовой инфраструктурой.
Работа шла в два этапа: анализ конкурентов и потребностей пользователей и разработка интерактивного прототипа. О конкурентном анализе рассказывать особо нечего: ходишь по сторам и выписываешь фичи в столбик. Куда интереснее потребности и гипотезы, выдвинутые на их основе.
Но сначала немного философии.
Зачем изучать потребности
Изучение потребностей помогает понять, что действительно важно пользователю в продукте.
Польза всегда конкретна. Пользователи выбирают продукт, чтобы регулярно решать конкретные проблемы в конкретных ситуациях более удобным способом. Для поиска этого способа нужно хорошо понимать контекст: ситуации, проблемы и намерения живых людей.
Живые люди куда сложнее абстрактных персон, которые иногда собирают проектировщики с маркетологами. Люди субъективны и иррациональны. Иногда они готовы мириться с неудобствами в сложных процессах, но теряют самообладание от неочевидных мелочей, а иногда наоборот. Угадать сложно.
Очевидно, что без понимания контекста команда будет отталкиваться от собственных представлений о том, что важно пользователю, и хороший продукт получится только случайно.
Можно, конечно, ничего не изучать, а набрать гипотез исходя из опыта и здравого смысла. Тогда исследование, скорее всего, сдвинется на вторую итерацию после тестирования первой рабочей версии.
Как изучать: интервью и Job Stories
Для диплома было достаточно провести пять-шесть интервью и на их основе составить с десяток Job Stories.
Job Stories — короткие записи, которыми фиксируют пользовательские ситуации и продуктовые фичи. Для удобства чтения Job Stories формулируют по строгой трёхчастной структуре: ситуация, мотивация и ожидаемый результат.
Например, когда у меня лопнула труба (ситуация), я хочу быстрее вызвать мастера (мотивация), чтобы не затопить соседей (результат).
Чтобы Job Stories несли пользу, их нужно правильно формулировать:
- Ситуация должна содержать проблему, а не просто описывать контекст. Например, я не просто зашел на кухню, а у меня там кипяток из трубы хлещет.
- Мотивацию нельзя подстраивать под интерфейс, она должна описывать желание человека вне продукта. Я не номер телефона в приложении хочу найти, а вызвать мастера.
- Результат должен иметь связь с продуктом. Если продукт совершенно не предусматривает вызова мастера, эта потребность не принесёт пользы проектированию.
Если все сделать правильно, Job Stories будут содержать ценные сведения о потребностях реального человека и помогать фокусироваться на пользе.
Вооружившись этим знанием, я поговорил с пятью потенциальными пользователями от 28 до 60 лет, которые подумывали купить квартиру в новых жилых комплексах. Перед интервью посмотрел решения конкурентов, почитал блоги застройщиков и набросал примерный план интервью с открытыми вопросами.
В первую очередь меня интересовали отправка показаний, оплата счетов и типичные проблемы в общении с управляющей компанией. Полученные сведения я перевёл в формат Job Stories и предположил необходимые функции.
Сбор фич на основе потребностей
Интервью подтвердили основную гипотезу: жильцам удобнее отправлять показания, оплачивать квитанции и общаться с управляющей компанией в мобильном приложении.
Стало также ясно, что сосредотачиваться нужно именно на общении. Все опрошенные отмечали, что теперь нельзя просто позвонить в УК и что-то узнать: ответит не очень умный робот, а поговорить с живым человеком не получится.
Итоговое продуктовое решение звучало так:
Приложение жильца соберет в одном месте всё, связанное с домом и квартирой, и станет основным каналом коммуникации с управляющей компанией и экстренными службами.
На основе Job Stories и фич конкурентов я собрал полный список функций приложения:
- передача показаний счетчиков и история потребления
- оплата квитанций по карте и через платежные сервисы
- архив квитанций, заявок и обращений в УК
- автоплатёж
- напоминания о сроках отправки показаний и оплате квитанций
- вызов мастера с выбором даты и времени, возможность подбора мастера по описанию проблемы и по типовым ситуациям
- чат с операторами УК, возможность прикладывать к сообщениям фото и видео
- экстренная связь с диспетчером аварийных бригад
- заявки в УК с отслеживанием статуса
- информирование о предстоящих плановых работах, авариях и чрезвычайных ситуациях
- опросы и собрания жильцов
- настраиваемые пуш-сообщения
- оформление временных пропусков для гостей и курьеров
- доступ к видеокамерам в подъезде, дворе и парковке
- управление шлагбаумом и дверями пожарных выходов, кладовыми и другой домовой инфраструктурой
- справочник по законам и нормам в сфере ЖКХ с релевантным поиском и поисковыми подсказками
- управление домофоном во дворе и на входной двери
- профиль пользователя и персональные настройки
- информация по квартире: план, площадь и размеры комнат, высота потолков, точки подведения коммуникаций
В рамках диплома реализовать всё было нереально, поэтому я взял самые основные:
- новости и оповещения
- передачу показаний и оплату квитанций
- вызов мастера и звонок диспетчеру
- чат с оператором
- камеры видеонаблюдения
- справочник
- заявления в УК
Далее я нарисовал принципиальные макеты в Миро, продумал Tone of Voice и сел рисовать интерактивный прототип и проводить промежуточные исследования. Об этом будет в следующих частях.
Ссылки
Интерактивный прототип в Фигме. Смотрите в режиме презентации.
Дипломная работа в гугл-документах
Все статьи об учебном проекте:
- Задачи и результат
- Потребности пользователей — вы находитесь здесь
- Основы ToV
- Интерактивные макеты
- UX-исследование
- Бонус трек. Как ставить задачи UX-писателю