Ищете слаженную команду разработки?
Готовы помочь с дизайном и разработкой приложений для бизнеса и стартапов
Дисклеймер: В тексте упоминается продукция, связанная с потреблением никотина. Мы не призываем вас курить и напоминаем, что курение любой никотиносодержащей продукции вредит вашему здоровью.
Чаще всего мы делаем MVP с нуля, но иногда заказчики приходят со своими наработками. Так было с SOAK — к нам обратились с готовым дизайном, но для разработки в макетах не хватало важных деталей.
Сначала небольшое погружение в бизнес заказчика и его запрос. Это поможет лучше осмыслить все, о чем будем рассказывать дальше.
Контекст: разрабатываем приложение для продавцов электронок
Нашей задачей было создать приложение для дистрибьюторов SOAK. Они выставляют электронки и POD-системы у себя в магазинах и консультируют покупателей: какую модель и вкус лучше выбрать.
По задумке клиента, приложение должно помочь продавцам лучше разобраться в мире электронок — продавцы выполняют задания, получают призы за правильные ответы, и таким способом прокачивают свои знания продукта.
Приложение с элементами геймификации: продавцы проходят викторину по электронкам и получают призы за правильные ответы
Дизайн для приложения подготовил инхаус-дизайнер SOAK. К нам обратились только за помощью в разработке. Но когда мы погрузились в задачу, поняли, что макеты нужно дорабатывать, иначе могут возникнуть трудности в разработке.
Кстати, не так давно мы рассказывали про разработку PWA-приложения для производителя электронок Plonq.
На том проекте мы помогли инхаус-команде клиента разрулить все сложности с разработкой и сделали приложение для людей, которые хотят бросить курить. О том, как мы приняли горящую задачу и стали буквально «руками» клиента — читайте в этом кейсе.
5 вещей, которые стоит учесть в дизайне, чтобы не было проблем в разработке
Вот какие моменты не были в дизайне изначально, а их обязательно нужно было учесть, чтобы не застрять в круговороте правок:
-
- UI-kit. Без него разработка и добавление новых сценариев становится ночным кошмаром.
- Гайдлайны сторов. Сторы не пускают приложения без плашек «Я соглашаюсь с политикой конфиденциальности» и других неочевидных мелочей.
- Путь пользователя. Иначе юзер может попасть в сценарий, который дизайнеры не отрисовали, и запутаться.
- UX-паттерны. Это устоявшиеся привычки пользователей, нарушение которых может оттолкнуть их.
- Адаптация под малые экраны. Чтобы на телефонах «постарше» не поплыл дизайн.
Обо всём по порядку.
1. UI-kit
UI-kit — это набор компонентов, из которых собирается интерфейс. Он есть почти в каждом проекте, связанном с digital-продуктами: от международных банковских приложений до локальных интернет-магазинов.
В «ките» собраны визуальные детали приложения. Например, как выглядят кнопки: их цвет, и толщина контура. Кроме этого — технические параметры для разработчиков: поведение кнопок, код цвета, размер шрифта.
Элементы UI-kit для SOAK, который мы помогли собрать
С UI-kit интерфейс выглядит единообразным и гармоничным. Он гарантирует, что дизайн на разных экранах согласованный — кнопки стоят с одинаковыми отступами от текста, и у логотипов один и тот же цвет.
Без UI-kit дизайн кажется небрежным и «дешевым». А еще дорожает разработка — программистам придется самостоятельно подбирать параметры дизайн-элементов, чтобы сверстать приложение. Кстати, мы уже писали, как собрать UI-kit с нуля.
Когда мы взяли дизайн SOAK в работу, у приложения не было UI-kit. Из-за этого продукт казался неоднородным.
Например, у одних и тех же заголовков на разных экранах отличался кегль, а у похожих иконок была неодинаковая толщина контура. Глаз за такое цеплялся — выглядело неаккуратно.
Сравните: слева экран, который создавался без учета UI-kit, справа — доработанный экран с однородным дизайном.
Мы помогли собрать UI-kit из элементов, которые уже были у клиента. Без «кита» цвета, размеры и шрифты разработчику нужно подбирать самому. Это занимает много времени и повышает риск ошибки
С UI-kit легко разрабатывать приложение и создавать новые экраны, если они нужны. А в случае SOAK их нужно было добавить.
2. Путь пользователя — стейты и экраны
В начале каждого дизайн-проекта мы выстраиваем путь пользователя. Бизнес-аналитики в деталях расписывают, что юзер может сделать в приложении, куда может попасть и с какими ситуациями столкнуться.
Артефактом этого этапа является «User story map» (карта пользовательских историй). Дизайнеры берут эту карту, колдуют и получается карта экранов, или UX-карта.
UX-карта помогает проработать шаги пользователя в приложении. Так, сразу видно, какие нужны экраны в приложении.
В дизайне приложения SOAK были проблемы с путем пользователя. Вот вещи, которых не хватало — без них юзеры могли легко потеряться в продукте:
-
- Связующие экраны
- Экраны с эдж кейсами
- Стейты кнопок и экранов
Рассмотрим их подробнее.
Связующие экраны. Они показывают, что приложение грузится, деньги отправили на карту, а баллы за тесты зачислили на счет.
Без них пользователю кажется, что приложение виснет и не работает. Дистрибьюторы могут чаще писать в поддержку, а это приводит к дополнительной нагрузке на ресурсы заказчика и трате его времени.
Добавили экран успеха. Если пользователь пришлет задание и не увидит этот экран, он подумает, что приложение глючит
Другой пример: регистрируясь, пользователь должен ввести номер телефона и подтвердить его кодом из СМС — стандартный сценарий для многих приложений. Но в макетах для флоу регистрации отсутствовал экран с полем ввода телефона и кода. Мы его добавили.
Добавили недостающий экран
Экраны с эдж кейсами. Это редкие сценарии использования приложения, но они важны для комфортного пользовательского опыта. Например, в приложении SOAK юзер, чтобы подтвердить выполнение одного из заданий, должен был ввести уникальный код. Нужно было учесть, что пользователь может ввести некорректные данные или попытаться повторно отправить один и тот же код, и добавить предупреждения для разных случаев. Иначе юзер бы не понял, в чем проблема и решил бы, что приложение «сломалось».
Ввод некорректных данных в поле ввода — распространенный эдж кейс, который важно учесть на этапе дизайна
Конечно, такие ситуации происходят не всегда, но если их не учесть, можно потерять пользователя.
Стейты кнопок и экранов. Это состояния элементов в разных контекстах. Например, как ведут себя кнопки, если задержать на них палец, нажать или оставить в покое. Если на кнопку нельзя нажать, у нее должен быть соответствующий стейт. Без него пользователи будут и дальше давить на кнопку не понимая, что пошло не так.
Добавили разные стейты для кнопок: нормальное состояние, неактивное и после клика
В дизайне SOAK не было стейтов с ошибками. Если пользователь вводил в поле неправильный логин или пароль, интерфейс ничего не показывал — но при этом не пускал дальше.
Предупреждаем пользователя, если что-то идет не так
То же самое было с баллами. Если пользователь пытался забрать деньги и у него не хватало баллов, интерфейс ни на что не реагировал. Казалось, что приложение зависло. Поэтому мы добавили поп-ап с предупреждением.
3. UX-паттерны
Когда мы дизайним приложения, наша команда учитывает UX-паттерны — модели поведения, которым следуют пользователи. Например, «закон близости» — элементы, расположенные близко друг к другу, воспринимаются как одна группа. Или «закон Миллера» — в среднем человек способен удерживать внимание одновременно на 7 элементах.
С UX-паттернами легче сделать интуитивно понятный продукт. Чем больше в приложении знакомых сценариев, тем легче в нем разобраться с нуля.
Можно не соблюдать паттерны — отстроиться и начать делать что-то свое. Но тогда нужно надеяться, что пользователь сам все поймет, или делать ставку на то, что юзер готов потратить время и разобраться в продукте.
В приложении SOAK было 3 искажения UX-паттернов:
-
- Заголовки похожи на кнопки
- Логические ошибки
- Цвета иконок не совпадают с их значениями
Заголовки на некоторых экранах были похожи на кнопки. Юзеры могли нажать на них по привычке — сидеть и ждать, пока откроется раздел, которого не существует.
Логические ошибки. Например, в тестах в приложении есть вопросы, где нужно выбрать один вариант ответа. Дизайнер отрисовал кнопки на этих вариантах как чекбоксы, а не радиокнопки.
Из-за подмены радиокнопок на чекбоксы кажется, что нужно выбрать несколько ответов, когда нужно нажать на один. И складывается ощущение, что приложение глючит — потому что не дает выбрать нужный ответ.
Избавились от логических ошибок в интерфейсе. Теперь юзер смотрит и сразу понимает, что надо делать
Цвета иконок не соответствовали их функциям. Например, если пользователь правильно ответил на задание, иконка загоралась красным — казалось, что юзер в итоге сделал что-то не так.
Исправили несостыковки в интерфейсе — все выглядит логично и понятно
Мы собрали все проблемы с паттернами, кнопками и экранами, которые нашли, и оставили их комментариями в Figma. Так дизайнеру клиента было легче доработать экраны со стейтами и привести макеты к единому виду.
4. Гайдлайны сторов
Чтобы сторы одобрили приложение, нужно проработать политику конфиденциальности и добавить соответствующую плашку.
Без плашки «Соглашаюсь с политикой конфиденциальности» собирать данные нельзя. Если ее нет, сторы не пропустят приложение.
В изначальном дизайне SOAK момент с политикой конфиденциальности не был учтен. Если оставить его так, как есть — ничего о нем не рассказать — приложение не пройдет модерацию сторов.
Добавили пункт с согласием на обработку данных. Его не было в дизайне заказчика
5. Адаптация под малые экраны
Во время дизайна мы учитываем и маленькие экраны — например, как для iPhone SE. Для этого делаем кнопки и заголовки чуть меньше, чтобы на таких устройствах было удобно пользоваться приложением.
В дизайне SOAK, который мы получили от заказчика, кнопки были огромными. Расстояние между текстом, границами кнопки и самой надписью было слишком большим.
Такие кнопки не помещались на маленький экран — их нужно было обрезать, чтобы все влезло на страницу. Можно попробовать оставить так, как есть, но тогда каждый экран пришлось бы скроллить, чтобы найти нужную кнопку — это неочевидно и неудобно для пользователя.
Поменяли расстояние между элементами интерфейса и уменьшили кнопки, чтобы все выглядело нормально на любых устройствах
На всю «докрутку» дизайна и подготовку к разработке ушло 2 недели. Для нас это типичный спринт по Agile. Все это время мы активно общались с инхаус-дизайнером клиента и вместе улучшали интерфейс приложения.
Заключение
На дизайн и разработку приложения SOAK у нас ушло два месяца. В Google Play приложение скачали больше тысячи раз. Заказчик доволен — этот продукт больше про имидж. А за помощь ребята из компании прислали команде электронные сигареты в качестве подарка.
Чек-лист: что учесть в дизайне приложения до разработки
Сделали для вас гугл-док с чекбоксами и кратко расписали все этапы. Если у вашего штатного дизайнера небольшой опыт в UI/UX, чек-лист поможет проверить, что в дизайне учтены все моменты, о которых мы рассказали.
Или обращайтесь к нам в Purrweb. Сделаем MVP с нуля: спроектируем дизайн, разработаем приложение и зарелизим его в сторах.
Заполните форму, чтобы связаться с нами. Мы внимательно выслушаем идею, поделимся опытом и прикинем цены и сроки.
[wpim]
