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

Ситуация: у клиента есть штатный дизайнер, который умеет разное — верстать лендинги, создавать баннеры и придумывать логотипы. И тут его просят задизайнить интерфейс приложения. А для этого нужна экспертиза в UI/UX дизайне и совсем другие навыки. Поэтому результат может не соответствовать стандартам UI/UX, и все (или почти все) нужно переделывать.

Привет! На связи Purrweb, студия дизайна и разработки приложений. Чаще всего мы делаем MVP с нуля, но иногда заказчики приходят со своими наработками, например, готовым дизайном. Так было с SOAK, производителем электронных сигарет, который обратился к нам за разработкой мобильного приложения. Мы быстро поняли, что дизайн нужно довести до ума: в нем не хватало важных для разработки деталей. А это незапланированные траты для клиента.

На примере проекта SOAK расскажем, что нужно учитывать в дизайне приложения с самого начала, чтобы потом не пришлось переделывать. А в конце поделимся чек-листом «5 вещей, которые стоит учесть в дизайне, чтобы не было проблем в разработке приложения».

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

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

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

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

Кстати, не так давно мы рассказывали про разработку PWA-приложения для производителя электронок Plonq.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Забрать чек-лист в гугл-доке

Если вы хотите узнать больше о UI/UX дизайне для мобильных приложений, переходите в наш блог. Там мы рассказываем о трендах, делимся советами и показываем крутые кейсы из нашей практики.

Пока пишите в комментариях: какие «мелочи» в дизайне приложений больше всего влияют на ваш пользовательский опыт?