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

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

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

image

Шаг 1: Определяем участников процесса


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

Энтони отправляет баннеры на проверку трем менеджерам.

Рассмотрим подробнее, кто принимает участие в системе:

  1. Дизайнер — исполнитель задачи. Пусть его работа уже выполнена, но ему важно знать результат: макеты приняли или возвращают на доработку.
  2. Арт-директор — принимает выполненную работу и утверждает ее с менеджером-заказчиком. Ему важно следить за ходом голосования и быстро принимать тактические решения.
  3. Менеджеры — получают готовую работу на утверждение. Им важно понимать, что их просят проверить и как срочно нужно рассмотреть задачу. И, конечно, принять решение с возможностью его прокомментировать.

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

  1. Исполнитель — один или группа людей, на которых назначена задача. Определяется полем «Исполнители» в задаче.
  2. Инициатор — пользователь, запустивший процесс утверждения.
  3. Утверждающий — один или группа пользователей, назначенных на утверждение.

Часто в системе могут быть неявные роли, о которых не стоит забывать. Например, если требуется высылать уведомления о состоянии происходящего процесса, то полезно будет ввести роль «Робот» — сообщения пользователям от лица вашего продукта.
Старайтесь ограничить этот список. Чем сложнее систему ролей вы построите, тем труднее пользователям будет понять, по какой логике она работает.

Шаг 2: Строим таблицу «Событие — Уведомление»


Строим каркас


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

Левая колонка. Сюда будем записывать возможные события в процессе утверждения по ролям. Именно они будут вызывать отправку уведомлений. Не все роли на практике могут влиять на систему. Например, «Исполнитель» в нашем примере является просто наблюдателем, поэтому в левую колонку его можно не добавлять. Итого, получаем три секции:

  1. Инициатор — действия инициатора от запуска утверждения до его окончания;
  2. Утверждающий — принятие решения и комментарии к нему;
  3. Робот — события по состоянию системы.

Верхняя строка. Сюда мы запишем роли, которые должны получать уведомления. На практике используют также разные каналы связи, например, push-уведомления или смс. Для простоты рассмотрим только один канал связи «Входящие» — персональную ленту уведомлений:

  1. Утверждающий
  2. Исполнитель
  3. Инициатор

В левом столбце размечаем поля для событий по ролям. В верхней строке указываем роли и каналы получения уведомлений.
Таблицу удобнее всего вести в Google Sheets. Помимо мощной функциональности ей будет удобно делиться с вашей командой и другими отделами, которым понадобится эта информация. Например, со Службой Поддержки пользователей.

Делитесь ссылкой с правами доступа «Комментирование». Так команда получит возможность обсуждать события в комментариях к ячейкам и никто, кроме вас, не сможет изменить или стереть их.

Заполняем события


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

  1. Выписывайте односложные события, где это возможно. Если поторопиться с группировкой, можно потерять часть простых событий, сразу усложнить формулировки и лишиться наглядности таблицы.
  2. Учитывайте логическую модель системы. Некоторые события, в зависимости от контекста, могут приводить к разным результатам. Например, если мы удаляем последнего утверждающего из активного процесса, помимо события удаления само утверждение должно отмениться.
  3. Не бойтесь дубликатов. Для некоторых ролей события могут повторяться. Например, инициатор и любой пользователь с правами могут изменять дату исполнения. Пусть это увеличит таблицу, но поможет лучше описать систему доступных для всех и уникальных для каждой роли действий.

Заполняем левый столбец всеми возможными событиями по ролям.

Шаг 3: Определяем принципы получения уведомлений


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

В нашей модели утверждения выделим следующие принципы:

  1. Инициатор — получает уведомления о решениях утверждающих и обо всех изменениях, которые кто-либо вносит в его процесс.
  2. Утверждающий — получает уведомления о старте нового утверждения со своим участием и всех значимых изменений процесса.
  3. Исполнитель — является наблюдателем. Узнает о старте утверждения, вынесенных решениях и его окончании.

Запишите эти принципы для каждой роли в строках получателей. Удобно указать их комментариями к ячейкам. С развитием системы принципы помогут держаться одного курса.

Шаг 4: Заполняем уведомления


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

  1. Старайтесь переиспользовать формулировки или их одинаковые части. Так уведомления получатся более консистентными. Если вы делаете международный продукт, это облегчит работу команде локализации.
  2. В строках уведомлений выделяйте переменные данные среди основного текста. Например, «ПОЛЬЗОВАТЕЛЬ: изменил дату исполнения на ДАТА». Так разработчикам будет легче работать с вашими строками.
  3. Не забывайте о правилах хороших уведомлений: краткие формулировки, максимум полезной информации, тон в соответствии с вашим брендом, выбранные принципы получения. Постарайтесь протестировать заранее длину строк в интерфейсе вашего продукта или мобильных пуш-уведомлениях — некоторые формулировки могут сложно считываться или обрезаться многоточием.
  4. Ставьте прочерки там, где уведомления не должны отправляться. Когда проект занимает длительное время, легко запутаться, где вы еще не заполнили таблицу, а где решили, что их не должно быть. Это также снимет вопросы команды.

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

Шаг 5: Дорабатываем события


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

  1. Привести все подобные строки к одному виду. Иногда бывает, что в большом списке одинаковые по смыслу части отличаются: немного разные падежи, предлоги, глаголы-синонимы.
  2. Добавить формулировки для массовых событий, где это возможно, чтобы сократить количество штучных уведомлений. Например, «ПОЛЬЗОВАТЕЛЬ: Добавил в утверждение N файлов»
  3. Добавить новые уникальные строки на замену группам последовательных действий. Например, вместо удаления утверждающих с последующим добавлением других можно сделать событие «Заменил утверждающего с УТВЕРЖДАЮЩИЙ на УТВЕРЖДАЮЩИЙ»
  4. Обсудить все уведомления с командой разработки. Архитектура продукта может не позволить реализовать некоторые ваши идеи, даже если выглядят они просто и логично. Чем раньше вы покажете черновик вашему бэкэнд разработчику, тем больше времени сэкономите в дальнейшей разработке.

Заключение


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

Несколько полезных советов для дальнейшей работы с таблицей:

  1. Для разных сценариев продукта используйте отдельные страницы таблицы. В ней будет легче ориентироваться и находить нужные места.
  2. Проведите команде разработки презентацию. Объясните логику и принципы ее построения. Ответьте на вопросы, чтобы у всех было одинаковое понимание в работе.
  3. Если в вашем продукте работают с уведомлениями другие дизайнеры, внедрите подход и используйте общую таблицу. Так все события сохранятся в одном месте, и будет видна общая картина.

Комментарии (3)


  1. kvAdRaT18
    09.12.2019 16:07

    Спасибо за статью, почти также делаем. Модель действительно усложняется, когда нужно учитывать:
    — способ уведомлений (sms, push, email и пр.)
    — совпадение ролей (например, инициатор и утверждающий)
    — прочие условия (например, если сумма превышает определенный лимит, то дополнительно уведомить кого-то)
    — необходимость уведомлений, когда в системе Пользователь не выполняет никаких событий (например, рассылка напоминаний)

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


    1. Newcss
      09.12.2019 18:07

      А как же — делегирование?) Генеральный поставил задачу начальнику отдела — начальник отдела — начальнику группы — начальник группы — 3-4 подчиненным) и понеслось…
      А эти подчиненные — не видели, не слышали, забЫ(и)ли… Тоже приходится дублировать, менять способ оповещения, иногда даже — прибегать к автоматической постановке задачи на контролирующего…


      1. kvAdRaT18
        09.12.2019 18:16

        При делегировании обычно подпроцесс со своими ролями: Инициатор-Исполнитель. В данном случае дерево подпроцессов. И для нее прописываем логику уведомлений по тому же принципу.

        Но уведомления тут тоже, конечно, можно навертеть — жестко логику зашивать или запрашивать еще у пользователя.

        Зависит от делегирования:
        — с передачей ответственности — когда передал и забыл и не хочешь уведомляться.
        — без передачи ответственности — передал, когда выполнят, вернется и придет новая таска, о которой будешь уведомлен.

        Вобщем-то всегда может быть много условий, от чего зависит матрица. Скорее всего она будет не двумерной.