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

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

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

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

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

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

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

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

Четвёртое это набор для разработки: сетка, шрифты, цвета, компоненты, иконки в нужных размерах, отступы и правила поведения. Плюс иконка приложения и картинки для страницы в сторе, если они нужны.

Для застройщика Арбан мы делали дизайн приложения по подбору недвижимости. Ключевой экран там это параметры: комплекс, корпус, число комнат, площадь и этаж. Задача выглядит простой ровно до момента, когда всё это надо уместить в один экран телефона и не превратить в анкету.

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

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

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

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

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

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

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

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

Для Арбана иконка построена на фирменном знаке: узнаваемое написание и силуэт крыши на плотном красном фоне. Она читается и на светлой, и на тёмной теме, и не сливается с соседними иконками в папке.

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

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

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

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

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

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

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

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

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

Когда приложение работает, а нужен ещё канал продаж, часто добавляют бота: витрина и заказ прямо в мессенджере. У нас это отдельная услуга, бот-магазин в Телеграм, и она хорошо соседствует с приложением.

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

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

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

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