Surf 
Тендеры и лиды
Информация
Не про «подобрать модные цвета», а про процесс: с чего начинается дизайн приложения, какие шаги проходит, чем мобильный экран отличается от веба и на каких граблях мы успели потоптаться.
Запрос «сделайте красиво» мы слышим часто, и почти всегда за ним стоит другая, настоящая задача: чтобы человек открыл приложение, за пару секунд понял, что делать, и дошёл до покупки или нужного действия без раздражения. Красота тут — следствие, а не цель. Дизайн приложения, которое продаёт и удерживает, — это работа на стыке логики, психологии восприятия и инженерных ограничений телефона. Ниже разберём, как такой дизайн собирается на практике, без теории ради теории.
Мы в Surf проектируем интерфейсы и разрабатываем мобильные приложения уже не первый год, а также проводим UX/UI-аудит существующих продуктов, так что показываем процесс так, как он идёт у нас в продакшене: с шагами, ролями и реальными результатами, а не как идеальную схему из учебника.
Когда говорят «дизайн приложения», обычно имеют в виду картинку: экраны, кнопки, иконки. Но видимый слой держится на невидимом.
UX (как устроено) — это сценарии и структура: какой путь проходит человек к цели, где разделы, что за чем идёт, что происходит при ошибке или плохой сети. UI (как выглядит) — это уже визуал поверх логики: сетка, цвет, типографика, состояния элементов, анимация. Можно нарисовать красивый экран поверх кривого сценария и получить приложение, которое хвалят на скриншотах, а удаляют после первого заказа.
Поэтому «нарисовать дизайн приложения» и «спроектировать приложение» — не одно и то же. Рисование — последняя четверть работы. Всё интересное происходит до того, как дизайнер открывает Figma.
На десктопе у пользователя мышь, большой экран и, как правило, он сидит за столом. На телефоне всё иначе, и эти отличия напрямую бьют по деньгам.
Палец вместо курсора. Минимальная зона касания — 44×44 pt по гайдлайнам Apple и 48×48 dp по Material Design от Google. Если кнопка меньше, пользователь мажет, злится и уходит. Курсор такого не прощает разве что совсем уж мелким целям, палец — почти любым.
Одна рука. Около половины людей держат телефон одной рукой и тянутся большим пальцем. Низ экрана достаётся легко, верхние углы — почти нет. Поэтому основная навигация уезжает вниз, а не наверх, как привыкли на сайтах.
Маленький экран — другая иерархия. На вебе можно держать 6–8 уровней заголовков и плотную сетку. На мобильном работают 3–4 уровня, иначе экран превращается в кашу. Информацию приходится открывать порциями, а не вываливать сразу.
Скорость ощущается физически. Анимация перехода в 200–300 мс читается как плавная; отклик на касание дольше 100 мс уже воспринимается как подтормаживание. Это не вкусовщина, это восприятие.
iOS и Android — разные миры. У них свои гайдлайны, свои паттерны навигации, свои привычки у пользователей. Системный шрифт, поведение «назад», уведомления, иконки — всё отличается. Натянуть один в один айфонный интерфейс на Android — значит сделать приложение, которое местному пользователю кажется чужим.
Есть вещь, про которую забывают почти все гайды: состояния экрана. Экран существует не в одном идеальном виде с данными. Есть загрузка, есть пустой список, есть ошибка, есть «нет сети». Если эти состояния не нарисованы, разработчик придумает их сам, и обычно это будет белый экран или непонятная крутилка. Хороший дизайн проектирует все четыре, а не один глянцевый «когда всё хорошо».
Процесс у нас выстроен так, чтобы дорогие ошибки ловились на дешёвом этапе. Чем раньше нашли проблему, тем дешевле она стоит: поправить сценарий в макете — минуты, переписать уже закодированный экран — дни.
Сначала разбираемся, для кого и зачем приложение. Кто пользователь, какие у него сценарии, что делают конкуренты, какие у бизнеса ограничения по срокам, бренду и платформам. Если этот шаг пропустить, дизайн строится на догадках, и красивые экраны потом приходится переделывать, когда выясняется, что люди ходили совсем другим путём.
Рисуем карту приложения и user-flow — маршруты, которыми человек идёт к цели. Тут видно, сколько шагов до покупки, где разветвления, где можно срезать. Часто на этом этапе экранов в голове было «штук десять», а сценарий показывает, что половина лишняя.
Чёрно-белые каркасы экранов без цвета и картинок: где блок, где кнопка, что за чем. Намеренно некрасиво, чтобы и заказчик, и команда обсуждали логику, а не оттенок синего. На вайрфреймах дёшево проверить структуру и переставить всё местами.
Тут появляется фирменный стиль: цвет, типографика, иконки, сетка, анимация. Параллельно собираем UI-kit — библиотеку компонентов (кнопки во всех состояниях, поля, карточки, шрифтовая шкала). Это не бюрократия, а экономия: разработчик кодирует компонент один раз и переиспользует, а приложение растёт без визуального разнобоя.
Из макетов собираем кликабельный прототип — приложение, которое ещё не написано, но в нём уже можно «потыкать». Даём его реальным людям и смотрим, где они спотыкаются. Это самый дешёвый способ найти проблему: на прототипе правка стоит ничего, после релиза — переписанного кода и потерянных пользователей.
Финал — отдать дизайн так, чтобы разработчик не гадал. Размеры, отступы, цвета, поведение состояний, анимации — всё описано и доступно прямо в макете (в Figma для этого есть режим разработчика). Плохой хэндофф — когда дизайнер кинул картинки и ушёл; хороший — когда сборка не расходится с макетом на пиксели.
Это не строгая эстафета, где шаг сдают и забывают. На практике петля крутится: на тесте всплывает проблема, возвращаемся к сценарию, правим, прогоняем заново.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13703 тендера
проведено за восемь лет работы нашего сайта.
На раннем продукте обычно хватает одного продуктового дизайнера: он держит в голове и логику, и визуал. По мере роста добавляются роли: UX-исследователь отвечает за то, чтобы решения опирались на данные о людях, UI-дизайнер — за глубину визуала и айдентику, моушн-дизайнер — за анимацию и микровзаимодействия, дизайн-лид — за цельность системы. Чем сложнее приложение, тем сильнее имеет смысл разделять; на старте эти роли совмещают.
Теория хорошо смотрится в статье, но проверяется на продакшене. Два примера из наших.
Love Republic — редизайн, а не рисование с нуля. К нам пришёл премиальный fashion-бренд с приложением, которое тормозило и теряло покупателей. Это отдельный жанр работы, про который гайды молчат: переделывать живой продукт сложнее, чем рисовать чистый лист, ведь нельзя сломать привычные людям сценарии. Мы переразработали приложение на кроссплатформе, пересобрали UX вокруг короткого пути «от вдохновения до покупки» и добавили AI-фичи: поиск, видеопримерку, онлайн-стилиста. Результат со страницы кейса Love Republic: конверсия в покупку выросла в 2 раза, в приложение ушло 30% всех покупок, затраты на разработку сократились на 40% за счёт кроссплатформы, рейтинг в App Store — 4,9 на 23 тысячах оценок. Первый релиз заняли 5 месяцев, а за первые три часа после запуска прошло 300 заказов.
Rigla — одна дизайн-система на шесть приложений. Аптечной сети нужно было запустить мобильный канал для нескольких брендов сразу. Мы собрали 6 приложений на единой базе за 5 месяцев: общая архитектура и дизайн-система, но свой облик у каждого бренда. По данным кейса Rigla: месячная аудитория 1,3 млн+, средний чек вырос в 3,5 раза, конверсия дошла до 33,8% у «Риглы» и 36% у «Будь здоров», доля приложений без сбоев — 99,97–99,99%. Здесь видно, зачем нужна дизайн-система: без неё шесть приложений превратились бы в шесть несогласованных проектов.
Объединяет оба кейса простая мысль: цифры дал не «красивый дизайн» сам по себе, а спроектированные сценарии, на которых эта красота держится.
Короткий чек-лист из собственных шишек — проверьте по нему свой проект.
Дизайн без оглядки на разработку. Эффектный экран, который тяжело и дорого кодить или который тормозит на среднем телефоне, — плохой дизайн, каким бы красивым он ни был. Дизайнер и разработчик должны спорить на этапе макета, а не после релиза.
Забытые состояния. Нарисовали «когда всё хорошо», а пустой список, ошибку и офлайн оставили на потом. «Потом» приходит в виде белого экрана у пользователя.
Война с гайдлайнами. Желание сделать «не как у всех» в навигации и базовых жестах оборачивается тем, что человек не понимает привычных вещей. Оригинальничать стоит в характере бренда, а не в кнопке «назад».
Лишние экраны. Каждый экран и каждое поле на пути к цели — место, где часть людей отваливается. Если шаг можно убрать, его нужно убрать.
Дизайн без проверки на людях. «Нам в команде нравится» — не аргумент. Пока прототип не потрогали реальные пользователи, это гипотеза, а не решение.
Главный плюс прототипа в том, что качество можно оценить до того, как написана первая строчка кода. Смотрите не на «нравится / не нравится», а на проверяемое: доходят ли люди до цели в прототипе, сколько шагов им нужно, где они путаются, попадают ли пальцем по кнопкам, понятны ли тексты ошибок. Если дизайн нельзя связать с конкретными сценариями и тем, как человек по ним проходит, это пока оформление, а не дизайн.
И ещё про деньги. Каждая правка после релиза тянет за собой регрессию и тестирование — это дорого. Поэтому смысл всего процесса один: ловить ошибки там, где они стоят минут, а не недель.
Дизайн приложения — это два слоя: UX (как устроено) и UI (как выглядит); по отдельности они не работают.
Мобильный экран диктует свои правила: зоны касания 44/48, навигация под большой палец, 3–4 уровня иерархии, проектирование всех состояний экрана.
Рабочий процесс — шесть шагов от исследования до хэндоффа, и это петля, а не прямая эстафета.
Ошибки дешевле всего ловить на прототипе; правка после релиза стоит переписанного кода.
Цифры приносит не красота, а спроектированные сценарии — это видно по нашим проектам Love Republic и Rigla.
Дизайн мобильного приложения — это не финальная полировка, а то, что определяет, дойдёт ли человек до цели и вернётся ли он. Кто относится к нему как к измеримой работе над сценариями, получает приложение, которое продаёт; кто как к картинке — красивые скриншоты и пустую аналитику.
Владимир Макеев, генеральный директор Surf — компании по разработке и дизайну цифровых продуктов для крупного и среднего бизнеса.
