Почему в приложении так сложно разобраться,
хотя все функции вроде бы есть?
UX/UI дизайн
мобильных приложений
в Новосибирске
Мобильные интерфейсы не читают — ими пользуются на ходу. Дизайн должен вести пользователя к цели.
Понятно с первого взгляда
Удобно пользоваться
Быстро цепляет
С чем приходят за дизайном приложения
Разработчики рисуют сами
Экраны собраны из того, что было под рукой, и приложение выглядит черновиком.
Пользователи не находят нужное
Функция есть, но до неё доходят единицы, и поддержка объясняет путь вручную.
Макеты не собираются
Дизайнер отдал картинки, и разработчик третью неделю уточняет отступы.
Каждый экран свой
Кнопки и поля различаются от экрана к экрану, и правки расходятся неделями.
Приложение не похоже на бренд
Сайт один, приложение другое, и клиент не узнаёт компанию.
Кому нужен дизайн приложения
Новым продуктам
Когда идея есть, а как она выглядит на экране, ещё не решено.
- Сценарии и экраны
- Прототип
- Макеты под сборку
Приложениям с низкой конверсией
Когда установки идут, а до целевого действия доходят немногие.
- Разбор воронки
- Правки экранов
- Проверка на людях
Рабочим приложениям
Когда сотрудники работают в приложении смену и устают от него.
- Крупные элементы
- Меньше шагов
- Работа одной рукой
Как устроена работа над дизайном приложения
Разбор задач и людей
Кто пользуется приложением, зачем открывает его и что делает чаще всего.
Люди
Сценарии
Структура и прототип
Карта экранов, навигация и кликабельный прототип без оформления.
Карта экранов
Прототип
Оформление и система элементов
Цвета, шрифты, кнопки и поля, собранные в переиспользуемые компоненты.
Стиль
Компоненты
Передача в разработку
Состояния, отступы, поведение при ошибках и ответы на вопросы по ходу сборки.
Состояния
Сопровождение
Как формируется цена
на дизайн приложения
в Новосибирске
Цена формируется по логике, сценариям и состояниям —
а не по количеству экранов, которое мы насчитали в Figma.
Онбординг, пустые состояния, базовые паттерны
от 100 000 ₽
Сложная навигация, кроссплатформенные макеты
от 100 000 ₽
Дизайн системы, взаимодействия, UI-варианты
от 150 000 ₽
*Финальная стоимость зависит от логики, функций и визуальной проработки.
Цены указаны без НДС. НДС по ставке 5 % предъявляется дополнительно и включается в счёт.
Больше возможностей для вашего проекта
Мы работаем с разными задачами и форматами.
Изучите дополнительные решения, которые могут подойти вашему проекту.
Ниши
Формат
- Интернет-магазины
- Недвижимость
- Здравоохранение и стоматология
- Рестораны и кафе
- Салоны красоты
- Образование
- Строительство
- Юридические услуги
- Туризм и гостиницы
- Логистика
- Дизайн интерьеров
- Ремонт квартир
- Автосервисы
- Маркетплейсы
- Консалтинг
- Фотографы
Обсудим проект?
FAQ
Если не нашли ответа — напишите нам на info@toimi.pro.
Можете ли вы переделать только часть приложения?
Да, конечно. Мы можем переработать один экран, отдельный сценарий или новую фичу — мы часто работаем с уже существующими продуктами. Убедимся, что наш дизайн аккуратно встраивается в вашу текущую систему и ничего не ломает.
Вы следуете гайдлайнам Apple?
Только там, где это действительно помогает. Мы используем iOS-паттерны, когда это имеет смысл,
но на первое место ставим понятность, удобство и стиль вашего бренда; жёсткие шаблоны нам не указ.
Как вы обеспечиваете адаптивность на всех экранах?
Мы проектируем адаптивно с самого начала — тестируем макеты под разные размеры, жесты и зоны удержания. Ничего не делаем «только под iPhone 14».
А если наш текущий дизайн… в порядке?
Если все работает — мы не трогаем. Но «в порядке» часто скрывает проблемы. Мы помогаем выявить, где пользователи теряются, тормозят или уходят — и точечно это исправляем.
Обязательны ли вайрфреймы или ресерч до старта?
Нет, от вас не требуется ни вайрфреймов, ни предварительного ресерча. Можно начать хоть с зарисовок на салфетке или чернового описания идеи. Мы сами погружаемся в тематику, изучаем рынок и поведение пользователей — и уже на этом основании предлагаем структурированные сценарии и решения.
Что такое система элементов в дизайне приложения?
Набор кнопок, полей и карточек, из которых собирают все экраны.
Зачем она нужна?
Правка в одном компоненте расходится по всем экранам сразу.
С чего начинают систему?
С цветов, шрифтов, отступов и состояний кнопок.
Что такое состояния компонента?
Обычное, нажатое, неактивное, загрузка и ошибка.
Нужно ли рисовать все состояния?
Иначе их придумает разработчик по своему усмотрению.
Как быть с отступами?
Их задают шагом сетки, а не на глаз.
Какой шаг сетки берут?
Кратный четырём или восьми пунктам.
Нужно ли описывать типографику?
Размеры и начертания задают набором стилей.
Сколько размеров текста нужно?
Пять-семь на всё приложение.
Как быть с цветами?
Цвета задают ролями: основной, фон, текст, опасность.
Почему цвета задают ролями?
Тогда тёмная тема получается заменой значений.
Нужна ли тёмная тема в системе?
Её закладывают сразу, иначе придётся перерисовывать.
Как быть с иконками в Новосибирске?
Один набор в одном стиле и в одном размере сетки.
Нужно ли рисовать свои иконки?
Системные понятнее, свои рисуют для уникальных сущностей.
Как быть с карточками?
Карточку описывают одним компонентом с вариантами.
Нужно ли описывать пустые состояния?
Пустой экран — тоже компонент.
Как быть с сообщениями и подсказками?
Их собирают в компоненты с правилами показа.
Нужна ли документация к системе?
Короткие правила использования рядом с компонентами.
Как быть с названиями компонентов?
Имена совпадают с теми, что использует разработчик.
Зачем согласовывать названия?
Общий язык снимает половину вопросов при сборке.
Нужно ли собирать систему в редакторе дизайна?
Компоненты и переменные держат в библиотеке файла.
Как быть с двумя платформами?
Общие компоненты плюс платформенные различия.
Нужно ли повторять системные элементы платформ?
Их берут из наборов платформы, а не рисуют заново.
Как быть с ростом системы?
Новый компонент добавляют, когда он нужен дважды.
Нужно ли чистить неиспользуемое?
Мёртвые компоненты удаляют раз в квартал.
Как быть с версиями системы?
Изменения фиксируют списком по выпускам.
Нужно ли согласовывать правки системы?
Их вносит один ответственный дизайнер.
Как быть с использованием системы разработчиком?
Компоненты кода повторяют компоненты макета.
Нужно ли называть переменные так же в коде?
Совпадение имён ускоряет сборку.
Как быть с системой на маленьком проекте?
Даже минимальный набор экономит время.
Сколько занимает сборка системы?
От недели, дальше она развивается по ходу.
Нужно ли брать готовую систему элементов?
Готовую основу берут и настраивают под бренд.
Как быть с брендом внутри системы?
Цвета и шрифты бренда подставляют в роли.
Нужно ли проверять доступность компонентов?
Контраст и размеры проверяют на уровне системы.
Как быть с передачей системы новому дизайнеру?
Документация и правила позволяют войти за день.
Что даёт система через год?
Новые экраны собирают быстрее и они выглядят единообразно.
Что входит в библиотеку компонентов?
Кнопки, поля, карточки, списки, сообщения и пустые состояния.
Нужно ли описывать варианты компонента?
Варианты задают свойствами, а размер и цвет — переменными.
Как быть с переменными цвета?
Каждой роли цвета задают значение для светлой и тёмной темы.
Нужно ли задавать шаг отступов переменной?
Шаг сетки держат одной переменной.
Как быть с набором размеров текста?
Стилей текста держат пять-семь.
Нужно ли ограничивать число компонентов?
Компонент добавляют, когда он нужен во второй раз.
Как быть с устаревшими компонентами?
Их помечают и удаляют после перехода экранов.
Нужно ли документировать правила компонента?
Рядом с ним пишут, когда его применять.
Как быть с совпадением имён в коде?
Имена компонентов согласуют с разработчиком.
Нужно ли вести владельца библиотеки?
Правки вносит один ответственный дизайнер.
Как быть с проверкой контраста компонентов?
Контраст проверяют на уровне библиотеки.
Нужно ли чистить библиотеку по расписанию?
Раз в квартал убирают неиспользуемое.
Лучшие статьи о мобильной разработке 
Смотрите также
Обновлено: