Как мы сделали приложение для work-life симбиоза: опыт «Мегаплана»

Готовы поспорить: вы решаете рабочие вопросы вне офиса, вечером и на выходных. А в рабочее время иногда отвлекаетесь на свои личные дела. Если это так, то и для вас понятия «работа» и «жизнь» переплетены. И искать нужно не баланс между ними, а возможности для взаимовыгодного симбиоза.

Эта статья будет полезна всем, кто не хочет паразитических отношений между своей работой и жизнью вне офиса. А также тем, кому интересно заглянуть на «кухню» «Мегаплана».

Пока технологии не проникли во все сферы нашей жизни, люди рассуждали о концепции баланса между работой и жизнью как о контрастных понятиях. То есть по-настоящему жить люди начинали, когда выходили из офиса или цеха. За порогом работа резко обрывалась. Не из-за того, что никто не хотел брать работу на дом, а потому, что даже офисные клерки не могли выполнять ее эффективно вне «конторы».

Сейчас появились и возможности и отчасти необходимость работать живя, и жить работая. С нами почти всегда смартфон, и мы доступны делам, общению и новой информации круглосуточно.

Вспомните, сколько раз вы отвечали «Я сейчас не за компом. Буду в офисе — сразу пришлю» или «С домашнего ноута у меня нет доступа, только на работе». Порой за недостаток мобильности мы расплачиваемся ушедшим к конкуренту клиентом или лояльностью руководства.

Как раз руководителям приходится сложнее всего. Если они по старинке пытаются делить свое время на работу и жизнь, то выпадают из ритма бизнеса, тормозят процессы и подводят других. Представьте: нужно сделать срочный платеж. Но тот, кто за это отвечает, пользуется электронными ключами-подписями. Они на флешках, флешки в офисе, а ответственный за это отлучился. Он бы и рад провести платеж удаленно, но куда там.

Симбиоз работы и жизни ни в коем случае не подразумевает, что по первой прихоти начальника стоит бросаться переделывать баннеры вечером субботы, потому что его жене не понравился цвет. Речь скорее о том, что технологии помогают нам не зависеть от офиса, а при необходимости — оперативно реагировать на важные события.

В компании RescueTime проанализировали 185 млн трудовых часов своих пользователей и выяснили, что 26% задач выполняется в нерабочее время. Все равно мы будем работать после условных 18:00, так давайте делать это эффективнее. Для этого мы стараемся делать мобильное приложение Мегаплана полноценным инструментом — офисом, который всегда с тобой.

Кстати, по статистике мы видим, что пользователи часто, работая в Мегаплане за компьютером, предпочитают отвечать на сообщения или комментарии в мобильном приложении.

В 2018 году мы выпустили третью версию приложения Мегаплана. Решили не просто улучшить вторую, а написать все с нуля. Для этого выбрали React Native, хотя с точки зрения разработки лучше использовать нативные языки для iOS и Android.

Почему мы выбрали не нативный язык?

Во-первых, у нас есть веб-версия, в которой большая часть бизнес-логики написана на React. А так как это одна платформа — React и React Native — мы можем продублировать бизнес-логику десктопной версии в приложении. Одна кодовая база для двух версий продукта существенно ускоряет разработку.

Во-вторых, чтобы разработать приложение на React Native, не нужны две разные команды под iOS и Android. Достаточно одной команды — приложение сразу выглядит как нужно на двух мобильных операционных систем. Конечно, мы адаптируем его, но каркас общий, а добавить штрихи гораздо проще. Когда пишется новая функция, в 90% случаев она не требует дополнительной доработки под платформу.

Исходя из этого, можно делать больше релизов за единицу времени. А чем больше релизов, тем больше гипотез проверяется и тем удобнее становится продукт.

К каждому модулю добавили до 50% новых функций. Пока их не было, мы видели, как наши пользователи совмещали приложение и веб-версию. Либо приложение и мессенджеры. Это неправильная логика — всё должно быть в одном месте. Такой вывод кажется очевидным, если оглядываться назад. Но в свое время мы пришли к нему, проверив много гипотез.

Создавая любой продукт, нужно опираться не на свои ощущения и видение, а на реальные пользовательские кейсы и насущные проблемы. Если в приложении появляется (и остается) изменение, то это результат подтвержденных гипотез и анализа метрик. Мы проводим продуктовые UX-исследования, самое первое из которых — «коридорное» тестирование.

Готовя обновление, делаем несколько кликабельных прототипов, которые даем попробовать разным людям в офисе. Они не просто бродят между экранами, а выполняют реальный продуктовый кейс. Например, мы даем задание отфильтровать список задач по заданным условиям и смотрим на ход решения и результат. Анализируем, как человек взаимодействует с интерфейсом в целом, насколько быстро находит нужные кнопки, на чем «буксует». Собираем обратную связь: было ли сложно, понравилось ли пользоваться?

После этого учитываем отзывы, из несколько прототипов выбираем один и отдаем его в разработку. Готовое обновление получает часть пользователей. Сейчас наступает самый важный этап: анализ того, как изменяются ключевые показатели. Наше приложение внутри себя ведет статистику поведения пользователей: что и как они делают, за какое время, какие экраны открывают. Соответственно, мы видим, как обновление сказалось на метриках.

Метрик может быть несколько, но ключевая — одна. Если вы видите, что изменение сказывается на ней негативно, то его стоит убрать, даже если второстепенные метрики улучшились. Такая логика справедлива для разработки любого софта, не только нашего приложения и не только бизнес-инструментов.

Иногда обновление кажется удобным и нужным, но статистика говорит обратное. Да, сложное и неоднозначное решение можно все равно оставить: люди постепенно привыкнут к нему. Но смысл любых изменений в улучшении. Удобно должно быть уже сейчас, а не через полгода переучивания.

Если в теле задачи в нашем приложении много текста, людям приходится долго скролить экран, чтобы добраться до комментариев. И у нас возникла идея: добавить шторку в нижней части экрана и прятать комментарии за ней. Отзывы внутри компании и от первых пользователей были положительными. Но через месяц мы посмотрели, как шторка повлияла на среднее количество комментариев. Оказалось, что оно сильно упало! Опция, которую мы задумывали, чтобы повысить вовлеченность, наоборот, снизила ее. И мы вернулись к привычному варианту, без шторки.

Полагаем, так произошло, потому что люди уже привыкли к определенному виду комментариев в их повседневных приложениях — Facebook и ВКонтакте. Там комментарии идут сразу под постом в хронологической последовательности. К тому же мы воспринимаем шторку как «бардачок» с полезной, но второстепенной информацией — иначе бы ее не прятали.

Недавно мы добавили в приложение фильтры для сортировки задач, сделок и клиентов. На этапе прототипа было два варианта. Первый — с тремя кликами и чуть сложнее. Второй — с пятью кликами, но с интуитивно понятным алгоритмом действий. Мы выбрали второй, попроще для освоения, и не прогадали: экран с фильтрами стали открывать в два раза чаще. Важнее снизить когнитивную нагрузку, а не количество кликов.

Это смахивания, свайпы, скроллинг, увеличение по двойному клику, особенности работы с файлами и многое другое. Одна из опций, давно доступная в мессенджерах — аудиосообщения. Она уже появилась и у нас, но пришли мы к ней не сразу. До этого приходилось отдельно записывать аудио на диктофон, а потом прикреплять его к сообщению, выбрав в файлах телефона. Это было не очень удобно.

Пожалуй, окончательным аргументом для нас в пользу аудиосообщений стал такой кейс. Весь коллектив одной компании пользуется Мегапланом. Весь, кроме директора. Он часто за рулем, и ему неудобно набирать сообщение текстом или прикреплять аудио отдельным файлом. Поэтому директор надиктовывал сообщения секретарше голосом в WhatsApp. А она заходила в Мегаплан и выполняла поручения: ставила или закрывала задачи, добавляла комментарии.

Когда мы наконец добавили эту опцию, то поняли, что люди действительно делятся на ненавистников и любителей аудиосообщений. Пользователи, которые раньше прикрепляли голосовые файлы, стали активно использовать новую функцию. Адепты текстовых сообщений ею не заинтересовались, но мы на это и не рассчитывали.

Неважно, нравится ли решение команде разработки или руководству. Если среди пользователей есть достаточно сторонников какой-то фичи, она должна быть. Конечно, если совпадает с тем, как развитие своего продукта видит компания.

Бывает сложно отказываться от «теплых ламповых» решений, к которым привыкли и пользователи, и команда разработки. Но это нормально. Элементы, которые казались вам классными пару лет назад, сегодня могут конфликтовать с UX-логикой. А удобство и пользовательский опыт — превыше всего.

В предыдущей версии приложения аватарки были в форме «телевизора» — квадрата со скругленными углами. Выглядели здорово, всем нравились. Но мы отказались от них в пользу круглых аватарок: в чатах кружки можно склеивать в полоску, выиграв 50% площади экрана по сравнению с «телевизорами». А на этом месте разместить что-нибудь полезнее «теплой ламповости».

Мы продолжаем развивать наше мобильное приложение. Стремимся к тому, чтобы оно было полнофункциональным, как веб-версия Мегаплана. Недавно добавили видеозвонки, они сейчас находятся на бета-тестировании. Хотим, чтобы наши пользователи не волновались о конфиденциальности разговоров и не тратили время на переключение между видеоконференциями.