Два года назад мы серьёзно продумывали организацию наших процессов работы по дизайну. Хотели в 100% случаев с первого раза попадать в ожидания заказчика.

Квантовый скачок — это момент между тем, когда все-все-все уже обсуждено, запрототипировано, согласовано, пробрейнштормлено — и тем, когда дизайнер показывает миру свой первый (пусть даже еще и не полностью готовый) макет страницы.

Все, что делается до этого — это попытка прицелиться. Все, что после — попытка компенсировать недолет или перелет.

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

Я потратил довольно много времени на то, чтобы построить формальный процесс дизайна в своей компании. Сейчас будет целый ПАФОСНЫЙ АБЗАЦ по этому поводу. Мы постоянно совершенствуем его на ретроспективах. Мы систематически применяем брейнштормы и креативные методики. Мы аккуратно собираем образы и строим визуальный бриф. Мы готовим скетчи и прототипы и вовлекаем заказчика на самых ранних этапах. У нас построена многоступенчатая процедура тестирования макетов на живых людях до демонстрации макета заказчику. Мы придумываем фишки и готовы обосновать почти каждый пиксель по дизайну. У нас все лучше и лучше с процессом демонстрации результатов (например, кроме этого процесса у нас появился invision — могу порекомендовать систему). Одна инфографика по этому процессу занимает 5 экранов :).

То, о чем вас просит заказчик, и то, что ему нужно — это разные вещи

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

Однако теперь я могу с уверенностью сказать, что даже фанатичное следование хорошему процессу не гарантирует попадания в струю на 100%.

Культ карго в IT не работает. А особенно — в дизайне ;)

Я анализировал причины и среди ключевых смог выделить:

• Изменчивость требований. Пока вы рисуете — у заказчика что-то меняется. И вы узнаете об этом последним.

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

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

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

• Высокая вариативность. Если нужно нарисовать белую собаку — у сотни дизайнеров будет сто разных белых собак с сотней разных оттенков белого. Причем все они будут немного не такими, как это представлял себе менеджер проекта, менеджер заказчика и сам заказчик. Мы на своей стороне принимаем множество конкретных решений, которые невозможно согласовать до получения готового результата (конкретность этих решений подтверждена тем, что конкретные пиксели стоят на конкретных местах :) ). К счастью, в большинстве случаев нам не нужно досконально угадывать образ, который вертится в голове у клиента. Он может там и не вертеться.

Что делать

Изначально задать верное функциональное направление

Правильный процесс сбора требований и анализа бизнес-задачи, применение метода персон — эти методики помогают нам в выборе верного функционального направления в начале работы. Однако все идет насмарку, если вы правильно брифуете не тех людей. Брифуйте самого главного босса — каким бы загруженным он ни был. Босса могут попытаться «спрятать», но прямой контакт с ним — это добро для проекта. Или вы серьезно думаете что, например, сайт Тинькова обошёлся без его личного участия?

Собрать «карту эмоций» проекта

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

Вовлечь дизайнера на стадии прототипирования

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

Экспериментировать с требованиями. Больше грязных прототипов!

Мокапы, скетчи, прототипы, набросок маркером на доске или карандашом на салфетке — это значительный прорыв по сравнению с 5-ю листами формального ТЗ.

Иногда доказывать на словах, что требования клиента несуразны — сложно и муторно, поскольку не хватает базы аргументов. «Так никто не делает» или «это будет плохо смотреться» или «у нашего дизайнера другое виденье» — не аргументы, а фуфло. Да и бессмысленно что-то доказывать: наша задача — получить правильный продукт.

Один из подходов — сначала сделайте макет именно так, как этого просит заказчик (дословно). Затем сделайте как надо. Сохраняйте промежуточные макеты, чтобы пояснять весь процесс перехода от «как просили» до «как надо». Это почти всегда работает на вас.

Сформируйте в голове клиента понимание дальнейшей работы — расскажите о своих процессах.

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

Тестировать дизайн

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

А вот исключить «квантовый скачок» и непрерывные изменения «картинки» в голове заказчика не способны даже самые правильные процессы.

Скажу с уверенностью, что применение нашего систематизированного процесса по дизайну увеличило количество макетов, принимаемых сразу, до 91% (за полгода из 24 макетов всего 2 пришлось фундаментально переделывать). Тем не менее, разработка, полагаясь на одни процессы (из которых создан культ карго) стопроцентной гарантии результата не дает. Нужно иметь «чуйку», умение договариваться и маневрировать по бюджету и срокам... или решимость отказаться от проекта, если найти общий язык с клиентом так и не удалось.

Оригинал: http://blog.sibirix.ru/2013/07/08/cargo-cult-in-webdesign/

Алексей Бородкин
Руководитель отдела аналитики и проектирования в Notamedia

Спасибо Владимиру за статью!

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

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

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

Мы боремся с «квантовым скачком» следующим образом — мы переплетаем работу аналитика и дизайнера максимально тесно, так что к работе над сайтом они приступают фактически вместе; кроме того, аналитик активно привлекается и на стадии разработки и согласования дизайна.

Во многом такой подход диктуется внутренней идеологией qb interactive, которая ставит во главу угла аналитику — аналитик выступает мозговым центром всей разработки и в разной степени привлекается на всех этапах — как при проектировании, так и непосредственном воплощении.

Если говорить конкретно, то процесс «стыковки» аналитика и дизайнера выглядит примерно следующим образом:

1. Аналитик собирает всю нужную информацию о клиенте и его отрасли, после чего в общих чертах набрасывает структуру сайта и, в идеале, наскоро рисует скетчи ключевых страниц.
2. Аналитик отправляется к арт-директору и вкратце (sic!) рассказывает ему о бизнесе клиента, его целевой аудитории и сути готовящегося проекта, а также показывает ему скетчи, если они есть. После этого арт-директор берет время на подумать (а иногда и не берет).
3. Арт-директор снова встречаются с аналитиком и вместе набрасывают визуальную концепцию, не вдаваясь при этом в излишние детали — они будут проработаны в дальнейшем. Эта концепция носит исключительно внутренний характер и клиенту не показывается, но служит краеугольным камнем всей дальнейшей разработки.
4. Аналитик пишет техническое задание на сайт в соответствии с разработанной совместно с арт-дизайнером концепцией и прописывает все возможные детали и подробности.
5. Далее начинается создание скетчей/прототипов. Интересно, что они могут создаваться разным людьми: в том случае, если основная смысловая нагрузка сайта лежит на дизайне (например, сайт представляет собой какой-нибудь одностраничник со сложным параллаксом и сюжетом), то прототип рисуется арт-директором; в том случае, если сайт относительно прост или обладает сложным функционалом, прототипы делает аналитик, но его работа в любом случае будет отдельно обсуждаться с арт-директором перед показом клиенту.
6. ТЗ и прототипы презентуются клиенту и сопровождаются предупреждением, что они отражают лишь контентное и функциональное наполнение страниц и приоритет различных элементов страницы и что дизайн в итоге может отличаться; по итогам презентации прототипов собирается обратная связь и вносятся правки. Самое главное, что происходит на этом этапе — клиент получает первое представление о проекте, причем настолько предварительное, что оно навряд ли вступит в противоречие с его ожиданиями, но повлияет на его ожидания и правильно подготовит ко встрече с итоговым дизайном.
7. Одобренные прототипы с ТЗ отдаются в дизайн, при этом разработка дизайна происходит под присмотром аналитика, который должен следить за тем, чтобы итоговый дизайн-макет соответствовал и ТЗ, и исходным условиям (задачам, целевой аудитории и т.п.).
8. Дизайн-макет согласовывается с клиентом, все довольны.

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