- Лонгрид
- 2 просмотра
Интерфейс — только часть пользовательского сценария
Когда работаешь только над макетами, их легко принять за весь пользовательский сценарий. Разбираемся, что происходит до первого контакта с продуктом и где задача заканчивается на самом деле.
Задачка на подумать: нам нужно спроектировать форму отчёта о командировке. Сотрудник вносит траты, прикладывает документы и отправляет всё на проверку.
Довольно простой и линейный флоу с условными четырьмя макетами. Может, чуть больше, чтобы показать состояния компонентов.
Пользователь заполнил поля, приложил чеки и нажал на кнопку. Можно расходиться. Но к первому экрану он приходит, уже успев запутаться, сходить в бухгалтерию, получить деньги и, возможно, сохранить не тот документ.
Когда собираешь сценарий только из макетов, легко принять их за весь путь и не подумать, что происходит за пределами интерфейса.
Давайте немного отойдём от проектирования экранов и посмотрим на задачу целиком: где она начинается и чем на самом деле заканчивается. Можно круто собрать интерфейс, но всё равно решить не ту проблему.
Пользователь ошибётся ещё до входа в продукт или застрянет после отправки формы, а команда будет улучшать место, где ничего не сломалось.
Вот об этом и поговорим.
В нашем примере компания и её правила выдуманы.
Появление формы, когда уже поздно
— Ты едешь в командировку.
— А что мне нужно сделать?
— Сходи в бухгалтерию, там расскажут.
Сотрудник ни разу не был в командировке. Он не знает, сколько денег получит, когда они придут, на что их можно тратить, какие документы сохранять и как потом отчитываться.
Отдельного онбординга на такой случай нет. Корпоративный портал есть, но сотрудник ни разу не пользовался сервисом командировок и не понимает, с чего начать.
В бухгалтерии объясняют общий порядок. Что-то подсказывает коллега в курилке: он уже ездил и вроде знаком с местными обычаями. Так сотрудник собирает процесс по частям — у тех, кто доступен и кому доверяет.
В итоге он получает аванс, едет в командировку и тратит деньги, а для подтверждения сохраняет то, что кажется достаточным. После возвращения создаёт отчёт и прикладывает файл, но бухгалтерия не принимает расход: нужен другой документ.
Когда мы проектировали форму, всё предусмотрели: яснее описали правила, добавили пример и объяснили причину отказа. Кажется, сотрудник сам виноват — не прочитал. Только форму он увидел уже после поездки, когда сохранять нужный документ было поздно.
Корппортал не знает о поездке
В нашем примере требование к документу должно было доехать до пользователя ещё до поездки. Его может прислать руководитель, бухгалтерия или сам сервис. Тут не так важен канал, как момент.
Допустим, человека назначили в командировку. В системе появляется поездка, а ему приходит уведомление. Внутри — сумма, сроки, правила расходов и требования к документам.
Но кто сообщит об этом системе? Сотрудник, руководитель и бухгалтер в курсе, а заявки всё ещё нет. Сведения разбросаны по документам, 1С и переписке.
Если автоматического сигнала нет, создать поездку в системе может бухгалтерия или сам сотрудник — смотря кто раньше узнал и готов действовать. Иногда достаточно просто договориться об этом. В других случаях придётся связать инструменты между собой.
Не нужно автоматизировать каждый шаг. Для начала достаточно понять, откуда продукт узнаёт о поездке, кто запускает процесс и кто должен действовать дальше.
Вот и всё. Четыре макета никуда не делись, но теперь видно, что происходит вокруг них. Не нужно затаскивать всё это в интерфейс: общение с бухгалтером может остаться как есть. Дизайнеру важно учесть этот шаг, иначе человек попадёт в форму неподготовленным.
Отчёт отправлен?
Форма пишет: всё готово, друг. Но пользователь всё ещё не знает, примут ли документы, нужно ли что-то исправить и не придётся ли доплатить из своих.
В нашей истории путь заканчивается после того, как бухгалтерия приняла отчёт. Остаток аванса возвращён, от сотрудника больше ничего не ждут.
И только тогда его наконец отпускает: да всё ок, иди уже, от тебя больше ничего не нужно.
Получается, макеты показывали только середину пути.
Что проверить в своём сценарии
Такую проверку лучше делать, когда собрана черновая цепочка экранов, а детали полировать ещё рано.
Сначала найдите момент, когда у человека появилась задача. Потом — событие, после которого она действительно закончилась. Между ними отметьте действия вне продукта.
Не нужно рисовать всё, о чём пользователь думает и что делает. Оставьте только внешние шаги, которые меняют проектное решение.
В итоге останется несколько важных точек. Для каждой запишите: что происходит, почему это мешает и что с этим делать.
| Вопрос | Описание |
|---|---|
| Когда у человека появилась задача? | Что случилось до первого экрана? В какой момент ему впервые понадобилось что-то понять или сделать? |
| Что человек делает вне продукта? | С кем разговаривает, где ищет правила, какими ещё инструментами пользуется? Возможно, причина будущей ошибки находится именно там. |
| У кого сейчас следующий шаг? | После действия пользователя работа пошла дальше или повисла? Тот, кто должен продолжить, вообще знает об этом? |
| Когда человек может забыть об этой истории? | Какое событие подтверждает, что задача действительно закончилась и от человека больше ничего не ждут? |
Не каждый разрыв требует нового экрана. Иногда достаточно изменить текст или статус, передать данные раньше или поправить сам процесс. В нашем примере правила нужны до поездки, а человек видит их после. Значит, информацию нужно передать раньше — до траты денег и выбора документов.
Четыре макета не обязательно превратятся в сорок. Но если не посмотреть, что происходит до первого и после последнего, можно спроектировать только середину.
