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