Анализ методики проектирования: ошибки, ситуации и полезные выводы из них

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

Как можно больше говорите с клиентом на этапе сбора информации

Я разделял (и частично разделяю сейчас) мнение о том, что у клиента проектом часто руководят бездарные или неготовые к этому люди, но это вовсе не означает, что с ними не надо разговаривать. Больше информации о бизнесе/проекте клиента, чем у него самого, нет ни у кого; даже если он маркетолог, описывающий свою аудиторию как «25-50 лет, мужчины».

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

Возложите ответственность за полноту и качество сбора информации на клиента

Ни в коем случае не берите эту ответственность на себя, если у вас нет штата исследователей и аналитиков как у Gallup. Поскольку мы — просто проектировщики, мы должны анализировать и интерпретировать; клиент в любом случае знает больше нас: у него есть данные, статистика, материалы, эксперты, клиенты.

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

Маркетинг, позиционирование — полностью ответственность клиента

Я наивно полагал, что могу подсказать клиенту что-то по позиционированию, и из этого выйдет толк. Да, я могу подсказать, но чаще всего это: а) не принимается клиентом, потому что он «лучше знает»; б) глупость, потому что клиент действительно лучше знает.

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

Ставьте клиента в неудобное/трудное положение

На этапе сбора информации крайне эффективными показали себя неудобные (даже невежливые) вопросы. Например:

• Ваши менеджеры по продажам не могут ответить, за счёт чего они убеждают клиента купить товар. А вы знаете?
• Похоже, у вас нет никакого позиционирования и конкурентных преимуществ. Что будем говорить посетителю, чтобы он выбрал вас, а не конкурента?
• Ваши цены на товары больше конкурентов, доставка дороже и дольше, сервис не предлагает moneyback. Почему вы думаете, что у вас кто-то что-то купит?

Просто удивительно, как хорошо в этот момент начинает работать голова клиента. Стыдно и хочется поскорее всё исправить?

Эскизы необходимы!

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

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

• Выглядеть как черновик и тем самым не давать ни малейшего повода подумать, что это дизайн;
• Чётко отражать логику и содержание, причём с реальным контентом, а не Lorem ipsum!

Отдельно хочу сказать про модные интерактивные прототипы. Наш опыт говорит: интерактивный прототип в 99% проектов — потеря времени. Понимания он не сильно добавляет, а времени на создание и редактирование требует в разы больше. К тому же, он не очень отвечает требованию «выглядеть как черновик», потому что слишком складный.

В эскизах прорабатывайте логику, а не внешний вид

Это крайне важное замечание, потому что я видел ошибку «оформления» у коллег и сам её совершал. Упор на логике позволяет:

• Сфокусировать клиента именно на ней, а не на размере логотипа и цвете ссылок;
• Снизить время на создание эскизов;
• Донести максимум информации до клиента и дизайнера;
• Дать дизайнеру определённую свободу в оформлении и интерфейсных решениях.

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

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

Описывайте логику после эскизов

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

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

Тестируйте эскизы

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

Проектировать вдвоём — лучше всего

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

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

Добивайтесь понимания от клиента

Убеждайтесь, что клиент понял все важные решения (не обязательно принял). Концепцию, каждую идею и эскиз нужно объяснять, а не просто высылать и, дождавшись реакции вроде «да вроде всё нормально» или нескольких непонятных правок, с облегчением вздохнуть и перейти к другой задаче. Большинство клиентов (пока) не сталкивались с проектированием и не понимают его смысл и значимость, в чём их нельзя винить. Сделали концепцию — облеките её в вид простой презентаций и лично, или, в крайнем случае, по скайпу, представьте её с подробными объяснениями, почему сделано именно так, а не иначе. Так же с эскизами.

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

Не грузите клиента технической информацией

Старайтесь превращать технические описания в человеко-понятные. Вместо «CMS содержит функциональность по редактированию сущности «Новость» со следующими полями: 1) title, 2) description…» напишите «Панель управления должна позволять редактировать заголовок и содержание новости». Так вы добьётесь большего понимания и вызовете меньше раздражения; слова «desription» и «title» вовсе не показывают ваш профессионализм, как многие думают, а просто бесят.

Не мучайте женщин

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

Это противоречит пункту «Добивайтесь понимания»? Да. Но мой опыт показал, что пользы от пытки клиента — как от козла молока: мозг нашей милой клиентки отключается и начинает реагировать абсолютно неадекватно. Так что если начинаете проектирование с женщиной по ту сторону, будьте готовы брать ответственность за решения на себя.

Убедитесь, что клиент способен реализовать решения

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

Это касается даже банальных новостей: если у клиента они будут появляться раз в полгода, то не нужно закладывать в проект раздел «Новости» с выводом ленты на главную страницу, правда? Или если у клиента нет хорошего писателя, то несколько наивно делать ядром проекта блог/статьи.

Давайте рекомендации к созданию контента

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

Не делайте больше двух проектов одновременно

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

Берите в работу «одинаковые» проекты, но не одновременно

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

Решительное «Нет!» клиенту-дизайнеру

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

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

Выводы

В статьях принято делать выводы. Он у меня один и довольно очевидный: никогда не думайте, что вы делаете всё правильно, замечайте, признавайте, анализируйте и исправляйте свои ошибки.

В следующей статье я предложу быстрый и эффективный способ сделать концепцию (сайта или сервиса). Я сознательно пропускаю этап сбора информации, потому что о нём почти всё сказано тут: habrahabr.ru/company/kelnik/blog/155003/.