Редизайн дейтинг-приложения для рынка Африки: как мы получили интересный опыт, а наш дизайн так и остался лежать в Figma. Кейс Trueflutter

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

Чаще всего мы создаем UI/UX дизайн с нуля, но иногда к нам приходят за редизайном уже существующих продуктов. Так было и с Trueflutter — дейтинг-приложением, ориентированным на рынок Нигерии. Фаундеры хотели улучшить UX на отдельных экранах и освежить интерфейс.

Мы ударили по рукам и приступили к работе. Должны были уложиться за месяц. В итоге проект занял больше времени, чем мы планировали, а наш обновленный дизайн…так и остался макетами в Figma. О том, как так вышло и почему важно сразу договориться с клиентом, кем он вас видит — «руками» или «головой» — в этом кейсе.

Летом 2022 года к нам обратились фаундеры стартапа Trueflutter — дейтинг-приложения, ориентированного на рынок Нигерии. В нем учтены местные культурные особенности. Например, нигерийцы ищут пару среди людей с таким же вероисповеданием и обращают внимание на социальный бэкграунд будущего партнера — образование, место работы и так далее. К моменту, когда заказчики пришли к нам, у приложения было 100к активных юзеров.

Киллер-фича Trueflutter — голосовое сообщение, которое пользователь может прикрепить в своем профиле.

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

Ведь редизайн — это не просто поменять форму элементов на главной странице или перекрасить кнопки. Он подразумевает цельное переосмысление продукта.

И это нам потом аукнулось. Но обо всем по порядку.

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

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

А что было у Trueflutter? Флоу такой: юзер регистрируется, указывает номер телефона и страну. Ему приходит код подтверждения, он вводит его, потом указывает email, имя, дату рождения. Все, можно искать любовь? 💕

Нет, подождите. Еще нужно указать пол, интересы, религию, разрешить доступ к геолокации, загрузить фото.

Ну, теперь, кажется, все? Юзер переходит на следующий экран, где его ждет это:

Юзер успешно прошел первую фазу онбординга из трех. А дальше — продолжение анкеты и вопросы про рост, место работы, образование, школу, интересы и так далее.

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

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

Задачи на проекте были такие:

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

Исследование для Trueflutter проводили в два этапа — сначала мы анализировали конкурентов, смотрели лучшие практики и негативные кейсы, а потом проводили юзабилити-тесты с реальными пользователями. Остановимся подробнее на каждом из этапов.

Неважно, разрабатываем ли мы дизайн для абсолютно нового продукта или делаем редизайн — всегда стартуем с анализа конкурентов.

В этом проекте особое внимание обращали на реализацию главной страницы и онбординга — это могло бы подсказать нам, как адаптировать решения конкурентов для Trueflutter.

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

Исключительно в рамках исследования 🙂 Для юзабилити-теста мы отобрали людей с разным опытом онлайн-дейтинга — как совсем новичков, так и «профи». Всем поставили одинаковую задачу: найти в Trueflutter партнера.

☝ Важный момент: выбирали участников без экспертизы в UI/UX дизайне, чтобы это не исказило результаты.

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

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

Результаты исследования мы обсудили с заказчиком и вместе генерировали идеи, что и как можно улучшить.

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

Вот так было…

…а так стало. Мы оставили базовые цвета приложения, но убрали градиенты, освежили дизайн более актуальным шрифтом, формами и эмодзи. Листайте галерею, чтобы все увидеть 👉

И это нормально🙂 Этот этап и нужен, чтобы согласовать видение перед началом полноценной работы. Когда презентуем дизайн-концепт, всегда готовимся к тому, что мэтча может не случиться.

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

В итоге работали над концептом две недели — хотя обычно укладываемся в неделю. У нас было несколько промежуточных вариантов: смотрели разные цвета, меняли внешний вид элементов, обсуждали с заказчиками UX-логику.

Мы согласовали концепт и полетели в полноценный UI/UX редизайн приложения, хорошо понимая бизнес-задачи клиента и конечную цель. Что может пойти не так? Как оказалось, мы не учли эмоциональную составляющую.

Во время работы над новым дизайном клиенты признались, что привязаны к старому дизайну и не хотят от него отказываться 🙃

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

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

Показываем, что получилось в итоге.

Домашняя страница

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

Онбординг

Мы улучшили отдельные элементы и сделали заполнение анкеты более удобным для пользователей. Поработали над деталями: например, раньше не везде дизайн был согласованным. Уменьшили количество шагов за счет того, что сгруппировали некоторые вопросы. Но радикально сокращать анкету не стали: получилось два этапа вместо трех и 30 экранов вместо 50. Хотя исследования показали, что онбординг стоило бы сократить, заказчики в итоге решили не менять его.

Почему? Нам самим сложно назвать точную причину. Но мы знаем, что заказчики вдохновлялись дейтинг-приложением Bumble и в какой-то момент стали подцеплять оттуда многие штуки, которые просили реализовать нас в дизайне Trueflutter. А в Bumble — длинная анкета на этапе онбординга, возможно, поэтому заказчики не захотели убирать её и в своем приложении. Как мы не пытались их переубедить ссылками на наш ресерч 🙂

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

Мы выполнили задачи и помогли клиенту определить новое видение продукта. Хотя признаемся честно: нас сильно удивило, насколько резко заказчик изменил направление 🙂 Но такое случается — считаем, что получили интересный опыт.

А еще этот проект заставил нас пересмотреть некоторые процессы. Вот три главных урока, которые мы извлекли:

1. Обсуждать с заказчиком на берегу, насколько он готов к изменениям и редизайну. С самого начала мы недооценили, насколько заказчики привыкли к дизайну своего продукта и как его любили. И хотя они сами понимали необходимость перемен, эта привязанность все переселила, поэтому какие-то решение принимались вопреки результатам исследований. Поэтому важно еще на старте убедиться, что заказчик понимает масштаб предстоящих изменений и готов к ним.

2. Взять паузу при большом количестве правок. Когда от клиента поступает слишком много фидбека, важно вернуться на шаг назад и обсудить его ожидания. Например, на этом проекте мы получали много фидбека, и поняли, что зашли в тупик. Мы обсудили это с заказчиками и спросили, чего они ожидают: хотят ли они, чтобы мы предлагали решения, основываясь на своей экспертизе, или просто вносили правки? В итоге мы договорились, что заказчики делятся идеями, исходя из своего понимания рынка, а мы адаптируем их с учетом нашего опыта в UI/UX дизайне.

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

Мы в Purrweb за годы работы научились находить общий язык с самыми разными клиентами и предлагать решения даже в сложных ситуациях. Делимся опытом в кейсах — заходите в наш блог.

А пока расскажите в комментариях: какие неожиданные изменения возникали у вас в проектах, и как вы с ними справлялись?