Что учесть в дизайне приложения, чтобы избежать проблем в разработке. Кейс SOAK

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

Чаще всего мы делаем MVP с нуля, но иногда заказчики приходят со своими наработками. Так было с SOAK — к нам обратились с готовым дизайном, но для разработки в макетах не хватало важных деталей.

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

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

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

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

На примере проекта SOAK расскажем, что нужно учитывать в дизайне с самого начала, чтобы избежать подобных ситуаций.

5️⃣ вещей, которые стоит учесть в дизайне, чтобы не было проблем в разработке:

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

- UI-kit. Без него разработка и добавление новых сценариев становится ночным кошмаром.

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

- Путь пользователя. Иначе юзер может попасть в сценарий, который дизайнеры не отрисовали, и запутаться.

- UX-паттерны. Это устоявшиеся привычки пользователей, нарушение которых может оттолкнуть их. 

- Адаптация под малые экраны. Чтобы на телефонах «постарше» не поплыл дизайн.

Обо всём по порядку.

UI-kit — это набор компонентов, из которых собирается интерфейс. Он есть почти в каждом проекте, связанном с digital-продуктами: от международных банковских приложений до локальных интернет-магазинов. 

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

Элементы UI-kit для SOAK, который мы помогли собрать:

С UI-kit интерфейс выглядит единообразным и гармоничным. Он гарантирует, что дизайн на разных экранах согласованный — кнопки стоят с одинаковыми отступами от текста, и у логотипов один и тот же цвет. 

Без UI-kit дизайн кажется небрежным и «дешевым». А еще дорожает разработка — программистам придется самостоятельно подбирать параметры дизайн-элементов, чтобы сверстать приложение. 

Когда мы взяли дизайн SOAK в работу, у приложения не было UI-kit. Из-за этого продукт казался неоднородным. 

Например, у одних и тех же заголовков на разных экранах отличался кегль, а у похожих иконок была неодинаковая толщина контура. Глаз за такое цеплялся — выглядело неаккуратно. 

Сравните: слева экран, который создавался без учета UI-kit, справа — доработанный экран с однородным дизайном. 

Мы помогли собрать UI-kit из элементов, которые уже были у клиента. Без «кита» цвета, размеры и шрифты разработчику нужно подбирать самому. Это занимает много времени и повышает риск ошибки

С UI-kit легко разрабатывать приложение и создавать новые экраны, если они нужны. А в случае SOAK их нужно было добавить.

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

Артефактом этого этапа является «User story map» (карта пользовательских историй). Дизайнеры берут эту карту, колдуют и получается карта экранов, или UX-карта.

UX-карта помогает проработать шаги пользователя в приложении. Так сразу видно, какие нужны экраны в приложении.

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

- Связующие экраны

- Экраны с эдж кейсами

- Стейты кнопок и экранов

Рассмотрим их подробнее.

◾️ Связующие экраны.

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

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

Добавили экран успеха. Если пользователь пришлет задание и не увидит этот экран, он подумает, что приложение глючит:

Другой пример: регистрируясь, пользователь должен ввести номер телефона и подтвердить его кодом из СМС — стандартный сценарий для многих приложений. Но в макетах для флоу регистрации отсутствовал экран с полем ввода телефона и кода. Мы его добавили. 

◾️ Экраны с эдж кейсами.

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

Ввод некорректных данных в поле ввода — распространенный эдж кейс, который важно учесть на этапе дизайна.

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

◾️ Стейты кнопок и экранов.

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

Добавили разные стейты для кнопок: нормальное состояние, неактивное и после клика:

В дизайне SOAK не было стейтов с ошибками. Если пользователь вводил в поле неправильный логин или пароль, интерфейс ничего не показывал — но при этом не пускал дальше. 

Предупреждаем пользователя, если что-то идет не так:

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

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

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

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

В приложении SOAK было 3 искажения UX-паттернов: 

- Заголовки похожи на кнопки

- Логические ошибки

- Цвета иконок не совпадают с их значениями

◾️ Заголовки на некоторых экранах были похожи на кнопки.

Юзеры могли нажать на них по привычке — сидеть и ждать, пока откроется раздел, которого не существует. 

◾️ Логические ошибки.

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

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

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

◾️ Цвета иконок не соответствовали их функциям.

Например, если пользователь правильно ответил на задание, иконка загоралась красным — казалось, что юзер в итоге сделал что-то не так.

Исправили несостыковки в интерфейсе — все выглядит логично и понятно:

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

Чтобы сторы одобрили приложение, нужно проработать политику конфиденциальности и добавить соответствующую плашку.

Без плашки «Соглашаюсь с политикой конфиденциальности» собирать данные нельзя. Если ее нет, сторы не пропустят приложение.

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

Добавили пункт с согласием на обработку данных. Его не было в дизайне заказчика:

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

В дизайне SOAK, который мы получили от заказчика, кнопки были огромными. Расстояние между текстом, границами кнопки и самой надписью было слишком большим. 

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

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

На всю «докрутку» дизайна и подготовку к разработке ушло 2 недели. Для нас это типичный спринт по Agile. Все это время мы активно общались с инхаус-дизайнером клиента и вместе улучшали интерфейс приложения.

На дизайн и разработку приложения SOAK у нас ушло два месяца. В Google Play приложение скачали больше тысячи раз. Заказчик доволен — этот продукт больше про имидж. А за помощь ребята из компании прислали команде электронные сигареты в качестве подарка.