Как оценивать дизайн и давать обратную связь

Прием задач и предоставление обратной связи — неотъемлемая часть рабочего процесса.

Чтобы объективно оценить работу дизайнера, необходимо учитывать определенные факторы. Также при этом важно давать корректный фидбэк. В этой статье мы говорим о том, как это сделать.

Оценка дизайна

Чтобы правильно оценить дизайн, стоит ответить на следующие вопросы:

• Какая цель была поставлена в задаче? Для чего выполнялась задача?
• Есть ли метрики, позволяющие понять, что задача выполнена успешно?
• Для кого предназначена функциональность? Какой сегмент пользователей будет с этим работать? Обладают ли пользователи необходимыми знаниями и навыками для этого?
• Проводились ли исследования или планируются ли относительно участков, которые вызывают сомнения? Если вы не уверены в каких-либо моментах, сформулируйте гипотезу.

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

В B2B-Center при постановке задач в Jira мы используем чек-лист, который составили на основе наработок Юрия Ветрова.

• Цель задачи

Для чего проектируется функциональность? В чем ценность для бизнеса и для заказчика?

• Измерение

По каким критериям будет понятно, достигнута ли цель? Как будут измеряться улучшения?

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

• Целевая аудитория

Роли пользователей, их социально-демографические характеристики и т.д. Чем полнее срез пользователей, тем эффективнее можно отслеживать действия этих групп. Если у вас есть персоны, приложите их.

• Обоснование

Подробное описание проблематики/боли или потребности пользователей. Выкладки из аналитики и результаты исследований, который натолкнули на понимание проблемы, ссылки на конкурентов.

• Дополнительные исследования

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

• Дополнительная информация

Если уже существуют страницы, на которых требуются изменения, можно их приложить.

• Предполагаемое решение

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

• Для новых крупных разделов или продуктов

Прикрепляется ссылка на доску в Miro с описанием проекта, бизнес-процесса, целей, метрик, task-flow, примерами и другими схемами, которые помогут проектированию решения.

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

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

• Внедрение

Нужно ли провести частичное внедрение на определенной группе пользователей для проверки решения (А/Б тестирование)? В какой срок будут предоставлены реальные результаты и проведена ретроспектива по задаче? Будет ли осуществляться проверка качества решения проблемы после его внедрения в продукте?

• Ограничения и контекст

Связанные задачи в Jira, пересечения с другими рабочими группами, технологические и временные ограничения (блокеры).

Корректная обратная связь

Как быть, если задача выполнена не совсем верно или вы не согласны с решением?

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

Самое главное — высказывать факты или гипотезы, а не делиться оценочными суждениями.

Например, мне доводилось слышать фразу: «Отвратительное поле ввода». Вместо этого лучше сообщить, что именно не нравится и в чем существует риск: «Я считаю, что поле ввода работает неочевидно — непонятны ограничения по вводу символов».

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