UX форм, с которыми работают

Меня зовут Михаил Греков. Я работаю менеджером продукта Velvica — платформа для автоматизации бизнеса по продаже облачных сервисов. До Velvica я руководил проектами в компании по заказной разработке (2007–2018). Работал в основном с системами для бизнеса и госсектора (b2b, b2g).

Пишу на medium Михаил Греков, веду канал в Telegram @proudobstvo — про UX, продуктоводство и саморазвитие.

У меня есть серия статей на тему “UX таблиц, с которыми работают”. Статьи про то, как создавать таблицы, с которыми пользователю будет удобно работать в течение рабочего дня.

Но таблицы — это часть основного рабочего процесса. Вторая весомая часть — формы с данными.

Эта статья посвящена формам, с которыми пользователь сможет эффективно работать в течение рабочего дня.

Акцентирую — именно формам, с которыми работают. Не формы регистрации или сбора обратной связи — там правила немного другие.

Статья авторская, не перевод и не пересказ — это то, с чем мне приходилось сталкиваться в рабочей практике.

В статье не про дизайн, а про здравый смысл — все макеты в статье представлены лишь для демонстрации идей, а не как варианты конкретного UI.

В работе с формами есть три основных этапа:

• Добавление новой формы
• Редактирование существующей формы
• Просмотр информации в существующей форме

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

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

Основное правило компоновки — форма должна быть уютной.

Сразу, конечно, вопрос — что же такое уютная форма? Уютная форма — это как уютный гардероб:

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

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

Табуляция — это когда по форме перемещаются с помощью кнопки Таб, то есть не используют мышку/тач.

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

Это не всегда не так. Почти правильный порядок табуляции ставится автоматом, но есть элементы на форме, которые его ломают.

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

Если пользователь заполняет форму с помощью табуляции — ему важна скорость и предсказуемость переходов, а всякие ссылки это ломают.

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

Например, Битрикс24 — интерфейс добавления сделки. Есть поле Ответственный, в котором аватар и Имя — ссылки на профиль пользователя. Табуляция идёт по аватару, потом Имя+Фамилия , а потом спускается ниже в “Дата начала”. При этом пропускается единственно важный элемент в поле “Ответственный” — Сменить.

Глобально каждая форма может находиться в двух состояниях — состояние просмотра и состояние редактирования.

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

Чаще режим просмотра не нужен, но если решили делать, то:

• Не делайте режим просмотра как заблокированный режим редактирования — это не просмотр, а ограничение в действиях. Т.е. блокировать элементы целесообразно, когда у пользователя прав не хватает, а не когда он на просмотр открыл.
• Не стоит полностью совмещать режим просмотра и редактирования. Например, можно сделать инлайн редактирование: наводишь или кликаешь на поле и оно превращается в редактируемое. Это удобно, но при условии, что есть отдельный режим редактирования — когда оператор может редактировать масштабно, а не кликать по каждому полю. Например,в Битрикс24 есть и поштучный режим редактирования, и массовый — удобно:

• Кому-то из пользователей важнее редактирование, кому-то просмотр. Например, для руководителя форма может по умолчанию открываться в режиме просмотра, а для работяги — в режиме редактирования. Это можно предусмотреть заранее на уровне прав доступа.

Я не зря поместил сюда мой стишок-пирожок про Колю. Современные масс-сервисы толкают нас в сторону автосохранения: например, Гугл-Диск и приложения на нём, или тот же Medium автоматом сохраняет публикацию в процессе написания.

Если есть возможность — делайте автосохранение.

Что учесть при режиме с автосохранением:

• Нужна контекстная история изменений: кто, когда, с каких и на какие менял данные. Если пользователь где-то ошибся и заметил это через время, то ему могут потребоваться прежние данные для восстановления. Кстати, версионность, когда можно откатиться к какой-то сохранённой версии, делать не обязательно. Часто пользователям достаточно найти прежние верные данные и внести их — поддерживать для этого версионность слишком дорого.
• Режим автосохранения должен быть выдержан по всей системе. Нельзя делать автосохранение для части форм — надо делать для всех.
• Пользователь должен регулярно получать информацию о том, что данные сохранены. Необходимо сделать индикатор, который будет показывать, что данные сохраняются и сохранены. Этот индикатор должен быть всегда в зоне видимости (не оставаться вверху при скролле).

• Автосохранение должно срабатывать не только на потерю фокуса (при переходе от поля к полю). Например, могут быть текстовые поля на форме, в которые пользователь будет вбивать приличный объём текста. Если сохранение работает на фокусы, то пока пользователь не закончит текст и не уйдёт с поля, сохранение не сработает. Это плохо — может произойти что угодно в процессе написания большого текста. Фокусное автосохранение необходимо подстраховать, например, автосохранением при бездействии — если пользователь замер на 3–5 секунд, то сохраняем в это время.
• Автосохранение заменяет только ручное сохранение, а не жизненный процесс формы. Может потребоваться кнопка, которая будет переводить запись из состояния “Черновик” в состояние “Я закончил создавать эту запись”.

Если автосохранение не сделали, то помогите пользователю не потерять введённые данные:

• Не делайте короткие сессии для работы с системой.
• При попытке закрыть форму с несохранённой информацией — уведомляйте пользователя об этом.

Что надо сделать с полями:

• Пометить обязательные поля. Кстати, обязательность полей и режим автосохранение немного конфликтуют между собой, но об этом чуть ниже.
• Выбрать адекватные размеру и формату информации поля ввода. Если количество символов ограничено, то хорошо показывать счётчик оставшихся символов.
• Не показывать редактируемые поля, как заблокированные для ввода. Бывает так, что поля на первый взгляд плохо отличимы от фона или выглядят заблокированными.
• Сразу показывать требования. Все форматы и ограничения должны быть ясны до заполнения.
• Проверять введённые данные по факту заполнения, а не отправки. Если форма с автосохранением, то иначе и нельзя. Но ругаться на неверные данные необходимо только после того, как они будут окончательно предоставлены: по потере фокуса или при бездействии.
• Показывать все ошибки сразу, а не делать из этого квест. Если автосохранения нет и поля всё же валидируются не по мере заполнения, то по нажатию на кнопку проверяется вся форма сразу: ищутся ошибки во всех полях сразу, а не по-одному.
• Показывать адекватные ошибки. Сообщения об ошибке появляются около поля с ошибкой и указывают на причину возникновения ошибки и на то, как ее исправить.
• Всё, что можно, заполняйте автоматически. Например, индекс по адресу, реквизиты по ИНН, адреса доставки на основании истории и т.д.
• Используйте автоформатирование данных. Например, для телефонов, чисел и прочих данных, которые удобнее воспринимаются в отформатированном виде. Ниже подробнее.
• Не прятать названия полей. Если название поля размещено внутри поля и исчезает при вводе, то пользователи начинают сомневаться, а ту ли информацию они вводят.
• Помнить, что поля с телефонными номерами часто нуждаются в поле-напарнике “Чей номер” (или “Кого спросить”, или “Примечание”). Если поля-напарника нет, то часто пользователи пишут прямо в поле “+7–988–567–77–66 Оля, звонить до 19.00”.
• Копировать популярные поля одним кликом. Если на форме есть поля, которые пользователи часто копируют (например, телефон контрагента), то сделайте для таких полей копирование в один клик. Например, поместить иконку копирования рядом с полем.

Для начала определим, что обычно бывает в подсказках:

• Расшифровка названия.
• Формат данных или пример заполнения.
• Информация о том, как данные будут использоваться.
• Где взять данные, которые надо ввести.

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

👉 Будет лучше, если текст подсказки можно будет скопировать — пользователь может обратиться за помощью с заполнением поля к коллеге (например, актуально для бухгалтерско-юридических данных).

👉 В формах для регулярной работы подсказки лучше делать вызываемыми. Например, через клик по вопросу рядом с полем. Пользователь может заполнять формы по 100 раз на день, и показывать ему подсказку всякий раз, когда он пришел в поле — лишнее отвлекающее мелькание. К тому же, если делать подсказку вызываемой, тогда и вопрос с копированием текста подсказки решается проще.

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

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

Для каких полей точно пригодится автоформатирование:

• Числовые поля: разделяйте разряды чисел пробелами, так пользователю легче не ошибиться с нулями в числе.
• Номера документов: разделяйте так, как номер выводится на документе. Пользователю легче сверить такой номер.
• Дробные числа: воспринимайте в качестве разделителя целого от дробного и точки, и запятые.
• Телефонные номера: сами ставьте скобки и дефисы в номер. Пользователь как правило такую информацию копирует и вставляет — форматирование надо приводить в порядок самим налету.
  Отдельная проблема поля с номером: вставляют в формат +7 (или другой код страны), а дальше ожидают, что пользователь впишет оставшуюся часть номера. Но пользователь копирует и вставляет весь номер, включая +7. В итоге, последняя цифра номера обрезается — если не заметил, то номер неверный.

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

Если автосохранение сделали — то режим черновика по-умолчанию должен входить в комплект, иначе как же сохранять, когда не всё обязательное заполнено.

Если автосохранения нет, то позвольте пользователю сохранять форму в любой момент.

Отдельно стоит предусмотреть возможность найти все формы-черновики: или поиск по статусу сделать, или в отдельный пункт меню складывать. Черновики должны быть отделены от рабочих данных.

Порой важно на форме цветами выделять статусы или какие-то иные данные, имеющие понятную цветовую градацию. Я писал, что важно выделять такие данные в таблицах — в формах тоже важно, так как она может быть открыта по ссылке.

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

По этой же причине ключевые статусы порой важно обновлять налету: изменился статус/поступили новые данные — форма говорит об этом пользователю, а не ждёт пока он сам обновит и увидит. Например, имеем дело с системой электронного документооборота: пользователь открыл карточку документа и планирует с ним ознакомиться. В это время документ отменяют — не прошёл согласование. Если форма изменит статус и уведомит пользователя о новом состоянии, то он не будет тратить время, а пойдёт дальше.
Например, gmail уведомляет о поступлении нового письма в переписке, если ты смотришь переписку:

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

Удобнее, когда новое значение в справочник можно добавить прямо из формы: например, добавив в список пункт-действие “Новое значение”. Как реализовать добавление нового значения — уже детали:

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

Но суть в том, что пользователь не уходит с формы, а решает вопрос на месте.

Не требуйте лишнего от пользователя при работе с картинками и фотками:

• Не требуйте загружать картинки определённого размера. Если картинка большая, сами пропорционально обрежьте. Если нужна пропорция — предложите кроп.
  Если картинка очень маленькая — тогда просите другую, так как растягивать нельзя.
• Используйте перетаскивание для загрузки. Если картинку нельзя просто перетащить на нужное место на форме, то интерфейс — старьё.
• Упрощайте пакетную загрузку. Если можно/нужно загрузить сразу несколько картинок, то должна быть возможность выделить несколько и перетащить на место загрузки. Загружать по одной — старьё.
• Поддерживайте вставку картинок из буфера. Редактор должен поддерживать вставку картинок из буфера (сделал скриншот и нажал “Вставить”). Если, например, в поле комментарий на форме можно вставить картинку, то должна быть возможность её вставить из буфера, не выбирая среди файлов. Иначе — старьё.

Постарайтесь забыть о требованиях к изображениям

Любое неприятие графического файла по причине: не тот тип файла, не тот размер — это минус в UX-карму системы.

Ограничения типа:

• Размер изображения должен быть сколько-то пикселей.
• Размер файла столько-то байт.
• Изображение должно быть квадратным.
• Мы принимаем только png и jpg, а у вас gif.

для многих пользователей просто непобедимы.

Современные технологии позволяют сжать, переконвертировать, показать кроп и избавить пользователя от неловкости и разочарования, что у него картинка неправильная.

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

Если форма — это часть веб-системы, то хорошо, если на неё будет персонализированная ссылка.

Что может быть в этой ссылке:

1. алиас со значимым полем формы, а не только ID. Например,

обычно: domain.name/contragents/562316589

удобно: domain.name/contragents/ooo-roga-i-kopita-562316589

по ссылке с алиасом сразу ясно куда она ведёт (плюсы человекопонятных URL можно не рассказывать, думаю).

Единственное, надо сделать так, чтобы при смене алиаса ссылка тоже работала — технической основой для перехода должен оставаться ID (так работают ссылки на Medium).

2. Ссылка также может содержать адрес конкретного таба, на котором должна открыться форма:
ещё удобнее: domain.name/contragents/ooo-roga-i-kopita-562316589#comments

3. Через правильный адрес можно даже к конкретному полю отмотать, но, возможно, это уже лишнее 🙂

У меня на этом всё, спасибо за внимание! Если было полезно/интересно, то поддержите статью хлопками 👏 — и мне приятно, и рейтинг растёт.

👉 Поле за 12 миллионов долларов — заметка USABILITYLAB о лишнем поле на форме. Когда его убрали — стали получать на 12 млн. $ больше.

👉 Чек-лист создания таблиц, с которыми работают — формат чек-листа: Гугл-Таблицы (Эксель от Гугл). Кому будет полезно — берите за основу. В чек-листе 65 требований и ссылки на теоретическую базу. Требования касаются как дизайна, так и разработки/тестирования.

Скоро выйдет чек-лист создания форм, с которыми работают. Если тема вам интересна — подписывайтесь на мой medium Михаил Греков и канал в Telegram @proudobstvo.