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

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

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

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

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

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

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

Подписаться на рассылку

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


29 comments

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

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

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

  2. Паша,

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

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

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

  4. Паша,

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

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

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

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

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

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

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

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

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

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

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

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

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*
*

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.