Scott
Scott

Опубликовано 06.10.2026, обновлено 06.10.2026

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

Форма создания командного пространства и отдельные состояния отправки, ошибки и подтверждённого результата

Определите задачу формы и правила для каждого поля

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

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

ПолеНазначение и элементПравило и примерКто определяет правило
Рабочая почтаИдентификатор учётной записи; поле emailОбязательное; в этом примере нужен адрес с полным доменом, содержащим точку, например alex@studio.comКоманда системы входа
ПарольУчётные данные; поле пароляОбязательное; длину и ограничения задаёт политика безопасности продуктаСпециалисты по безопасности
Размер командыНастройка первого знакомства с продуктом; один вариантОбязательное; 1, 2–10, 11–50 или 51+Команда продукта
Страна или регионРегиональные настройки; выбор из списка с поискомОбязательное; одно поддерживаемое значениеКоманда, отвечающая за доступность сервиса
ИнтересыПодбор подсказок; независимые флажкиНеобязательное; UI-дизайн, прототипы, дизайн-системыКоманда знакомства с продуктом
Условия использованияСогласие; отдельный флажокОбязательное в данном сценарии; изначально не отмечено; рядом ссылка на условияОтветственный за условия сервиса

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

Соберите структуру и первый макет в Pixso

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

В Pixso создайте широкий и узкий фреймы. Добавьте группы в одинаковой последовательности, разместите кнопку «Создать пространство» после согласия, а рядом с кнопкой предусмотрите область статуса. За пределами фреймов оставьте заметки со ссылками на строки таблицы требований. Человек, который просматривает файл позже, должен понимать причину появления каждого поля.

Для исследования вариантов можно воспользоваться AI Design. В обзоре Pixso AI на английском описано создание редактируемого интерфейса по запросу. Сформулируйте запрос с конкретными полями и состояниями:

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

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

Разделите подпись, значение, подсказку и ошибку

Начните с компонента рабочей почты. Постоянная подпись «Рабочая почта» остаётся видимой после ввода. Заполнитель name@company.com показывает формат, но не заменяет подпись. Подсказка нужна, только если она уточняет требование: например, «Укажите адрес, которым пользуетесь на работе». Не повторяйте в ней название поля.

По правилу из таблицы адрес alex@studio не подходит для этой регистрации. Сообщение должно объяснять исправление: «Введите адрес в формате name@example.com». Оставьте введённое значение на месте, чтобы человек мог дописать его, а не вводить заново. Красная рамка привлекает внимание, но сама по себе не говорит, что делать.

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

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

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

Используйте Auto Layout — автоматическую компоновку — для вертикальной группы из подписи, элемента ввода и сообщения. При переносе ошибки группа должна расти вниз и сдвигать следующий элемент. Назовите отступы и состояния, чтобы они не зависели от случайных значений в отдельных фреймах. AI Smart Layout может помочь с компоновкой подходящего выделения, но не применяется к одному слою или Section и не заменяет уже заданный Auto Layout. AI Smart Rename предлагает понятные имена для подходящих слоёв и не перезаписывает названия, заданные пользователем. Отдельные фигуры, векторы и текстовые слои, экземпляры компонентов и вложенные в них слои, а также скрытые и заблокированные слои не переименовываются. Проверьте предложенные имена по правилам команды.

Выберите момент проверки и путь исправления

Не объявляйте адрес неверным, пока человек ещё печатает. Для нашего примера проверка запускается при продолжении или отправке. Если введено alex@studio, форма сохраняет этот текст и показывает конкретную ошибку. После исправления на alex@studio.com сообщение исчезает после повторной проверки, а не просто после любого нажатия клавиши.

Рекомендации GOV.UK по проверке форм на английском предлагают возвращать форму с введёнными данными: ошибочное значение тоже нужно сохранить, чтобы его можно было исправить. Для секретов действует отдельное правило. Пароль может оставаться только в рамках текущего защищённого взаимодействия; при истечении сессии или смене контекста безопасности может потребоваться очистка. Не сохраняйте пароль или платёжные данные в постоянном хранилище ради общего требования «ничего не терять».

Когда проверятьКогда это помогаетКогда стоит отложить или изменить проверку
Во время вводаПоказывать длину текста или выполнение требований к паролю, не объявляя незавершённый ввод ошибкойЧеловек ещё не успел закончить значение
После ухода из поляЛёгкая проверка даёт полезную подсказку и не мешает вернуться к редактированиюРезультат зависит от другого поля, формат ещё меняется или основной сценарий проверяет всё по кнопке
По кнопке продолжения или отправкиПроверить обязательные поля, согласие, связанные значения и готовность к запросуВместо указания конкретных полей появляется только общее «Что-то не так»
После ответа сервераПроверить уникальность адреса, права и правила, которые определяет сервисИнтерфейс раскрывает внутренние коды, стирает исправляемый ввод или показывает успех до подтверждения

Далее нужны три состояния всей формы. При отправке оставьте видимыми несекретные данные, покажите «Создаём пространство…» и предусмотрите защиту от повторного запуска запроса. При ошибке сервиса объясните результат: «Не удалось создать пространство. Попробуйте ещё раз». При подтверждённом успехе покажите «Пространство создано» и следующий шаг. Не заменяйте ответ сервера зелёными отметками возле полей.

Исправление почты ведёт к отправке; ответ сервера разделён на ошибку с повтором и подтверждённое создание пространства

Сообщение должно быть доступно и без визуального наблюдения за экраном. W3C описывает уведомления формы на английском, включая связь ошибки с полем и объявление результата вспомогательным технологиям. Эти требования нужно передать разработчику вместе с макетами.

Опишите поиск в списке и зависимые поля

Поле «Страна или регион» должно вести себя как выбор значения. Ввод фильтрует варианты; клавиши со стрелками перемещают фокус по доступным пунктам, Enter выбирает пункт, Escape закрывает список. Отдельно опишите отсутствие результатов, очистку и текст, который не соответствует ни одному поддерживаемому значению. Ориентир для реализации — паттерн combobox W3C на английском. Если список короткий и поиск ничего не упрощает, используйте более простой элемент.

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

В нашем примере значение размера команды «51+» открывает необязательное поле «Название компании». Разместите его сразу после размера команды. В реализации изменение должно быть понятно пользователям вспомогательных технологий. Если человек возвращается к «2–10», заранее определите судьбу введённого названия: сохранить его на время текущего заполнения или очистить по согласованному правилу. Если очистка уничтожит полезный ввод, объясните последствие до неё.

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

Сохраните смысл на телефоне и при работе с клавиатуры

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

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

В мобильном макете сохраняйте порядок полей и предусмотрите подходящие типы экранной клавиатуры. Фиксированная кнопка не должна перекрывать согласие или сообщение об ошибке. На широком экране ограничьте ширину формы, чтобы короткий ввод не растягивался на весь экран. Проверьте длинный email, сообщения на нескольких строках, масштаб 200% и более длинные переводы. Если продукт поддерживает языки с письмом справа налево, для них нужна отдельная проверка порядка и выравнивания. AI Smart Text может помочь подготовить варианты текста, но итоговые требования и формулировки должны оставаться согласованными с задачей.

Свяжите шесть состояний в прототип

На холсте Pixso подготовьте шесть фреймов: «01 Начало», «02 Ошибка почты», «03 Можно отправлять», «04 Отправка», «05 Ошибка сервиса», «06 Пространство создано». Используйте одинаковые данные во всех состояниях. Так видно, что именно изменилось, а не кажется, будто каждый экран относится к новому пользователю.

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

В Pixso рядом с формой из шести полей показаны отправка, ошибка сервиса с повтором и подтверждённое создание пространства
Путь повтора возвращается к отправке. Экран успеха появляется в сценарии только после подтверждённого ответа.

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

Спроектировать состояния формы в Pixso →

Передайте правила вместе с макетами и кодом

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

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

Для кодовой части можно использовать Design to Code. В руководстве Pixso по D2C на английском описаны режимы Design Mode и Dev Mode, выбор React, Vue, HTML, ArkUI или Flutter, настройки выбранного формата, выбор фреймов или слоёв, генерация, просмотр структуры проекта и загрузка пакета. В Design Mode также описана оптимизация макета, а Dev Mode сосредоточен на просмотре и выводе кода. Выбирайте формат вместе с разработчиком, исходя из реального проекта.

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

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

Наверх
Поделиться в X
Поделиться в Facebook