Как правильно показывать клиенту интерактивный прототип сайта в первый раз

  • Tutorial
Возьмём понятный всем пример. Интернет-магазин. Вот вы встретились с клиентом в первый раз, обсудили, что должен и не должен делать их будущий проект. После этого сформировали список функциональных требований и сопроводили его предварительной картой сайта. Всё это дело будет потом помещено в приложение номер один к договору на проектирование, но сегодня речь не об этом. Давайте для начала взглянем на карту сайта, которая у нас получилась.

  • Главная
  • Каталог
  • Страница товара
  • Блог
  • Отдельный пост
  • О нас
  • Доставка и оплата
  • Акции и спецпредложения
  • Личный кабинет
  • Мои заказы
  • Мои данные
  • Настройки
  • Корзина
  • Оформление заказа
  • Результаты поиска по сайту

При первом приближении у нас тут 15 экранов. Опытный проектировщик скажет, что их тут будет до 30-ти. Давайте ответим на вопрос, с чем стоит прийти к клиенту на первую встречу, чтобы осчастливить его, а заодно минимизировать риски и издержки в процессе проектирования. И тут небольшое лирическое отступление.

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

Шаг первый


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

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

Шаг второй


Берём из головы самый распространённый сценарий взаимодействия и, двигаясь по нему, детализируем страницы, которые попадаются на пути. В случае с интернет-магазином чаще всего это будет выглядеть так:

  1. Пользователь из поисковика (или каталога) попадает на страницу отдельного товара;
  2. Добавляет товар в корзину. В этот момент интерфейс должен ему подсказать, куда двигаться дальше, чтобы продолжать покупки или оплатить товар;
  3. Переходит в корзину для оплаты, редактирует содержимое, знакомится с дополнительной информацией, связанной с акциями;
  4. Указывает личные данные, информацию о доставке, выбирает способ оплаты;
  5. Оплачивает товар во внешнем гейте оплаты;
  6. Возвращается на сайт магазина, в список своих оплаченных заказов и следит там за их статусами.

Когда сценарии взаимодействия описаны, такой список есть у нас перед глазами. Но чаще всего он у нас перед мысленным взором. Давайте теперь посмотрим, какие разделы из карты сайта нам нужно проработать и в какой последовательности.

  • Каталог
  • Страница товара
  • Корзина
  • Оформление заказа
  • Подтверждение оплаты
  • Мои заказы в личном кабинете

Шесть экранов! И это с учётом того, что мы уже проработали навигационное решение. То есть, нам не нужно выдумывать навигацию личного кабинета или придумывать, куда структурно воткнуть тупиковые (или разводящие, т.е. те, где сценарий закончен и надо бы направить пользователя куда-нибудь дальше) страницы.

Шаг третий


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

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

А напоследок давайте вспомним, что обычно показывают проектировщики на первой демонстрации прототипа.

— Это главная страница!
На главную страницу обычно попадает до 10% трафика, если речь не идёт о каком-нибудь исключении в виде популярного сервиса, поэтому не стоит с неё начинать

— Каталог товаров и карточка отдельного товара. Мы можем добавить товар в корзину прямо из каталога. Я кликаю по этой кнопке, у нас в корзине появляется плюс один и стоимость, а кнопка превращается в «Добавить ещё один».
А здесь пример преждевременной проработки динамических элементов. Клиент может сосредоточиться на комментаровании этой страницы и создать много сложной работы по переделке, хотя это всего лишь первый шаг в нашей сценарной цепочке

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

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

Все мы через это проходили. И в роли клиентов, и в роли проектировщиков. И поначалу все наступали на похожие грабли. Поэтому желаю вам побольше практики и удачных рабочих отношений. Любая инструкция будет действовать только в рамках определённых условий, а практика подарит опыт, который поможет под эти условия подстраиваться.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 11

    +2
    А какой смысл показывать клиенту прототип на стадии прототипирования? Мне всегда казалось на то он и прототип, что с его готовой версии начинается обсуждение. Да и работая в Axure, даже если у клиента возникают замечания которые в корне изменят прототип, на все правки уйдет не больше пары часов, причем можно это сделать прямо при клиенте, чтобы не терять в дальнейшем времени на согласования.
      0
      Да, такой сценарий тоже существует. Бывают случаи, когда проектировщик уверен на 100%, что сделает именно то, что нужно, с первого раза, а последующие комментарии будут незначительными и не займут много времени. Хорошо, если так. Но статья не об этом. Она о том, как сделать так, чтобы и клиент был доволен, и риски дополнительных издержек были сведены к минимуму.
      Вы ещё не успеваете познакомиться с человеком с момента заключения договора. Может быть, когда вы покажете ему финальную версию, он скажет «Мне это не нравится» и на этом его аргументация закончится.
      Суть проектирования заключается в процессе. Обсуждение начинается задолго до подхода к прототипу. Даже если вы делаете точно то, что нужно клиенту, лучше делать это так, словно вы вместе работаете над прототипом, как одна команда. А не так, что прошёл месяц, вот вам прототип, делайте с ним, что хотите. А клиент понимает, что проделанная работа действительно стоит тех денег, что он заплатил, но это совершенно не то, что ему нужно. Я очень много раз сталкивался с такой ситуацией, когда клиент с улыбкой платит исполнителю, а потом идёт к другому, чтобы всё-таки получить то, что ему нужно.
      Процитирую самого себя:
      «Чаще всего клиенты, которые обращаются за проектированием и платят за это больше сотни, точно знают, чего хотят. Им в первую очередь нужен исполнитель, а во вторую — консультант. А исполнитель не обязательно должен обладать собственным экспертным мнением.
      Высший пилотаж в процессе работы с таким клиентом показать ему свою экспертность, при этом выдавая именно тот результат, который был заранее сформирован в голове клиента. А если вы так умеете, то вот вы уже и в той позиции, когда вас рекомендуют, а не вы кого-то ищете. И снова прототипы в вашем портфолио не играют большой роли».
        0
        Вы ещё не успеваете познакомиться с человеком с момента заключения договора.

        При заключении договора идет как минимум двухчасовая беседа, составляется бриф, уточняется что именно человек имеет под разными терминами, такими как «Каталог» или «Обратная связь» ищутся примеры реализации похожих вещей, предлагаются свои варианты, так же с примерами, и только после всего этого составляется прототип, который уже в полной мере совпадает с ожиданиями заказчика.
        Все правки, которые за этим последуют, в большинстве случаев сведутся к: «А давайте подвинем корзину и напишем в ней количество товаров»
        Есть клинические случаи, когда слова клиента можно перефразировать как «Нет, это не то, я не скажу что здесь не так, но вы делаете совсем не так как я хочу!», но таких можно отсекать на первой беседе, перед заключением договора.
          0
          Кажется, не туда ответил. Сейчас перечитываю и вижу, что ответ скорее конфронтальный, чем солидарный. На самом деле это не так. Вы всё совершенно верно написали и про беседу, и про уточнения, а я воспринял это, как тотальную формализацию. Но это не отменяет того, что промежуточный результат в процессе проектирования сокращает потенциальные издержки на правки и позволяет безболезненно подкорректировать курс, даже если появляются новые функциональные требования.
            0
            Отвечу на обо комментария сразу:
            Бриф это не страховка исполнителя, это гарант взаимопонимания, потому что риски несет как исполнитель, так и заказчик. Собственно прототип это второй гарант.
            Теперь про издержки:
            В первом случае делается прототип -> показывается заказчику -> согласовываются правки -> доделывается прототип -> утверждается прототип
            Во втором случае делается часть прототипа -> показывается заказчику -> согласовываются правки -> вносятся правки -> доделывается прототип -> согласовываются правки -> вносятся правки -> утверждается прототип
            Мне не кажется этот путь сокращением издержек, более того мне не кажется такой путь понятнее и приятнее для клиента, кроме случая когда исполнитель пропадает на месяц(любой другой немыслимый срок), с разработкой прототипа.
              0
              Значит, мы всё-таки остались каждый при своём мнении.
              Я не соглашусь с описанными сценариями, потому что, как в первом, так и во втором случае, ограничиться одной-двумя итерациями, значит не проектировать, а сделать прототип под ключ, внести в него один набор правок и прикрыться договором с функциональными требованиями.
              Я всё это описывал не с позиции «мне кажется». Четыре года я работал по методологии, описанной в первом сценарии, до тех пор пока сам не оказался клиентом, которому нужны услуги проектировщика. И ещё три года я работал уже по методологии, описанной в статье, сначала как фрилансер, а затем как собственник компании. Вторая показала себя лучше, особенно на проектах от 150 экранов. При ней функциональные требования могли меняться на лету и клиент получал то, что ему нужно, а не то, что было оговорено в течение двух часов перед брифом.
                0
                Все что я говорил тоже взято из собственного опыта. К сожалению мне не приходилось разрабатывать прототипы в более чем 30-50 экранов, и там первая методика срабатывала на ура. В случае действительно больших прототипов возможно Вы и правы.
                Наверное можно вывести какую то формулу, по которой после определенных трудозатрат на прототип второй вариант становится более целесообразным.
                  0
                  Я всё же соглашусь с автором поста и вот почему.
                  Заказчик изначально представляет себе желаемый функционал, но никак не внешний вид.
                  Если вы делаете единственный бриф, то увеличиваете риск желания переделки заказчиком полученного результата. Либо, если у вас жесткий запрет на переделки в договоре, скрытое его недовольство.
                  Итерационные же встречи спокойнее сводят в единую точку реальности галлюцинации клиента о будущем сайте и созданные прототипы.
                  И да, конечно, это тем важнее, чем больше сайт.
                  То есть не только поэтапное согласование само по себе, но и снижение риска требования переделок.
      0
      Я ведь именно об этом и пишу. Исполнители подстраховываются брифом, выдают готовый результат, который в человекочасах стоит затраченного бюджета, а клиента счастливым за его деньги не делает. Я бы уже занервничал, когда у меня исполнитель спросил: «А давайте уточним, что такое обратная связь?» Это значит, что в процессе проектирования, я не смогу передумать и по сути я покупаю результат в виде чёрного ящика, а не прозрачный процесс, который приведёт к нужной мне цели. С таким брифом проектирование происходит в момент заключения брифа.
      Я описываю клиентоориентированную методологию, при которой снижаю риски, появляющиеся из-за этой клиентоориентированности.
        0
        Лично я проектирование начинаю с миндмапа со структурой сайта и всеми возможными целями пользователя. На этом этапе можно с клиента получить почти все его «фантазии». И только когда уже ясен список страниц и цели можно начинать проектировать.

        Во-первых, дает возможность получить максимум информации не отвлекая клиента на внешний вид (многим даже перед чернобелым прототипом тяжело не думать о картинке), а во-вторых экономит кучу времени и пониманием желаний клиента. Чаще всего миндмап составляеться вместе с клиентом (или отвественным лицом) за час-полтора. В редких случаях требуеться ссамостоятельная и глубокая проработка.
          –1
          можно еще и провести пользовательское тестирование чтобы отсечь субьективность истории. Например, тут www.fabuza.ru

          Only users with full accounts can post comments. Log in, please.