75. Зачем и как писать ФС

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

Материалы Проектората

Антон Григорьев рассказал о функциональных спецификациях к интерфейсу: зачем нужны и как их писать.

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

На записи плохо видно слайды, ссылка на презентацию есть в описании видео.

Интересные статьи

Рохан Мишра написал про универсальный (инклюзивный) дизайн — создание продуктов и сред, которые доступны людям независимо от их возраста, инвалидности и факторов вроде сломанной руки, беременности и т.п.

На примере двери:

  • Размещение дверной ручки не слишком высоко для ребёнка и не слишком низко для взрослого;
  • Автоматическое открытие — лучше открытия двери с помощью ручки;
  • Ширина — достаточно большая для людей на инвалидных колясках.

Принципы:

  • Проектировать так, чтобы пользователь с ограниченными возможностями не испытывал дискомфорта от «особого отношения»;
  • Обеспечивать гибкость, чтобы пользователь мог контролировать темп и точность использования;
  • Передавать информацию разными способами: изобразительными, словесными и тактильными;
  • Допускать ошибки: минимизировать вред и неблагоприятные последствия, которые могут возникнуть из-за непреднамеренных действий;
  • Уменьшить физические усилия, необходимые для взаимодействия;
  • Дать больше пространства для манипуляций.

Илья Бирман на нескольких примерах объяснил принцип «дай нажать».

Например, пользователь должен указать хотя бы 1 способ уведомления из 4. Если он выключает 3 чекбокса, нельзя блокировать оставшийся 4-й включённый чекбокс. Надо дать возможность выключить и его тоже. При этом система может автоматически включить один из трёх ранее выключенных чекбоксов.

Или при выборе даты: «Чтобы не дать пользователю ввести несуществующую дату, некоторые разработчики убирают из поля дня несуществующие дни. То есть если выбран месяц июнь, то дня «31» просто не будет в выпадайке. Но что, если у меня день рождения 31 августа? Я хочу ткнуть в 31, а потом выбрать август. Дай нажать!»

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

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

Кстати, можно присоединиться к обсуждению этого принципа в ВК.

Павел Шерер написал об использовании состояния потока для увеличения времени пребывания пользователя на сайте или в мобильном приложении.

Состояние потока обычно свойственно играм. Чем оно характеризуется:

  • Игрок понимает игровые механики и максимально контролирует ситуацию внутри игры;
  • Оказывается полностью погружен в процесс, начинает жить своим персонажем;
  • Теряет чувство времени.

Как поддержать это состояние не в игровых проектах:

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

Неопубликованное

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

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

Они делали это по своей инициативе. Я считал, что это будет проявлением недоверия к словам менеджера, и не просил показывать платёжки. Но так считать неправильно.

Менеджеры проектов обычно не занимаются оплатами. Они передают счета в бухгалтерию, где им говорят: «Сегодня оплатим». Менеджеры уверенно сообщают об этом подрядчикам.

Однако, может так случиться, что бухгалтерия забывает про счёт, теряет его или переносит оплату на послезавтра. Когда проходит 4 дня, и денег от заказчика всё ещё нет, вам с менеджером приходится тратить время на решение этого вопроса. А проект стоит.

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

(Заметка из моего личного телеграм-канала «Френч-пресс».)

Рассылка Проектората × UX Notes

Технологии цифрового маркетинга — книга, где я был соавтором (параграф про создание сайта) и литературным редактором (привёл текст к единой стилистике и упростил формулировки). От 250 рублей.