David Cronin из дизайн-бюро Cooper рассказывает как они в своих проектах пытаются избегать ситуации бесконечных утверждений дизайна и пляски вокруг цветовой гаммы и двух иконок.
В целом идея сводится к тесной работе с клиентом и вовлечение его представителей в процесс дизайна. Таким образом они
избегают спирали переделок, замечаний не по делу, предосуждений, вкусовых предпочтений и невыгодных компромиссов.
Предлагаемые практики:
— |
Выделение роли коммуникатора дизайна - человека, который будет объяснять остальным в чем заключается смысл
предлагаемых решений. |
— |
Работа с правильными людьми - на этапах процесса вовлекаются только те клиентские работники, которые реально
необходимы. Гендир не должен обсуждать иконки, а менеджер - ключевые бизнес-моменты. |
— |
Планирование и расписание - если клиент будет видеть как его действия влияют на сроки и стоимость, он подумает о своем поведении. |
— |
Сотрудничать часто и рано - клиент должен быть вовлечен в процесс дизайна как можно раньше. |
— |
Выстраивать собрания вокруг определенных решений - необходимо не просто давать поглядеть клиенту на дизайн,
а предоставить перед ним проблему и потребовать ее разрешение. |
— |
Ключевые люди заказчика должны быть проинтервьюированы как можно раньше. |
— |
Нужно использовать персоны и сценарии - для постановки проблем и задач на собраниях нужно использовать
персоны - собирательные образы пользователей сайта, которых может быть несколько с разными параметрами. Соответственно, персоны должны выполнять определенные сценарии. Они так же должны быть разработаны на
основе наблюдения за реальными пользователями, а не быть полностью выдуманными. |
— |
Сначала надо определить проблему, а потом обсуждать решение. Часто все происходит ровно наоборот, что
и влечет к "смертельной спирали" бесконечных обсуждений. |
— |
Разрабатывать визуал постепенно. У Cooper есть специальный стиль, который они используют для составления
"чертежей". Этот стиль заключается в отсутствии стиля, чтобы клиента не заклинило на оформлении. |
— |
Быть готовым выкинуть свою работу. Не нужно стоять на защите своего решения просто потому что вы его
придумали. Если оно не решает проблемы, его нужно выкинуть. |
Вот полная версия статьи Early and Often: How to Avoid the Design Revision Death Spiral