Неконструктивная критика дизайна: кто виноват и что делать?

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

Вольный перевод статьи Rachel Krause от 30 мая 2021 года nngroup.com

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

• высокое качество дизайна
• согласованность целей проекта и дизайна
• дает прямые ответы на нерешенные вопросы по дизайну
• раннее сотрудничество членов команды с заинтересованными лицами

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

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

• Гипотетические сценарии: ситуации, которые не подтверждены данными или спор ради спора («Если бы я был адвокатом дьявола…»)
• Обратная связь, которая не помогает или не требует каких-то конкретных действий: личное мнение о дизайне или об элементах, на которые дизайнер не сможет повлиять.
• Вопросы не по теме или преждевременные вопросы: вопросы, не имеющие отношения к обсуждаемому дизайну или заданные слишком рано в процессе проектирования.

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

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

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

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

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

Важно понять, почему эти сценарии всплывают во время разбора:

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

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

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

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

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

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

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

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

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

Перед началом разбора дизайна, установите, какого рода фидбэк вы ожидаете, например:

• соответствует ли дизайн целям пользователя
• соответствует ли дизайн бренду и тону сообщений
• конкретные вопросы по содержанию
• общее восприятие визуального дизайна

Такое руководство по обратной связи позволит аудитории дать вам полезный отзыв на основе ваших потребностей.

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

Полезно сортировать список по 3 категориям:

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

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

• нет согласованности целей и задач проекта
• нет ясных рекомендаций по обратной связи
• в комнате не те люди (или доминирующие личности)
• дизайнеры изолированы от остальной команды или у них непрозрачный процесс проектирования

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

• Предложите место/способ для сбора вопросов. Парковки вопросов ведут встречу в нужном направлении и напоминают о поднятых темах. Не забудьте следить за развитием этих тем!
• Вовлекайте команду и заинтересованных лиц в дизайн-процесс. Это позволит не только собрать больше идей и лучших идей, но и синхронизирует людей в лексике, процессах и артефактах.

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

Ссылка на оригинальную статью nngroup.com

#design #дизайн #обратнаясвязь #критика #неконструктивнаякритика

Лайк, шер, репост и конструктивная критика приветствуются 😉