Последний раз я писал статью о проектировании в 2011 году. Тогда я собирался написать гораздо больше, но подумал: «Методика есть, но она не проверена временем, клиентами и проектами. Какого беса я буду писать о ней?». И не стал. Прошло два года, за которые мы с командой спроектировали полсотни разных проектов: корпоративные сайты и каталоги товаров, личные кабинеты, системы управления, сервисы, посадочные страницы, мобильные приложения. Многое поменялось: у меня есть статистика, данные по конверсии, отзывы пользователей и клиентов, сделано и исправлено много ошибок в методике и процессе. Теперь можно и написать.
Начну с обзора этих ошибок и выводов за последние два года. Надеюсь, это будет вам полезно. Отдельно надеюсь получить отклики из вашего личного опыта.
Как можно больше говорите с клиентом на этапе сбора информации
Я разделял (и частично разделяю сейчас) мнение о том, что у клиента проектом часто руководят бездарные или неготовые к этому люди, но это вовсе не означает, что с ними не надо разговаривать. Больше информации о бизнесе/проекте клиента, чем у него самого, нет ни у кого; даже если он маркетолог, описывающий свою аудиторию как «25-50 лет, мужчины».
Задавая правильные вопросы, можно узнать много полезного для проектирования. Потом, когда вы сообщите ваши выводы клиенту, он будет очень благодарен и станет использовать их в своей работе (если не дурак).
Возложите ответственность за полноту и качество сбора информации на клиента
Ни в коем случае не берите эту ответственность на себя, если у вас нет штата исследователей и аналитиков как у Gallup. Поскольку мы — просто проектировщики, мы должны анализировать и интерпретировать; клиент в любом случае знает больше нас: у него есть данные, статистика, материалы, эксперты, клиенты.
Возлагая ответственность на клиента, вы поступаете правильно, не потому, что снимаете её с себя, а потому что клиент по определению больше вас заинтересован, чтобы вы получили максимум полезной информации и сделали правильные выводы. Вот пусть он и обеспечит это, а вы будете думать и принимать решения. Архитектор бизнес-центра не делает замеры почвы и не анализирует поток потенциальных клиентов, правда?
Маркетинг, позиционирование — полностью ответственность клиента
Я наивно полагал, что могу подсказать клиенту что-то по позиционированию, и из этого выйдет толк. Да, я могу подсказать, но чаще всего это: а) не принимается клиентом, потому что он «лучше знает»; б) глупость, потому что клиент действительно лучше знает.
Я понял, что лучшее, что я могу сделать — это помочь клиенту сформулировать позиционирование, но никак не исправлять и, тем более, создавать его. В конце концов, это его бизнес, и пусть каждый занимается своим делом и несёт свою ответственность.
Ставьте клиента в неудобное/трудное положение
На этапе сбора информации крайне эффективными показали себя неудобные (даже невежливые) вопросы. Например:
- Ваши менеджеры по продажам не могут ответить, за счёт чего они убеждают клиента купить товар. А вы знаете?
- Похоже, у вас нет никакого позиционирования и конкурентных преимуществ. Что будем говорить посетителю, чтобы он выбрал вас, а не конкурента?
- Ваши цены на товары больше конкурентов, доставка дороже и дольше, сервис не предлагает moneyback. Почему вы думаете, что у вас кто-то что-то купит?
Просто удивительно, как хорошо в этот момент начинает работать голова клиента. Стыдно и хочется поскорее всё исправить?
Эскизы необходимы!
Это один из главных выводов, который я для себя сделал. Они помогают самому понять и продумать логику и содержание, клиенту — вообще понять, что вы предлагаете, а дизайнеру — понять, что делать. Слова, много слов, майндмэпы — это всё плохо работает без визуализации.
У меня была гипотеза, что эскизы обрывают полёт мысли дизайнера, ограничивают его тем, что он видит, а клиента заставляют относиться в дизайну как к раскраске эскиза. К счастью, это чаще всего не так, но тут многое зависит от качества эскиза и его подачи. Эскиз должен быть эскизом, т.е.:
- Выглядеть как черновик и тем самым не давать ни малейшего повода подумать, что это дизайн;
- Чётко отражать логику и содержание, причём с реальным контентом, а не Lorem ipsum!
Отдельно хочу сказать про модные интерактивные прототипы. Наш опыт говорит: интерактивный прототип в 99% проектов — потеря времени. Понимания он не сильно добавляет, а времени на создание и редактирование требует в разы больше. К тому же, он не очень отвечает требованию «выглядеть как черновик», потому что слишком складный.
В эскизах прорабатывайте логику, а не внешний вид
Это крайне важное замечание, потому что я видел ошибку «оформления» у коллег и сам её совершал. Упор на логике позволяет:
- Сфокусировать клиента именно на ней, а не на размере логотипа и цвете ссылок;
- Снизить время на создание эскизов;
- Донести максимум информации до клиента и дизайнера;
- Дать дизайнеру определённую свободу в оформлении и интерфейсных решениях.
Ни в коем случае не отдавайте логику полностью дизайнеру (я совершал эту ошибку неоднократно, к сожалению). Да, он — специалист по интерфейсам и оформлению, но логику проекта и характеристику пользователей (персонажей) лучше знаете вы. И именно вы знаете, что выделить, какие формулировки будут более понятными и так далее. Пусть каждый делает своё дело.
То, что я только что сказал, не означает, что дизайнера не надо слушать. Очень даже надо, но он не должен определять логику проекта — только исправлять ошибки и помогать сделать лучше.
Описывайте логику после эскизов
Да, раньше я думал, что надо описать всю логику, а потом сделать по ней эскизы. Сейчас понял, что эти процессы идут параллельно, и лучше сначала определить ключевые моменты (концепция, общая структура), проработать детали на эскизах, а потом всё это описать.
Это же касается сценариев. Проектирование подробных сценариев до структуры и эскизов не дало (мне) видимых положительных результатов, поэтому сейчас я набрасываю общие сценарии, показывающие, как мыслит пользователь, а потом по готовым эскизам делаю описание конкретных сценариев его поведения. Почему это хорошо? Потому что общий ход мысли пользователя помогает определиться со структурой, коммуникацией и акцентами в интерфейсе, а сценарии, написанные по эскизам, помогают проверить ваши решения в деле.
Тестируйте эскизы
Показывайте эскизы потенциальным пользователям, с которыми вы проводили интервью на этапе сбора информации, и проверяйте ваши решения на предмет полноты информации и логичности её донесения. Это ещё не сайт, в эскизах нет интерактива, но они всё равно помогают увидеть, понятна ли пользователю организации информации, язык, на которым вы с ним говорите, дальнейшие действия (целевые).
Проектировать вдвоём — лучше всего
Проектирование в одиночку лишает вас ценного взгляда со стороны (клиент не всегда помогает, потому что бывает крайне пассивен и ждёт первых картинок). Проектирование втроём — это лебедь, рак и щука. А вот проектирование вдвоём позволяет и посмотреть на задачу с разных сторон, поспорить конструктивно и подстраховать, если что.
Лучше всего объединять немного разных по стилю проектировщиков — например, отлично проектирующего коммуникацию/контент и более склонного к работе с интерфейсами. Если попробуете свести совсем разных, не договорятся.
Добивайтесь понимания от клиента
Убеждайтесь, что клиент понял все важные решения (не обязательно принял). Концепцию, каждую идею и эскиз нужно объяснять, а не просто высылать и, дождавшись реакции вроде «да всё нормально» или нескольких непонятных правок, с облегчением вздохнуть и перейти к другой задаче. Большинство клиентов (пока) не сталкивались с проектированием и не понимают его смысл и значимость, в чём их нельзя винить. Сделали концепцию — облеките её в вид простой презентации и лично, или, в крайнем случае, по скайпу, представьте её с подробными объяснениями, почему сделано именно так, а не иначе. Так же с эскизами.
Этим вы сэкономите всем время и нервы, с большей вероятностью добьётесь понимания и согласования правильных решений. Если не сделаете этого, будете заново проектировать, но уже на этапе создания дизайна или, что ещё хуже, программирования. Минус деньги, время и репутация, потому что виноваты именно вы.
Не грузите клиента технической информацией
Старайтесь превращать технические описания в человеко-понятные. Вместо «CMS содержит функциональность по редактированию сущности «Новость» со следующими полями: 1) title, 2) description...» напишите «Панель управления должна позволять редактировать заголовок и содержание новости». Так вы добьётесь большего понимания и вызовете меньше раздражения; слова «desription» и «title» вовсе не показывают ваш профессионализм, как многие думают, а просто бесят.
Не мучайте женщин
Не знаю точно почему, но женщины-менеджеры хуже переносят кропотливый процесс проектирования, когда вы заставляете их проверять каждое слово в описании логики и каждый элемент интерфейса. Зато у них много других плюсов: конструктивность, желание найти общий язык, меньше самодурства и упрямства (перечислил явно не всё).
Это противоречит пункту «Добивайтесь понимания»? Да. Но мой опыт показал, что пользы от пытки клиента — как от козла молока: нашей милой клиентки отключается и начинает реагировать абсолютно неадекватно. Так что если начинаете проектирование с женщиной по ту сторону, будьте готовы брать ответственность за решения на себя.
Убедитесь, что клиент способен реализовать решения
В проекте можно придумать, что угодно — видеопрезентацию, крутую систему рекомендаций, аналитику действий пользователей в 56 разрезах. Но что от этого толку, если у клиента нет времени и ресурсов на это? Предлагая решения, обязательно проверяйте, что клиент сможет их реализовать и поддерживать.
Это касается даже банальных новостей: если у клиента они будут появляться раз в полгода, то не нужно закладывать в проект раздел «Новости» с выводом ленты на главную страницу, правда? Или если у клиента нет хорошего писателя, то несколько наивно делать ядром проекта блог/статьи.
Давайте рекомендации к созданию контента
Даже если у клиент есть способности и ресурсы для создания и поддержки задуманного вами контента — блога, новостей, отчётов о событиях — дайте ему рекомендации, как это делать: задачи, размер, содержание, стиль. В их отсутствие клиент будет писать чёрт знает что (примеры приводить не буду, потому как это некорректно).
Не делайте больше двух проектов одновременно
Один проект — хорошо, потому что можно погрузиться и медитировать. Два проекта — неплохо, потому что больше денег. При трёх и более проектах одновременно эффективность резко падает, появляется дикая каша в голове, на эскизах одного сайта появляются элементы другого и так далее. , похоже, не в состоянии обрабатывать столько разной информации одним способом.
Берите в работу «одинаковые» проекты, но не одновременно
Одинаковые на первый взгляд проекты при правильном применении методики почти всегда оказываются разными: в коммуникации, бизнес-процессах, содержании. Смело говорите клиенту, что для него большой плюс, что вы проектировали сайт его конкуренту. Но ни за что не делайте такие проекты одновременно: никуда вы не денетесь — будете предлагать одни и те же решения.
Решительное «Нет!» клиенту-дизайнеру
Ни при каких условиях — за исключением гонорара в миллион долларов — не входите в разработку с клиентом, который на этапе проектирования показывает себя самодуром и «разбирающимся в дизайне»: говорит, что в эскизе хорошо бы подвинуть логотип на 2 см и сделать его побольше, или требует «сделать интерфейс как в Windows 8».
Если на этапе проектирования, где логики и здравого смысла гораздо больше, чем в дизайне, он так поступает, представьте, что будет, когда вы покажете ему первый дизайн-макет.
Выводы
В статьях принято делать выводы. Он у меня один и довольно очевидный: никогда не думайте, что вы делаете всё правильно, замечайте, признавайте, анализируйте и исправляйте свои ошибки.
В следующей статье я предложу быстрый и эффективный способ сделать концепцию (сайта или сервиса). Я сознательно пропускаю этап сбора информации, потому что о нём почти всё сказано тут: habrahabr.ru/company/kelnik/blog/155003/.
Автор: Altunik
