Стартуем проекты. Удачная рабочая сессия

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

В условиях работы над стартапом, когда есть общее представление и очень мало конкретики, объем и трудоемкость работ оценить сложно. Хороший способ разрулить эту коллизию — устроить плотную рабочую сессию с заказчиком. В ходе этой серии обсуждений четко описывается, что должна делать система и как. Тут работает принцип “пока рассказывал, сам понял” — функциональность проговаривается по нескольку раз. И по ходу этих обсуждений снимаются неувязки, всплывает забытое и отбрасывается ненужное.

Первым результатом нашего обсуждения стали персонажи ключевых пользователей и их user stories. Персонажи приобрели цели, задачи и общий бекграунд. А их user stories описали, каким образом функциональность системы позволяет пользователю выполнить задачи и достичь своих целей — то есть примерный алгоритм работы с системой. В нашем случае персонажами выступили, скажем, автор и редактор (назову их так, чтобы не навредить создателям проекта). Цели автора — создать хороший материал и получить за него приемлемую оценку. А вот его задачи уже более приземленные:

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

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

Черновой вариант wireframeЗдорово, если в рамках этой сессии получается набросать низкоуровневые wireframes — на уровне набора блоков (”черных ящиков”), содержащихся на странице. На бумаге или в электронном виде — не так важно. Это позволяет проговорить функциональность еще глубже, максимально приблизившись к конкретике. Также полезно определиться с составом интерактивного прототипа – задача это достаточно трудоемкая и лишнюю работу в ее рамках делать не стоит. На это во многом влияет цель, с которой он создается — юзабилити-тестирование или презентация инвесторам.

На этом мы и закончили рабочую сессию. У меня на руках оказался достаточный пакет материалов, чтобы спланировать работы по проекту. Кроме того, сложилась четкая картинка интерфейса системы — теперь его осталось только глубоко детализировать. Не забыли и про спецификацию — business rules, сущности и их атрибуты, особенности реализации и прочие технические моменты. Ну и контакты, которым можно задать любые уточняющие вопросы. После того как ключевые детали прояснились, их список не будет многостраничным.

Workshops, Начало проекта, Пользовательские интерфейсы, Практика, Проект-менеджмент, Проектирование, Юзабилити

  1. May 29th, 2007 at 20:15 | #1

    Где-то я эту шапочку в визио уже видел!

  2. May 30th, 2007 at 10:44 | #2

    Это я, Максим, у Лебедева заимствовал — ему можно верить! :)

  3. July 11th, 2007 at 04:13 | #3

    А в чем все это нарисовано?

  4. July 11th, 2007 at 12:44 | #4

    Это MS Office Visio — все wireframes рисую в нем.

  5. July 12th, 2007 at 03:09 | #5

    2003?

    Кстати, нотификации на емейл не ходят.

  6. July 12th, 2007 at 12:55 | #6

    Да, 2003й. Но они все начиная с 2002 более-менее пристойные.

    Нотификации попробовал починить — надеюсь, сработало :) Спасиб за информацию!

  7. July 13th, 2007 at 04:22 | #7

    Я поэтому и спросил - сам пользуюсь 2002, оно не очень-то похоже визуально.

    Нотификации нашел. В спаме. Странно, в CBL вашего домена нет :)

  8. July 13th, 2007 at 11:49 | #8

    А это стенсил специальный, вот и не похож :) По функциональности что 2002, что 2007 — отличаются минимально.

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

  9. July 13th, 2007 at 16:16 | #9

    >А это стенсил специальный
    А скачать его где-нибудь можно?

  10. July 13th, 2007 at 16:23 | #10

    Я использую сильно доработанный напильником стенсил Garrett Dimon: http://v1.garrettdimon.com/resources/templates-stencils-for-visio-omnigraffle — там есть версия и для Visio 2002.

  11. January 4th, 2008 at 01:10 | #11

    Юра, в кратком обзоре процесса ты эта озаглавил всё это как предпроектный анализ. Хотел бы уточнить артефакты которые были на входе и получились на выходе.

    Я успел высмотреть следующие
    - Описание персонажей(задачи и цели) и их user stories
    - Низкоуровневый прототип (в идеале - детализированный)
    - Куски функциональной спецификации исходя из пользовательских задач и прототипа

    А что ты имел в виду тут?
    “Не забыли и про спецификацию — business rules, сущности и их атрибуты, особенности реализации и прочие технические моменты”
    Что тут в результате создается ?

    Если можно перечисли все полученные артефакты на всём этапе. Спасибо.

  12. January 28th, 2008 at 15:58 | #12

    Паша,

    На входе был поток сознания клиента и пара набросков ключевых страниц. На выходе после рабочей сессии получилось вот что:

    — перечень и краткое описание персонажей;
    — набросок карты сайта;
    — наброски схем страниц на бумаге (это очень и очень низкоуровневый бумажный прототип :) );
    — перечень user stories с примерной оценкой страниц для каждой;

    После того как обсуждение закончилось, я привел это все в порядок и получил:

    — описание персонажей;
    — карта сайта и схема навигации — в каких меню какие разделы будут отображаться;
    — низкоуровневые wireframes, как на скриншоте в статье;
    — расписанные в базовом виде user stories — как раз вышла нулевая часть статьи о них;
    — куски спецификации — описание хитрых алгоритмов работы со сторонней базой данных. Тут вообще в достаточно свободной форме все, описана бизнес-логика работы связки пользователь/наша система/сторонняя система, требования к безопасности и т.п.;

    Примерно так. Заняло все это вместе с написанием коммерческого предложения и договора неделю.

  13. January 28th, 2008 at 17:06 | #13

    Юра, спасибо тебе большое за ответ. Учусь на твоих статьях и на твоём опыте. Ты как Прометей несёшь людям огонь юзабилити. Жду анонсированных материалов.

    В планируемой своей статье о персонажах буду ссылаться на тебя

  14. January 28th, 2008 at 17:26 | #14

    Паша,

    До Прометея мне еще далеко, но здорово что получается помогать :) Сейчас плотно занят написанием пачки статей для нового сайта моего отдела — так что текстов в феврале будет адски много :) За будущие ссылки тоже спасиб :)

  15. January 11th, 2009 at 08:31 | #15

    Юрий, оцени пожалуйста программу, подготовленную для рабочей сессии с заказчиком (волнуюсь немного, первая встреча):

    Исходные данные
    - Формализация предпосылок и оснований для разработки проекта.
    - Необходимо дать общее описание ситуации и условий, в которых возникла идея создания проекта.
    Бизнес-возможности
    - Обсуждение и формализация бизнес-возможностей проекта.
    - Необходимо зафиксировать бизнес-возможности проекта: источники получения прибыли и/или иной выгоды.
    Формулирование бизнес-целей и критериев успеха
    - Формализация целей проекта и критериев успеха.
    - Необходимо сформулировать конечную цель (цели) проекта и критерии её (их) достижения (как мы поймём, что мы достигли цели).
    Описание целевой аудитории
    - Определение и сегментация целевой аудитории.
    - Необходимо в общем описать целевую аудиторию и составить портреты типовых пользователей (персонажи).
    Пользовательские истории
    - Необходимо описать типовые истории использования системы пользователями (используя предопределённые персонажи).
    Образ решения
    - Необходимо сформулировать общее описание продукта, его функциональность, особенности.
    Масштабы и ограничения
    - Необходимо определить функциональность, реализуемую в первой версии продукта, функциональность последующих версий, а также рамки проекта – функциональность, которая вообще не будет реализована в проекте.
    Приоритеты проекта
    - Необходимо распределить по степени важности следующие параметры проекта:
    - объём функциональности;
    - качество;
    - сроки реализации
    - бюджет.

    Из поста сделал выводы, что по возможности следует набросать низкоуровневые wireframes, а также определить основные сущности и их атрибуты. Можно про сущности с атрибутами поподробнее, на примерах?

  1. June 5th, 2007 at 11:07 | #1
  2. July 26th, 2007 at 11:50 | #2
  3. December 18th, 2007 at 14:17 | #3
  4. December 27th, 2007 at 12:20 | #4
  5. March 7th, 2008 at 11:34 | #5
  6. August 29th, 2009 at 00:44 | #6