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

    Последний раз я писал статью о проектировании в 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.
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 11
    • 0
      Спасибо за статью! Мой небольшой опыт полностью совпадает с вышеописанным.
      • 0
        А не за что. Хорошо, когда находишь подтверждение своего опыта у других.
      • 0
        Проекты по проектированию имеют свойство сильно затягиваться довольно часто (так как предполагают активное общение с клиентом, а он часто занят). Поэтому брать 1-2 проекта, если это обычные проекты, а не здоровенные — значит жить впроголодь :)
        • 0
          Я имел в виду не количество заказов для студии в целом, а в расчёте на одного проектировщика.
          • 0
            Я как проектировщик-фрилансер ответил :)
            • 0
              Тут случай другой :) Зависит от интенсивности проекта тогда. Если брать вялотекущие проекты, то можно и больше двух без потери качества делать.
              • 0
                До 10 брал. Потому что часто неделю приходится ждать ответа заказчика.
        • +1
          Можно свои пять копеек. Такой подход я называю «пассивным обследованием». Т.е. когда предполагается четкое разделение функций и полномочий «заказчик»-«исполнитель» и исполнитель только спрашивает — чего же хочет заказчик.

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

          Неполное описание может получаться и от экономии денег — ведь обследование, как и ремонт невозможно закончить. Вы можете быть просто ограничены фактором времени — например написать ТЗ за 1 неделю, все что выше — заказчик не захочет оплачивать. И в третьих — даже самое что ни на есть полное заключение — не всякий (разве что кроме автора) разработчик дочитает до конца. А если дочитает разработчик — то не захочет тестировщик и пр…

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

          Я для себя нашел несколько вариантов:
          1) Почаще предлагать _типовое_ решение. Т.е. у вас уже есть прототип вашего скажем сайта под соответствующую тематику. И от клиента требуется только выбрать из конечного числа вариантов предустановок. В этому случае вы имеете свою хорошо отлаженную портальную логику, не грузите клиента деталями реализации, система вообще говоря непротиворечива — т.к. многие вещи вы предусмотрели и протестировали заранее. Да — это несколько уменьшает креатив клиента, но как правило сильно ему нравится в плане экономии денег. Ясно же — что типовой сайт «взлетит» не за полгода-год, а практически за несколько дней.
          Но чтобы продавать типовое решение — вам надо иметь хорошую документацию по нему — с детальным описанием всяческих функций и плюшек. «На пальцах» типовое решение не объясняется и не продается. Поэтому сэкономив на расходах на программировании — вы все равно должны потратиться на хорошего редактора и корректора текста.

          2) Вариант «Активное» обследование. Вы смотрите на предмет глазами заказчика. Не создаете сайт — а скажем рассматриваете его как канал привлечения клиентов, повышение объема продаж, закрепление торговой марки и пр. Т.е. решаете не технические, а бизнес-задачи.
          Если у вас есть референсы на успешно выполненные такие проекты, у вас хорошее образование и достаточно квалифицированная команда — заказчик может вообще отдать вам в том числе и проектирование. Т.е. — решайте сами, думайте сами, только не задавайте вопросов. Но само собой — вы и отвечаете за эффективный результат. Как правило — так работают консультанты мирового уровня — они сначала нарабатывают себе имя, а потом — ни с кем ничего не согласуя — делают как считают нужным. (см типовое решение ;-)

          3) Еще интересный вариант — типа shift activity — это эдакий вариант аутсорсинга, только когда вы не просите заказчика что-то ответить на вопросы для вас, потом перевариваете его неструктурированные мысли, и уговариваете в итоге принять компромиссный вариант — (в таком случае вообще говоря ваша эффективность сильно зависит от того — насколько заказчик прислушается (или поймет) ваши советы.)
          Так вот — «перенос активности» — это когда вы по сути подменяете функцию заказчика как класс, т.е. вообще берете на себя эту нужную работу. Например — не создаете сайт, чтобы привлечь клиентов — а просто приводите клиентов, и ваше дело — откуда вы их взяли. И делаете это не разово — а навсегда. Само собой — нужно договариваться «на берегу» — сколько стоят ваши услуги, т.к. вы по сути можете стать совладельцем бизнеса — а может и правда станете партнером. Но это самая интересная и эффективная штука. В быту это тоже встречается — например когда вы говорите парикмахеру «подстригите меня на свой вкус» или пользуетесь консультантами по одежде — который даже не водит вас по магазинам — а просто догадывается о ваших предпочтениях и каждый раз привозит к нужному сроку и в нужное время полный комплект вашего наряда.

          Вкратце — вывод простой, становитесь экспертом в своем деле на уровне заказчика (или даже выше — т.к. вы можете объединять опыт однотипных проектов — чего никогда не сможет заказчик)- и тогда вы будете работать не за еду-себестоимость, а за столько — сколько сами захотите — ибо ваши услуги будут качественны, уникальны и вас не нужно будет «пасти», вы будет просто незаметны (в хорошем смысле) и незаменимы ;-)
          • +1
            Извините, либо утро ещё, либо я не догадлив. Вы не могли бы пояснить (не знаю вашего имени), к чему относится ваш комментарий, а особенно его первая часть до пунктов (4 абзаца)?
            • –1
              К пунктам методики обследования
              «Как можно больше говорите с клиентом на этапе сбора информации»
              «Возложите ответственность за полноту и качество сбора информации на клиента»
              «Маркетинг, позиционирование — полностью ответственность клиента» и пр.

              это все элементы строгого функционального разделения и пассивной (по отношению к объекту автоматизации) позиции исполнителя. Считаю что это начальный уровень консалтера, который нужно проходить за 1-2 года освоения предметной области. Вероятно немало аналитиков застревают на этом уровне, превращаясь в «луноходов» — которым нужно давать максимально четкие и детальные инструкции. Но работать на другом уровне энергетики — не в страхе/боязни потерять покой, а в радости свободного творчества и партнерстве c заказчиком — куда как полезнее для организма ;-)
              • 0
                К пунктам методики обследования


                Это не пункты методики :) Если хотите побольше узнать про методику, рекомендую ссылку в конце статьи.

                Т.е. когда предполагается четкое разделение функций и полномочий «заказчик»-«исполнитель» и исполнитель только спрашивает — чего же хочет заказчик.


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

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

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


                Статья не про бизнес-консалтинг, а про методику проектирования сайтов и других интерактивных продуктов. Бизнес-консалтинг — это отдельная вещь, рекомендую её сюда не примешивать. Это всё равно, что прийти в обсуждение статьи про java-скрипты и написать: «Писать java-скрипты — это надо проходить за первый год, а вот проектирование архитектуры системы — это дааа, новый уровень понимания, творческий полёт, другая энергетика.»

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое