Если ты менеджер или аналитик и продумываешь форму обратной связи на сайте...

то знаешь, что форма — один из ключевых элементов сайта, на который возлагаются большие надежды в плане конверсии. Делюсь инсайдерской заметкой со всем, что мне пригодилось при создании форм на сайтах. Здесь нет ничего про UI (это работа дизайнера) и количество шагов формы (работа продакта), но выписаны все логические аспекты, которые нельзя потерять менеджеру и аналитику. Часто именно они готовят задачу для разработчиков, и в ней должно быть описано все.

Это подсказка для руководителя проекта (РП) и аналитика, которые представляют команду заказной разработки и уточняют задачи клиента. Если вы сами клиент – вам тоже может пригодиться, просто не задерживайте внимание на агентских формулировках.

Размещаю скриншотами по частям, так как в редакторе vc нет подходящего функционала. Кому нужно текстом – напишите, пришлю.

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

Пользователи могут попробовать загрузить что-то другое (часто удивительное). На этот случай нужен текст ошибки. Примеры:

“Недопустимый формат файла. Допустимые форматы прикрепляемых файлов: doc, rtf, pdf, ipg, jpeg, png, bpm, gif”.

“Файл превышает допустимый размер. Максимальный размер прикрепляемых файлов 5 Мб”.

Это технические примеры, перепишите на человеческий под tone of voice своего проекта.

Дополнительный интерфейс к загрузке файлов – Drag-and-drop и предпросмотр.

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

Если объектов несколько, то может потребоваться слайдер.

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

Актуально для проектов, где десктоп в приоритете.

Чтобы форма была доступна с клавиатуры, нужно правильно расставить tabindex и добавить состояния фокуса у элементов формы – у инпутов и кнопок. О таких требованиях нужно сообщить разработчику отдельно, по умолчанию это вряд ли будет сделано.

Решение выбирается в зависимости от целей проекта.

Рекомендуется убирать пробелы в начале и в конце полей: имя, фамилия, почта, чтобы данные не сохранялись в БД с пробелами. Один из способов реализации – оставлять пробел визуально и удалять его при отправке данных на бек.

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

Например, для проектов на Vue/Nuxt можно использовать вот этот валидатор. Для нативных JS проектов можно использовать zod.

Собраны здесь.

Придерживаемся не всего, а только необходимого, иначе будет сложно/дорого.

А вот мой любимый пример антиUX и антиUI в игровой форме, попробуйте пройти его разок от начала до конца. Его показываю всем, кто не знает, что такое UX ⚡️⚡️⚡️

Пример декомпозиции для задачи на форму в рамках проекта с обычной версткой:

Для отдельных стеков декомпоз может отличаться, какой использовать – может решить аналитик, тимлид или менеджер, если у него достаточно технических знаний.

Считаю, что и это менеджер тоже должен знать.

В настоящее время электронные адреса передаются третьим лицам без согласия, так как в законодательстве четко не указано, что они являются (или не являются) персональными данными.

РКН придерживается такой позиции:

Но была еще позиция от Минцифры (чем-то схоже с РКН):

В общем, сейчас это небольшой пробел в законодательстве.

Если сильно обобщить, то ПД – информация, по которой можно идентифицировать конкретного человека.

В общем и целом, подходить к данному вопросу всегда нужно индивидуально.

1. Если есть возможно рассмотреть электронную почту заранее, то исходя из имени почтового ящика – брать / не брать.

2. Если это какая-то анкета, где видно только по итогу всю информацию, которую заполнил человек, то лучше брать согласие.

На каждом проекте, где есть форма, стоит спросить клиента, есть ли у него юрист. Пусть лучше он принимает решение. Или сам клиент. А мы просто должны обладать знаниями и давать рекомендации, но не принимать решение за клиента.

Как вы могли заметить, это не повествовательная статья, а заметка с подсказками. Сколько работаю – вижу в процессе разработки, что что-то забыли на уровне постановки задачи. А тут собрано все, что надо обдумать при постановке задачи. Здорово, если это поможет кому-нибудь.

Если что-то забыто или неточно написано – поделитесь, обновлю)

Если кому-то нужно текстом – могу прислать.

Всем продуманных форм и хороших конверсий🙃