Pull to refresh

Comments 36

Мне вот очень понравился подход студии Лебедева, когда они делали сайт для машины какой то русской. Смеялись помню, сайт дороже самой машины :) Так они там макет сайта сделали в прямом смысле на бумаге и как мини театр его показывали заказчику.
Про макеты в следующей статье. Вообще люди сейчас проектируют от бумаги до специальных серьезных софтин. На бумаге дольше всего и нельзя менять сквозные элементы, которые есть на всех макетах.
Чего только ни сделаешь, чтобы оправдать затраты.
Можно даже из золота макет выковать с каменьми.
Это я к тому, что лебедевские «нанотехнологии» большей частью выглядят как пассы фокусника перед тем, как достать монетку у заказчика из-за уха.
Интересно. Подписался на Вас. Не могли бы Вы во второй части выложить примеры создаваемых проектных документов.
Да я бы и в первой не отказался — бриф, цели, персонажи, сценарии, задачи/проблемы/решения — как эта информация группируется в документах, вся ли она показывается клиентам?
Во второй часте мы покажем примеры интерфейсов и конечное ТЗ. Все из перечисленных документов показываются и утверждаются клиентом, но самое важное для последующей разработки — это интерфейсы вместе с текстовым описанием, на это нужно делать упор. Что касается брифа, целей и т.д. — не сильно важно оформление, ведь это промежуточные этапы.
Ок. Я понимаю, что для разработки важны интерфейсы и т.д., но цель статьи, как я понимаю, описать весь процесс. Я считаю, что ошибка на каждом из этапов способна внести нехилые риски, и поэтому каждый этап важен. Мне, как человеку, который как раз сейчас перебирается в веб-разработку очень интересны наглядные иллюстрации документов.

Короче было бы здорово :)
Тогда по порядку:

1. Бриф мы делаем в вольном стиле, на усмотрению менеджера
2. Цели — по сути минидокумент на одну страничку, примеры привел
3. Пример персонажа привел, в документе один за одним, в статье скрин с ворда, даже с красным подчеркиванием
4. Пример сценария привел, один за одним
5. Задачи/проблемы/решения — скрин с экселя, остальные также делаются.

Во второй части документы обещаю более наглядные :)
Вставлю свои 5 копеек:
1. Все что говорит клиент для брифа не нужно воспринимать за истину, многие из его предложений и предположений требуют проверки. Это касается целевой аудитории, выделение приоритета по целям, да и сами высокоуровневые требования иногда формулируются в отрыве от реальной ситуации.
2. Хороший интерфейс это прежде всего качественная аналитика. Чем меньше мы сами (или клиент) придумываем персонажей и сценариев и чем больше у нас возможностей для мониторинга существующих целевых ресурсов клиента, тем точнее мы сможем сформулировать истинные задачи и пути их решения. Особенно уникально-положительная ситуация когда возможно предпроектное A-B тестирование текущего ресурса клиента для фиксации эффективных решений, но это пока уникальные случаи.
3. Задачи-проблемы-решения очень напоминает стори-мэппинг и в целом достаточно удобная вещь для не очень крупных проектов.
Очень интересная статья, большое спасибо. Ориентировочно 2-ю часть когда ждать?
habrahabr.ru/company/SECL_GROUP/blog/178049/ — ловите!

Правда habrastorage не поддерживает большие размеры картинок, как я понял, поэтому mind map и другие огромные элементы можно посмотреть в полном размере у нас на сайте в полной версии статьи: secl.com.ua/article-serjoznoe-proektirovanie-serjoznix-saitov.html
Когда я слышу про SWOT мой BS детектор начинает звенеть

Помомо этого, мне в общем и в целом нравится использование персонажей, но действительно ли нам реально важно знать, что Алексей Крамов подрабатывает мерчандайзером. Что мы изменим, если он подрабатывает, скажем эникейщиком? И что более важно, действительно ли такая большая часть наших потенциальных пользователей подрабатывает мерчандайзерами и живет в пригорадах Киева. Может быть нам лучше выбрать в качестве персоны продавщицу Олесю из Крыжополя (которая тоже попадает в целевую аудиторию с подтипом «покупатель первой собаки»)?
В общем вопрос в том, не провоцирует ли использование проработанных с достаточной детальностью персонажей появление ненужных стереотипов и необоснованных предположений у дизайнеров и разработчиков.
«но действительно ли нам реально важно знать, что Алексей Крамов подрабатывает мерчандайзером»
Важно вжиться в роль персонажа. Поэтому лучше составить полную картину.

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

«В общем вопрос в том, не провоцирует ли использование проработанных с достаточной детальностью персонажей появление ненужных стереотипов и необоснованных предположений у дизайнеров и разработчиков. „
Такой риск есть. Но так как персонажей много, а проектировщик старается сделать каждого из них нейтрального, то скорее всего стереотипов будет немного, если вообще будут.
Боюсь, что если персонажей будет сильно много (десятки), они не вместятся в мозг проектировщика (разработчика, дизайнера).
В результате он «забьет» на них при проектировании и время и деньги, потраченные на разработку персонажей будут потрачены зря.
Почему же? С каждым персонажем идет отдельная работа, шаг за шагом. Задачи-проблемы-решения делаются для каждого из персонажей, а потом собираются в единую табличку.
Вопрос в том, оправдано ли использование ограниченных ресурсов на проработку десятков персон, и не лучше ли ограничится предполагаемыми потребностями более абстрактного персонажа, каковых наберутся не десятки, а единицы.
Интересно, что задачи-проблемы-решения в вашем примере не особо зависит от профессии, пола и места жительства «Алексея», они с таким же успехом подходят и «Олесе»
Абсолютно согласен, выдумывание детализированных персонажей не способно повысить качество проектирования по причинам:
-персонажи придуманы а следовательно могут не совпадать в общем или в деталях с характеристиками основной выборки реальной ЦА
-излишняя искусственная детализированность добавляет такой же объем искусственных непроверенных условий, которые могут быть по факту абсолютно невостребованными в реальности
Предпочтительно использование обобщенных персонажей (или даже целевых групп) с теми характеристиками, которые можно максимально точно измерить или оценить по реальной аудитории. Этого будет достаточно.
Зависит от сайта, конечно. Дублировать однотипных персонажей нет никакого смысла, и на последующих этапах работа будет проще если объединить их в архетипы. Но на крупном и сложном проекте действительно может быть 10 и больше совершенно разных групп пользователей.
Спасибо, интересно.
У нас пока не очень воспринимают проектирование, но я пытаюсь улучшить ситуацию. Проблема в том, что заказчик может быть как раз не увлеченным, он ждет, что ты за него придумаешь себе цели и задачи, а вот отчетности требует строгой — «сделай не знаю что точно в срок и с ограниченным бюджетом». В таком случае приходится идти сразу к пользователям или руководителем меньшего ранга, чтобы собрать требования.
Заказчик все равно не очень доволен, потому что, по его мнению, надо было с разгону писать код, а не «чесать репу», но хотя бы можно сделать что-то действительно нужное.
Абсолютно согласен. Мы обычно это мотивируем примерно так: «Видите какое у нас портфолио? Хотите также классно? Нужно начинать с проектирования!»
А если еще подогнать табличку с результатами юзабилити тестирований и ростом показателей аналитики по каждому сайту… :)
Спасибо, интересный материал. Буду перечитывать и обращаться снова и снова, так как хоче запускать свой проект.
Много полезного вспомнил, что со временем подзабылось или давно не использовалось в виду направленности на «штамповку» сайтов, а не на их маштабность и качество.
С удовольствием на выходных буду читать vol.2 = )

Ряд вопросов, если позволите:
1) Какой разброс сроков Аналитики вы можете назвать на основе Вашего опыта? + Сроки сдачи проекта также интересуют (от заказа до запуска)?
2) Какой процент Ваших клиентов уходил/возмущался/урезал бюджет из-за сроков анализа?
3) Прекрасно понимаю, что все люди разные, но всё же: Какие аргументы больше всего (чаще?) действуют/используются Вами для аргументации сроков и соответствующих затрат на аналитику? (Кроме портфолио, конечно же)
4) Какова, если не секрет, средняя зарплата такого специалиста в Вашей компании? (проектировщика)
5) Больше риторический вопрос:
У меня сложилось лёгкое впечатление, что данная модель в общем похожа на PR-акцию, т.е. так или иначе (явно или косвенно) мелькают знакомые мне моменты: Концепция, Таргет-группы, Психологические портреты, ожидаемая реакция и т.д.
Вам так не кажется? и знакомы ли Вы с работой PR-шика? = ))))
Спасибо за отзыв!

Отвечаю на вопросы:
1. На аналитику уходит от 2х недель до месяца. Все проектирование от месяца до 3х
2. Таких не было. Это очень важный этап, мы всегда доносим до клиента, что это необходимо
3. Мы объясняем зачем это нужно, что принесет, показываем эту статью :)
4. Информацию не раскрываем)
5. Возможно, я не пиарщик
Какова стоимость услуг по проектированию интерфейсов?
Судя по тому, что вы считаете проведение интервью пользователей необязательной работой, возникает закономерный вопрос — а какой источник информации о персонажах и задачах пользователей?

Похоже, что в вашем случае это всё какие-то домыслы, а не результаты реальных исследований.

Буду рекомендовать ваш подход как антипример.
А я разве говорил, что с реальными представителями ЦА нельзя общаться? Напротив, очень полезно пообщаться с реальными людьми, мы так часто и делаем…
«Мы должны понять, кто именно наша целевая аудитория»
«Для каждой группы мы ПРИДУМЫВАЕМ типичного персонажа»
«Для полного понимания ЦА, ИНОГДА проводят интервью с пользователями, это уже сфера маркетинговых исследований.»

Если интервью с пользователями для вас ИНОГДА, а не must, то вы делаете интерфейс для себя, а не для пользователей.
С предсказуемым результатом.
Подсчитайте стоимость глубинного интервью с хотя бы 20ю типичными представителями ЦА, а по хорошему, на каждую группу нужно по несколько глубинных интервью, чтобы получить точный портрет. Посчитали? А теперь ответьте, кто финансово может себе это позволить, кроме Гугла и ряда подобных компаний?

Да, начинать исследование с правильных маркетинговых исследований очень не плохо, но вот стоимость таких исследований выйдет в 100 тыс. долл. примерно. Мы обычно столько не тратим, Вы правильно заметили.
Я прямо сейчас провожу интервью для компании в 700 человек.

7 интервью занимают вам один день и могут принести серьёзную пользу.
Ваш день стоит 100 тыс долларов? Значит, вы не на тот сайт пишете.
Расскажите это GfK или TNS. Если Вы говорите о профессионализме, так следуйте этому принципу до конца. Нет смысла разводить непонятно что и называть это «исследованиями». Если беретесь серьезно с исследованиями, то и делайте это хорошо.
Что именно рассказать TNS?

Откуда вы взяли про «непонятно что»?
Я говорю про день на исследования.
Такие вопросы всплыли в голове, пока читал:
— будет ли пользователь ожидать наличия материалов по выбору породы собаки или отправится за этим в гугл?
— будет ли эффективен узкоспециализированный сайт по выбору породы собаки или пользователю с такой целью нужен более комплексный сайт?

Тогда можно ли отложить вторичную функциональность (материалов по выбору породы собаки) и сфокусироваться на ядре сайта? Будет ли это выгодно финансово и по времени?

Вспоминается Getting Real и идея «сделайте не так много, но качественно».
В целом принцип делать просто и быстро — правильный. Мы спроектировали целого монстра, а начать нужно с небольшой беты и постепенно её развивать.
Sign up to leave a comment.