88. Правила написания интерфейсного текста

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

Цифровая машина

Тим Шеинер написал о «цифровой машине» — схеме, которая описывает цифровой продукт как совокупность 5 моделей:

  1. Пользователя;
  2. Ценности;
  3. Взаимодействия;
  4. Объекта;
  5. Данных.

Они всегда существуют в виде неосознанных допущений в головах участников проекта. Такие допущения — основной источник неразберихи.

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

2. Модель ценности определяет, каким должно быть первое впечатление о продукте. Её можно представить в виде высказывания:

[Название продукта] — это [категория пользовательского опыта], которая приносит мне [такую-то пользу] и лучше альтернативных решений [по таким-то причинам].

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

3. Модель взаимодействия определяет, как человек меняет состояние цифровой машины: какие данные вводит и какие сигналы обратной связи получает.

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

4. Модель объекта — самая важная, потому что она определяет детали машины и их взаимосвязь.

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

5. Модель данных строится на основе простого принципа — пара имя/значение.

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

Популярные проблемы форм

Андрей Клёц написал о популярных проблемах форм в банковских приложениях:

  1. Отсутствие маски при вводе номера телефона. Используйте маску вида +7 ( ) ___-__-__. Автоматически исправляйте ошибки ввода;
  2. Неинформативные сообщения об ошибках. Плохо, если сообщение содержит технические термины, написано латиницей, находится над или под формой, так что пользователю не ясно, с каким полем оно связано. Хорошо, если указана причина ошибки и способ её устранения;
  3. Неинформативные подсказки. Не стоит повторять в них название поля, писать очевидные вещи и использовать непонятные термины. Полезно объяснить, что означает название поля, в каком формате вводятся данные, сколько символов надо ввести, откуда брать информацию для ввода;
  4. Подсказки и названия полей, которые исчезают после начала ввода. Располагайте подсказки над полем, выносите их в заголовок после начала ввода или показывайте маску ввода;
  5. Отсутствие возможности посмотреть введённый пароль. Его можно показывать временно при нажатии на специальный значок;
  6. Необходимость заполнять поля данными, которые приложение может получить автоматически. Например, определить индекс по адресу;
  7. Некорректное автозаполнение. Его уместно использовать, когда ввод данных занимает слишком много времени, когда пользователь наверняка не станет ничего менять, когда скорректировать ввод можно парой нажатий. Если не уверены, можно предложить пользователю несколько вариантов значений для быстрой подстановки в поле;
  8. Активная кнопка отправки формы при незаполненных полях. Пользователь считает, что форма заполнена верно, и в итоге сталкивается с сообщением об ошибке;
  9. Перегруженная форма (характерно для платежей по квитанциям). Выделите главные поля, ненужные скройте;
  10. Буквенная клавиатура вместо цифровой при заполнении числовых полей (вроде поля «Сумма»).

Правила написания интерфейсного текста

Николай Бабич составил правила написания интерфейсного текста. Наименее очевидные рекомендации:

3. Инструкции начинайте с пользовательской цели. «Нажмите на элемент, чтобы увидеть его свойства» → «Чтобы увидеть свойства элемента, нажмите на него».

5. Будьте последовательны. Если в одной части интерфейса вы назвали процесс «бронированием», не называйте его «резервированием» в других частях.

7. Убирайте лишние глаголы. «Видео было загружено» → «Видео загружено».

8. Пишите в активном залоге. «Кнопку „Поиск“ следует нажать, когда вы будете готовы искать статью» → «Чтобы найти статью, нажмите на кнопку „Поиск“».

9. Пишите числительные цифрами. «У вас два пропущенных звонка» → «У вас 2 пропущенных звонка».

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

14. Если речь о сегодняшнем, вчерашнем или завтрашнем дне, пишите «сегодня», «вчера» и «завтра» вместо даты.

(Самая популярная ссылка в этой подборке, если судить по количеству лайков в ВК.)

Управление табличными данными

Михаил Греков написал об управлении табличными данными и их экспорте.

1. Действия с одной записью:

  • Основное действие можно выполнять двойным кликом на строку, а полный список действий показывать по нажатию правой кнопки мыши. Не годится для тач-интерфейсов. Пример: веб-версия Google Drive;
  • Можно показывать кнопку основного действия, а дополнительные прятать в кебаб-меню. Если поставить кебаб в начале строки, пользователь сразу его заметит при любом количестве столбцов. Пример: панель управления сайтом на Битриксе;
  • Кнопки действий можно показывать при наведении курсора на строку. Минусы: строки мигают, кнопки закрывают часть информации, не годится для тач-интерфейсов. Пример: Gmail.

2. Действия с несколькими выделенными записями:

  • Список действий можно показывать над таблицей (всегда или когда выбраны записи). Пример: WordPress;
  • Список действий для всех выделенных записей можно показывать по нажатию правой кнопки мыши. Минус: пользователю надо как-то рассказать об этом приёме;
  • Выделенные записи можно перетаскивать на нужные действия. Минус: экзотика и для пользователей, и для разработчиков. Пример: Яндекс-почта.

3. Если у записей в таблице есть однородные свойства, работать удобнее, когда можно быстро изменить их для нескольких записей. Пример: Redmine.

4. При выборе нескольких записей удобны:

  • Выбор интервала. Пользователь выбирает 1-ю строку, зажимает Shift и выбирает последнюю строку в интервале. Пример: Gmail;
  • Выбор всех строк. Важно, чтобы пользователь понимал, выбраны вообще все записи или все записи на текущей странице.

5. Редактирование данных непосредственно в строке:

  • Полезно, когда выводятся часто сменяемые свойства (приоритет, статус, ответственный менеджер);
  • Удобно, если при изменении данных не надо вводить причину изменения и т.п.;
  • Требует подсказки: какие данные можно изменить в строке, как перейти к редактированию, как сохранить изменения. Понятнее всего — иконка карандаша для изменения и галка для сохранения.

6. Пользовательский экспорт данных (данные экспортируются для работы с ними в другой системе или передачи другому человеку):

  • Для такого экспорта не годится формат CSV;
  • XLS-файл надо готовить для дальнейшей работы с ним: соблюдать ширины столбцов, форматы данных, выделение шапки и т.п.;
  • Файл надо называть осмысленно с указанием даты и времени экспорта;
  • Дату и время экспорта желательно продублировать перед таблицей на случай отправки её на печать.