Для асинхронного дизайн-ревью нужны конкретная версия работы, несколько ясных вопросов, срок ответа и человек, который решит, как учесть обратную связь. Передайте всё это вместе. Попросите участников указывать обозначенную часть дизайна и объяснять, какую проблему пользователя они видят. После завершения ревью опубликуйте принятые решения.
Это полезнее, чем отправить ссылку с вопросом «Что думаете?». На общей доске для визуальной совместной работы можно собрать задание, схему, вопросы и комментарии. Люди смогут участвовать в разное время, не восстанавливая контекст по переписке.
Выбирайте вопросы, которые можно разобрать самостоятельно
Асинхронный формат подходит, когда материалы понятны без устного объяснения, а у участников есть время изучить их до ответа. Он особенно полезен для поиска пропущенных состояний в сценарии, проверки формулировок относительно задачи пользователя и выявления неучтённых зависимостей.
Короткий разговор в реальном времени лучше, если участники не могут договориться о самой проблеме, решение срочное или письменное обсуждение порождает новые недоразумения. Цель — полезное ревью, а не отказ от любых встреч.
Уточните, собираете ли вы критические замечания или запрашиваете официальное согласование. Набор комментариев не означает одобрения, а молчание — согласования. Заранее назовите того, кто принимает решение, и обязательных участников. Более общие принципы обратной связи описаны в руководстве по обсуждению дизайна на английском языке.
Составьте задание до отправки ссылки
Рассмотрим условную команду, которая проверяет сценарий отмены подписки. Дизайнер хочет понять, ясно ли пользователю, что будет дальше, и может ли тот продолжить действия при ошибке отправки запроса. Ревью касается взаимодействия и текста интерфейса, а не устанавливает правила отмены подписки компании.
| Поле | Пример |
|---|---|
| Версия | Сценарий отмены подписки, версия для ревью R2. Экраны C1–C4. |
| Задача пользователя | Отменить подписку и понять, успешно ли выполнен запрос. |
| Вопрос 1 | Может ли пользователь на C3 отличить отправленный запрос от завершённой отмены? |
| Вопрос 2 | Если отправка на C2 не удалась, понятен ли путь повторной попытки с сохранением намерения пользователя? |
| Рамки | Состояния сценария и тексты интерфейса. Фирменный стиль и коммерческие условия здесь не определяются. |
| Участники | Дизайн, разработка, поддержка и человек, уполномоченный подтверждать соответствие формулировок утверждённым правилам. |
| Срок ответа | Согласованные дата, время и часовой пояс завершения. Укажите, к кому обратиться, если участник не успевает. |
| Ответственный за решение | Руководитель продукта обобщает отзывы вместе с дизайнером; неясные формулировки правил передаются уполномоченному ответственному. |
Такое задание не даёт участникам оценивать разные задачи. Разработчики проверяют состояния ошибок, поддержка замечает типичные недоразумения, а ответственный за правила подтверждает, соответствует ли предложенный текст утверждённым условиям.
В своём рассказе об асинхронном обсуждении дизайна Erin Casali подчёркивает значение точных вопросов и явных контрольных точек обсуждения. Пример выше применяет эти идеи к одному ограниченному ревью, а не предлагает оценивать весь постоянно меняющийся продукт.
Не меняйте версию во время ревью
Если дизайнер правит сценарий по мере поступления комментариев, один участник может указать на проблему уже удалённого экрана, а другой — ответить о новом. Тогда несоответствие версий будет выглядеть как разногласие.
Пометьте материалы как R2 и сохраняйте их неизменными в согласованный период. Это могут быть экспортированные экраны или отдельно обозначенная копия нужной части дизайна. Рядом оставьте ссылку на исходный проект, но укажите, какую версию следует комментировать. Создание отдельной копии — решение команды; сама метка не устанавливает программную блокировку.
Если необходимую правку нельзя отложить, отметьте, что изменилось, и сообщите участникам, нужна ли ещё их обратная связь. Не подменяйте материалы незаметно, считая, что все комментарии автоматически относятся к новой версии. После ревью обозначьте обновлённое предложение как R3 и опишите изменения.
Просите наблюдения, которые помогают принять решение
Полезный комментарий указывает место, проблему и причину её важности. Предлагаемое решение тоже приветствуется, но должно быть отделено от самой проблемы.
Место: C3, заголовок подтверждения.
Наблюдение: Заголовок сообщает, что подписка отменена, а сообщение ниже — что запрос ещё обрабатывается.
Последствие для пользователя: Человек может уйти, считая отмену завершённой.
Предложение: Использовать заголовок ожидания, пока система не подтвердит завершение.
Такой отзыв конкретнее, чем «страница подтверждения какая-то неправильная»: он выявляет противоречие состояний. При этом разработчики ещё должны подтвердить, что именно известно системе на этом шаге, а уполномоченный ответственный — проверить текст.
Попросите отличать наблюдаемое противоречие от предположения или личного предпочтения. «Мне больше нравится короткий заголовок» можно обсудить, но это не равнозначно пропущенному состоянию ошибки. Командная обратная связь помогает выбрать, что проверить, но не заменяет сведения от людей, использующих продукт.
Разбирайте противоречивые отзывы относительно одного вопроса
Не считайте комментарии голосами. Два участника могут предлагать противоположные изменения, потому что решают разные проблемы. Прежде чем выбирать действие, ещё раз сформулируйте общий вопрос.
| Отзыв | Стоящее за ним опасение | Что делать |
|---|---|---|
| «Сократите C3, сообщение слишком длинное». | В плотном абзаце человек может пропустить основной статус. | Изменить иерархию, чтобы статус был заметным, затем оценить необходимость пояснений. |
| «Добавьте больше объяснений на C3». | Человек может не понимать, что происходит, пока запрос ожидает обработки. | Оставить необходимое пояснение следующего шага под статусом. Краткость совместима с ясностью. |
| «Измените правила, чтобы отмена происходила сразу». | Участник хочет другого условия обслуживания. | Передать предложение об изменении правил отдельно. Не обещать в интерфейсе то, что не утверждено или не реализовано. |
| «Повторная попытка на C2 может создать дублирующий запрос». | Дизайн может скрывать технический сбой. | Уточнить поведение у разработчиков. Не закрывать решение о затронутом сценарии до ответа. |
В первых двух случаях не нужно выбирать победителя. Третий вопрос выходит за полномочия этого ревью. Четвёртый может препятствовать реализации предложенного взаимодействия. Если воспринимать всё как просьбы отредактировать экран, эти различия потеряются.
Организуйте пространство ревью в Boardmix
Поместите задание в начальной области доски. Ниже расположите сценарий: готовые материалы дизайна или простую последовательность фигур и соединительных линий. Дайте каждому состоянию видимое обозначение, например C1 или C2, чтобы на него можно было точно сослаться.
Два вопроса для ревью разместите возле соответствующих частей сценария. Рядом с каждым оставьте область для отзывов, а уточнения прикрепляйте к работе в комментариях. Запись может содержать ссылку вроде «C3 · ожидание», даже если обсуждение идёт в другом канале.
Выделите отдельную область решений с заголовками «Изменить», «Исследовать» и «Оставить, объяснив причину». Ответственный переносит туда отзывы или их выводы после прочтения. Boardmix предоставляет общий холст и комментарии; сроки, напоминания и решения определяет команда.
До отправки приглашения попросите одного участника проверить доступ к доске, читаемость задания и возможность оставить отзыв нужным способом. Укажите точное время завершения и в приглашении, и на доске. Если обязательный участник не может присоединиться, договоритесь об ином порядке, не принимая его отсутствие за одобрение.
Покажите итог вместе со следующей версией
По окончании срока соберите изменения и открытые вопросы. Для нашего примера итог может быть таким:
- На C3 ожидающий запрос будет отличаться от завершённой отмены.
- Пояснение следующего шага останется под основным статусом.
- Поведение повторной попытки на C2 ожидает ответа разработчиков.
- Предложение изменить коммерческие условия передано ответственному и не входит в текущее согласование дизайна.
Представьте обновлённые материалы как R3 и свяжите каждое значимое изменение с соответствующим вопросом. Запрашивайте повторное ревью только там, где действительно нужен новый ответ; не заставляйте всех перечитывать неизменённые экраны. Поздний комментарий о серьёзной ошибке заслуживает внимания, а новое предпочтение может подождать следующего подходящего обсуждения.
Для начала откройте Boardmix и подготовьте один вопрос о чётко обозначенной части работы. Дайте достаточно контекста, чтобы участники могли ответить без вашего присутствия.
