html текст
All interests
  • All interests
  • Design
  • Food
  • Gadgets
  • Humor
  • News
  • Photo
  • Travel
  • Video
Click to see the next recommended page
Like it
Don't like
Add to Favorites

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

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

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

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


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

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

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


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

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

UPD: Этот пункт не означает, что мы выключаемся из процесса сбора информации! Напротив, мы «мучаем» клиента и всех его сотрудников, которые могут сказать нам что-то полезное, предоставить материалы, статистику и так далее. Обычно на этапе сбора информации клиент устаёт больше всего, потому что вынужден каждый божий день отвечать на мои вопросы и запросы материалов.

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


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

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

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


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

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

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


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

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

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

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


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

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

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

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


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

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

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


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

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


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

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

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


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

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

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


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

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


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

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

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


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

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

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


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

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


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

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


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

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


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

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

Выводы


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

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

материал с habrahabr.ru

0

      Add

      You can create thematic collections and keep, for instance, all recipes in one place so you will never lose them.

      No images found
      Previous Next 0 / 0
      500
      • Advertisement
      • Animals
      • Architecture
      • Art
      • Auto
      • Aviation
      • Books
      • Cartoons
      • Celebrities
      • Children
      • Culture
      • Design
      • Economics
      • Education
      • Entertainment
      • Fashion
      • Fitness
      • Food
      • Gadgets
      • Games
      • Health
      • History
      • Hobby
      • Humor
      • Interior
      • Moto
      • Movies
      • Music
      • Nature
      • News
      • Photo
      • Pictures
      • Politics
      • Psychology
      • Science
      • Society
      • Sport
      • Technology
      • Travel
      • Video
      • Weapons
      • Web
      • Work
        Submit
        Valid formats are JPG, PNG, GIF.
        Not more than 5 Мb, please.
        30
        surfingbird.ru/site/
        RSS format guidelines
        500
        • Advertisement
        • Animals
        • Architecture
        • Art
        • Auto
        • Aviation
        • Books
        • Cartoons
        • Celebrities
        • Children
        • Culture
        • Design
        • Economics
        • Education
        • Entertainment
        • Fashion
        • Fitness
        • Food
        • Gadgets
        • Games
        • Health
        • History
        • Hobby
        • Humor
        • Interior
        • Moto
        • Movies
        • Music
        • Nature
        • News
        • Photo
        • Pictures
        • Politics
        • Psychology
        • Science
        • Society
        • Sport
        • Technology
        • Travel
        • Video
        • Weapons
        • Web
        • Work

          Submit

          Thank you! Wait for moderation.

          Тебе это не нравится?

          You can block the domain, tag, user or channel, and we'll stop recommend it to you. You can always unblock them in your settings.

          • habrahabr.ru
          • домен habrahabr.ru

          Get a link

          Спасибо, твоя жалоба принята.

          Log on to Surfingbird

          Recover
          Sign up

          or

          Welcome to Surfingbird.com!

          You'll find thousands of interesting pages, photos, and videos inside.
          Join!

          • Personal
            recommendations

          • Stash
            interesting and useful stuff

          • Anywhere,
            anytime

          Do we already know you? Login or restore the password.

          Close

          Add to collection

             

            Facebook

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

            Facebook

            К сожалению, вы не попадаете под условия акции