Scott
Передача макета в разработку должна отвечать на три вопроса: что нужно собрать, как это должно работать и какая версия согласована. Красивого экрана для этого мало. Если не показаны загрузка, ошибка и результат действия, разработчику придётся принимать продуктовые решения по ходу реализации.
В Pixso можно держать макеты, прототипы и пояснения в общем рабочем пространстве. Возможности передачи макетов разработчикам в Pixso помогают посмотреть параметры элементов и подготовить графику. Ниже разберём сам процесс на форме приглашения участника: как связать состояния, компоненты и решения, чтобы команда могла приступить к работе без догадок.
1. Подключите разработчика до завершения макета
Когда дизайнер передаёт файл только в конце работы, разработчик получает результат, но не всегда понимает решения, которые к нему привели. На статичном экране не видно, что произойдёт при медленном ответе сервера, длинном адресе электронной почты или недостаточных правах. Если эти вопросы обнаруживаются во время реализации, приходится возвращаться к уже согласованным экранам.
Обсудите структуру сценария раньше. Для приглашения участника достаточно показать поля адреса и роли, кнопку отправки и место для обратной связи. Разработчик сможет заранее уточнить, какие ответы возвращает сервер, кто имеет право приглашать людей и какие ограничения уже есть в продукте. Дизайнер учтёт их до детальной проработки всех состояний.
Передача в разработку — это продолжающееся обсуждение, а не одно сообщение со ссылкой на готовый файл. Договоритесь, где лежит актуальный макет, где записываются принятые решения и как команда узнаёт об изменениях. Тогда новый вопрос дополняет общую картину, а не создаёт ещё одну версию требований в переписке.
2. Храните макет и пояснения рядом
Отдельные изображения в чате, таблица с размерами и старый прототип быстро расходятся. Выберите одно место, где можно найти текущий экран вместе с пояснениями. В общем файле Pixso команда может обсуждать макет, смотреть прототип и обращаться к параметрам выбранных элементов, не восстанавливая их по снимку экрана.
Панель Handoff показывает свойства слоя: размеры, отступы, заливку и параметры текста. В ней также доступен справочный код стилей; конкретные возможности описаны в руководстве по панели Handoff на английском. Эти данные помогают реализовать внешний вид элемента. Правила отправки запроса, проверки прав и обработки ответа команда определяет отдельно.
Например, у кнопки приглашения разработчик может посмотреть типографику и внутренние отступы. Но по ним нельзя понять, когда кнопка становится недоступной, нужно ли сохранять введённый адрес после ошибки и в какой момент показывать успех. Такие решения добавьте рядом с соответствующим состоянием формы.
После изменения макета сообщите, что именно изменилось и нужно ли уже применять правку в разработке. Обновлённый файл сам по себе не означает, что команда согласовала новую версию для выпуска. Для приглашения это может быть короткое уточнение: «После ошибки сохраняем адрес и выбранную роль; текст ошибки согласован, реализацию можно обновлять».
3. Передайте состояния и причины решений
Покажите, что пользователь видит до действия, во время ожидания, при ошибке и после завершения. Там, где сценарий зависит от отсутствующих данных, добавьте пустое состояние. Подробная разметка размеров не заменяет этих экранов: она объясняет внешний вид, но не последовательность работы.
В нашей форме пользователь вводит адрес anna@example.com и выбирает роль «Редактор». После отправки данные должны пройти проверку на сервере. Для этого сценария согласуем следующие правила:
| Состояние | Что видит пользователь | Что нужно реализовать |
|---|---|---|
| Готовность к отправке | Адрес, выбранную роль и кнопку «Пригласить» | Показать ошибку формата адреса до отправки запроса. Это не подтверждает существование адреса или право пригласить человека. |
| Загрузка | Кнопку «Отправляем…» и индикатор ожидания | На время запроса исключить повторную отправку. Не показывать успех до подтверждения сервера. |
| Ошибка отправки | Сообщение «Не удалось отправить приглашение. Попробуйте ещё раз» и кнопку «Повторить» | Сохранить адрес и роль. Дать повторить действие после завершения неудачной попытки. Ошибку прав или уже существующее приглашение обработать по отдельно согласованному правилу. |
| Успех | Сообщение «Приглашение отправлено» и адрес получателя | Показать результат после подтверждения сервера. Уточнить, что это отправка приглашения, а не подтверждение того, что человек уже вступил в команду. |
Свяжите основные состояния в прототипе, чтобы обсудить порядок переходов. Отдельно поясните, что запускает ошибку, как её закрыть и можно ли повторить действие без потери данных. Если пользователь отменяет действие во время ожидания, команда должна решить, закрывает ли он только окно или действительно отменяет запрос. Один переход в прототипе не определяет поведение сервера.
Сохраняйте рядом и причину нестандартного решения. Если роль нельзя изменить после отправки, разработчику важно знать, что это согласованное ограничение текущего сценария. Пояснение с причиной полезнее, чем общая просьба «сделать как на макете»: оно помогает оценить дальнейшие изменения.
Подготовить состояния формы в Pixso →
4. Свяжите компоненты макета с компонентами в коде
Повторяющиеся кнопки и поля должны иметь понятные имена и согласованный набор состояний. Если одна и та же кнопка каждый раз нарисована заново, разработчику трудно понять, где используется общий компонент, а где нужен отдельный вариант.
Для формы приглашения определите, какие части относятся к общим компонентам поля и кнопки, а какие — к конкретному сценарию. Для поля важны обычное состояние, фокус и ошибка; для кнопки — обычное, недоступное и загрузка. Текст «Приглашение отправлено» относится к результату операции, а не к варианту кнопки.
Согласуйте названия с разработчиком. Например, вариант кнопки «Загрузка» в макете можно сопоставить с состоянием pending в реализации. Само название не принципиально; важно, чтобы по нему обе стороны находили одно и то же поведение. Не нужно переименовывать существующие компоненты проекта ради терминов из отдельной статьи.
То же относится к цветам, интервалам и другим токенам дизайна. Общие названия помогают понять, какое значение используется в макете и в коде. Изменение токена в дизайн-файле не обновляет работающий сайт автоматически: команда отдельно согласует, реализует и проверяет такую правку.
5. Отделите согласованное от того, что ещё нужно решить
Команда должна видеть, какие экраны можно реализовывать, а какие остаются в обсуждении. Положение фрейма на холсте или слово «final» в имени файла не заменяет договорённость. Обозначьте согласованный набор экранов и отдельно оставьте варианты, которые ещё исследуете.
Назовите слои и экспортируемые файлы так, чтобы их можно было найти без помощи автора. Проверьте, открываются ли нужные переходы в прототипе и подготовлены ли используемые иконки и изображения. Открытые вопросы привяжите к конкретному компоненту или состоянию: «что происходит после ошибки прав?» полезнее общей пометки «нужна проверка».
Перед началом реализации пройдите сценарий вместе с разработчиком. Для приглашения проверьте длинный адрес, перевод кнопки на другой язык, отсутствие доступных ролей и недостаточные права. Если приглашать может только администратор, решите, как об этом узнаёт пользователь с другой ролью. Такие условия нельзя надёжно вывести из обычного состояния формы.
Обнаруженный пробел нужно закрыть конкретным решением. Если отсутствует состояние ошибки, добавьте его и согласуйте дальнейшее действие пользователя. Если не определён ответ при повторном приглашении, сначала уточните правило. Набор красивых экранов не становится готовым к разработке от одной отметки в списке.
6. Оценивайте результат по вопросам, которые возникают в работе
Посмотрите, где разработчики всё ещё останавливаются и возвращаются за уточнениями. Если большинство вопросов касается ошибок и переходов, дополнительные размеры не устранят проблему. Если команда регулярно реализует устаревший экран, нужно наладить передачу изменений, а не добавить ещё одну страницу пояснений.
Разберите недавно выпущенную функцию: каких сведений не хватало, сколько времени занимали уточнения и какие ошибки интерфейса пришлось исправлять. Для следующей похожей задачи измените процесс в нужном месте. У формы приглашения это может быть явное описание сохранения данных после ошибки или отдельное подтверждение того, что набор состояний согласован.
Сравнивайте задачи сопоставимого объёма. Меньше повторных вопросов, ожидания ответа и переделок интерфейса — полезные признаки улучшения, но сложность функции тоже влияет на результат. Не приписывайте весь выигрыш одному инструменту или новой форме документации.
Хорошая передача помогает принять следующее решение: какой компонент использовать, какое состояние показать и какое поведение проверить. Держите актуальный макет, прототип и ответы рядом, а сам процесс улучшайте по реальным затруднениям команды.
