дизайн мобильного приложения для 1С: 6 экранов, которые решают всё

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

сцена: почему приложение с красивым макетом не прижилось на складе

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

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

Цена такой ошибки — не абстрактная. Переделка интерфейса под новый сценарий заняла три недели работы дизайнера и разработчика, склад весь этот срок вёл двойной учёт (бумага плюс частичные данные в системе), а два штатных кладовщика не смогли перестроиться и уволились до конца испытательного срока.

из чего складывается дизайн: пять слоёв, а не один

Когда клиент говорит «нарисуйте дизайн», он чаще всего имеет в виду только последний из пяти слоёв, которые реально формируют интерфейс.

исследование сценариев использования

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

информационная архитектура

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

прототип и тестирование на реальных задачах

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

визуальный дизайн

Только здесь появляются цвета, шрифты, иконки — то, что обычно называют «дизайном» в бытовом смысле. Хорошая новость: если первые три слоя сделаны верно, визуальный дизайн редко ломает приложение — максимум делает его менее приятным глазу, но не мешает работать.

адаптация под платформу и интеграцию

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

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

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

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

что теряет бизнес, если пропустить этап прототипирования

Пропуск прототипа кажется способом сэкономить неделю-две. На практике экономия оборачивается противоположным результатом на следующем этапе.

• ✓переделка навигации после написания кода занимает больше времени, чем изменение прототипа — потому что меняется не картинка, а логика переходов между экранами
• ✓сотрудники, для которых делали приложение, тестируют интерфейс не на макете, а на себе во время рабочей смены — и первые недели работают медленнее, а не быстрее
• ✓часть пользователей возвращается к старому способу (бумага, звонки, Excel), и получить их обратно в приложение сложнее, чем удержать с первого дня
• ✓заказчик оплачивает повторную работу дизайнера и разработчика по тем же экранам, хотя формально проект уже «сдан»

как выглядит процесс дизайна, который не переделывают

Порядок шагов важнее конкретных инструментов. Ниже — последовательность, которая снижает риск переделки после запуска.

1. ✓интервью с 2-3 будущими пользователями приложения — не с заказчиком, а именно с теми, кто будет держать телефон в руках каждый день
2. ✓карта экранов и переходов: что доступно с главного экрана, что скрыто в меню, сколько тапов до ключевого действия
3. ✓кликабельный прототип без финального визуального оформления — серые прямоугольники, но рабочая навигация
4. ✓проверка прототипа на реальном сценарии: тот самый кладовщик проходит путь «отсканировать — принять — отправить в учёт» и говорит, где споткнулся
5. ✓визуальный дизайн поверх проверенной структуры — здесь уже безопасно добавлять цвета, иконки, фирменный стиль
6. ✓проверка совместимости экранов с данными из учётной системы: остатки, статусы заказов, права доступа — до того, как разработчик сядет писать код

Для приложений, которые работают как надстройка над 1С — заказы от контрагентов, складской учёт, полевые сотрудники — этот шестой пункт критичен: экран «оформить заказ» без проверки остатков в реальном времени приведёт к тем же отказам после подтверждения, что и на бумаге, только с задержкой в один клик. Подробнее о таких сценариях — в разделе про B2B-приложения с интеграцией 1С.

где дизайн переходит в разработку и сколько это стоит

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

Для компаний, у которых мобильное приложение работает поверх 1С, есть готовый путь через 1С:Мобильную платформу — она ускоряет разработку типовых сценариев учёта и заказов за счёт готовых компонентов, но дизайн интерфейса всё равно проектируют под конкретный сценарий использования, а не берут из коробки. Стоимость разработки мобильного приложения с дизайном и интеграцией — от 500 000 ₽, точная сумма зависит от числа экранов и сложности подключения к учётной системе. Актуальные тарифы и условия — на странице цены и тарифы.

❓ Частые вопросы

Сколько времени занимает дизайн мобильного приложения до готовых экранов?

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

Можно ли начать разработку сразу по макетам без прототипа и тестирования?

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

Дизайн приложения для 1С отличается от обычного мобильного дизайна?

Да, экраны нужно проектировать с учётом структуры данных учётной системы — остатков, статусов, прав доступа. Иначе интерфейс покажет то, что физически недоступно, и пользователь получит отказ после подтверждения действия.

Что дешевле: доработать шаблонный конструктор или заказать дизайн с нуля?

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

Кто должен участвовать в тестировании прототипа приложения — заказчик или сотрудники?

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