Как объяснить разработчику, как должно выглядеть приложение

Почему «на словах» не работает — механика, а не лень

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

У слов нет координат. Фраза «кнопка заказа наверху» описывает примерно сорок разных экранов. Наверху — это в шапке или под шапкой? На всю ширину или справа? Она видна всегда или уезжает при прокрутке? Каждое из этих «или» разработчик решит сам, и в половине случаев решит не так, как у вас в голове. Не потому что не старался — потому что выбора вы ему не оставили, а решение принять надо.

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

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

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

Пять способов и что теряется в каждом

1. Рассказать словами (созвон, голосовые, переписка)

Самый быстрый и самый дорогой. Работает ровно для одного: договориться, что вообще делаем. Дальше начинается «я думал, вы имели в виду». Главный признак, что вы в этом режиме: на демо вы говорите «ну не совсем так» и не можете объяснить, чем именно не так.

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

2. Дать референсы («сделайте как в Авито»)

Резко лучше, чем ничего, но с одним условием, которое почти никогда не выполняют: нужно сказать, что именно вам нравится. «Как в Авито» — это фильтры? карточки товара? чат? способ загрузки фото? У Авито в приложении несколько сотен экранов, и вы имеете в виду один из них.

Рабочая формулировка выглядит так: «карточка товара — как в Авито: большое фото сверху, цена крупно под ним, кнопка "Написать" прилипшая к низу экрана. Всё остальное в Авито нам не нужно». Три предложения, ноль двусмысленности.

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

3. Нарисовать на бумаге и сфотографировать

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

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

4. Написать документ или собрать презентацию

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

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

5. Собрать кликабельный макет

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

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

Что не закрывает: правила и состояния. Макет не расскажет, что делать с отменённым платежом. Поэтому пункт 4 никуда не девается — просто становится в разы короче.

Сводная таблица

Практический вывод: макет + короткий список правил закрывают примерно всё, ради чего обычно пишут сорокастраничное ТЗ. Дизайн заказывается после и по макету — он получается дешевле, потому что дизайнер не угадывает структуру.

Почему это про деньги, а не про аккуратность

Одна и та же правка — «кнопку оформления надо не в конец списка, а закрепить внизу» — стоит совершенно разного в зависимости от того, когда её нашли.

Точные суммы зависят от команды, но порядок разницы устойчив: правка на макете дешевле правки в коде на один-два порядка, а после релиза добавляется то, что деньгами не решается, — время на прохождение модерации в App Store, Google Play или RuStore.

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

Словарь: как называется то, что вы хотите

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

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

Что разработчик решит за вас, если вы промолчите

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

Навигация

• Как устроен переход назад — стрелка в шапке, свайп, обе?
• Есть ли нижнее меню (таб-бар)? Сколько в нём пунктов и какой открывается первым?
• Что происходит после успешного действия: возврат на предыдущий экран, переход на главную или остаёмся на месте с сообщением?

Пустота и ошибки

• Что видит человек, у которого ещё ничего нет: пустой список — это пустота, картинка с надписью или сразу форма создания?
• Что показать, когда пропал интернет: сообщение поверх экрана, строка сверху, пустой экран?
• Ошибка формы — под каждым полем или одним сообщением сверху?

Долгие операции

• Загрузка: крутилка по центру, скелетоны (серые заглушки на месте будущего контента) или ничего?
• Что происходит, если человек нажал кнопку оплаты дважды?

Данные, которые не влезают

• Название товара в 120 символов — обрезаем многоточием, переносим на две строки или сжимаем шрифт?
• Список из 5000 позиций — подгрузка при прокрутке или страницы?
• Нет фотографии товара — заглушка какая?

Формы

• Какие поля обязательны и что нельзя ввести (телефон без +7, имя цифрами)?
• Сохраняется ли введённое, если человек вышел с экрана и вернулся?

Права и роли

• Что видит незалогиненный человек — вообще всё, кроме оформления, или сразу просят войти?
• Есть ли роли (клиент, менеджер, админ) и чем отличаются их экраны?

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

Как собрать такой макет за вечер — маршрут

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

Шаг 1. Выпишите экраны списком, до всякого рисования

Обычно приложение — это 5–9 экранов: вход, главная, список, карточка, форма, подтверждение, профиль. Если получилось больше пятнадцати — вы описываете не первую версию.

Шаг 2. Заведите экран под нужное устройство

В Maketa при создании экрана выбирается рамка — iPhone 15, iPhone SE, Pixel 8, Galaxy S24, iPad, веб-десктоп — и размер подставляется сам. Это не косметика: на iPhone SE (375×667) помещается заметно меньше, чем на iPhone 15 Pro, и «внизу экрана» на них означает разные вещи.

Шаг 3. Соберите экран из готовых блоков

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

Шаг 4. Свяжите экраны переходами

У любого объекта в панели свойств есть строка «При нажатии → экран». Выбрали кнопку «Оформить», указали экран «Подтверждение» — переход готов. У нижнего меню переход настраивается отдельно для каждого пункта: таб-бар в Maketa это один объект с 2–5 пунктами, а не пять нарисованных иконок.

Шаг 5. Проверьте себя в «Просмотре»

Кнопка «▶ Просмотр» открывает макет в рамке телефона с рабочими переходами и кнопкой «‹ Назад». Пройдите свой же сценарий от начала до конца. Здесь обычно и вылезает «а как вернуться из корзины в каталог».

Шаг 6. Допишите словами то, чего не видно

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

Шаг 7. Отправьте ссылку

Кнопка «Поделиться» даёт одну ссылку на макет. Права переключаются тут же: «Может редактировать», «Только просмотр» или «Только приглашённые» (по умолчанию — только просмотр). Разработчик открывает ссылку в браузере, кликает переходы, как в настоящем приложении, и может сделать себе копию. Устанавливать ему ничего не нужно, регистрироваться — тоже.

Реалистичный расчёт по времени: первый экран — 10–15 минут, пока разбираетесь; дальше по 5–7 минут на экран; переходы и примечания — ещё полчаса. Семь экранов за вечер — нормальный темп для человека, который открыл редактор впервые.

Если рисовать совсем не хочется

Есть два обходных пути, оба честные.

Разобрать чужой скриншот. Вы нашли приложение, где нужный экран уже сделан правильно. Вставляете скриншот в Maketa (Ctrl+V) и нажимаете «ИИ-разбор» — картинка превращается в набор редактируемых объектов: прямоугольники, тексты, кнопки. Дальше правите под себя: меняете подписи, убираете лишнее. Это платная операция, 15 ₽ за разбор. Важно понимать ограничение: разбирается структура, а не пиксели, — сложные градиенты, тени и иллюстрации не восстановятся, получится схема. Для объяснения разработчику схемы достаточно, для дизайна — нет.

Описать экран словами ИИ-помощнику. «Экран корзины интернет-магазина: список товаров, итоговая сумма, кнопка оформления» — и получаете экран из объектов, которые дальше двигаете руками. 19 ₽ за экран. Результат — рабочая заготовка, а не финальный вид; дорабатывать руками придётся почти всегда.

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

Сам редактор, переходы, ссылки и совместная работа — бесплатны и остаются бесплатными.

Чего макет не решает — честно

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

Макет не заменяет договорённости о правилах. Расчёт скидок, что приходит в СМС, кто кому пишет при отмене заказа — это текст, и его придётся написать.

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

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

Экспорт — по одному экрану в PNG. Выгрузить весь макет одним файлом сейчас нельзя; основной способ поделиться — ссылка, и она в любом случае лучше картинки, потому что по ссылке переходы работают.

Что отправить разработчику: короткий чек-лист

1. Ссылка на кликабельный макет (не картинки — ссылка, чтобы переходы кликались).
2. Список экранов с одной строкой назначения на каждый.
3. Ответы на вопросы из блока «что решит за вас» — хотя бы на половину.
4. Правила словами: расчёты, обязательные поля, что приходит в уведомлениях.
5. Два-три референса с пояснением, что именно оттуда берём.
6. Отдельной строкой — чего в первой версии не будет. Этот пункт экономит больше всего.

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

Нужно ли уметь рисовать?

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

А если разработчик скажет «дайте нормальное ТЗ»?

Кликабельный макет со списком правил — это и есть нормальное ТЗ для мобильного приложения, только в удобной форме. Если нужен документ, отдельно разобрана структура ТЗ на приложение — с макетом он получается короче, потому что раздел «описание экранов» заменяется одной ссылкой.

Разработчик увидит макет без регистрации?

Да. Ссылка открывается в браузере, вход не нужен. По умолчанию у него режим просмотра; если вы хотите, чтобы он правил макет вместе с вами, — переключите права в «Поделиться» или добавьте его по почте в соавторы.

Сколько экранов нужно нарисовать?

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

Можно ли отдать макет ИИ, чтобы он сделал код?

Прочитать макет ИИ может: у Maketa есть MCP-сервер, и Claude, ChatGPT, Cursor или VS Code подключаются к нему как к источнику, видят объекты экрана и могут их менять. Но «макет → готовое приложение» одной кнопкой не бывает: код по макету пишет разработчик, ИИ помогает ему, а не заменяет.

Мы уже начали разработку и всё плохо. Поздно?

Нет, и это самый частый момент, когда за макет берутся. Нарисуйте не всё приложение, а только спорные экраны — те, где вы говорите «не так». Разговор с командой сразу перестаёт быть разговором про ощущения.