На днях вернулся из командировки — делаем интерфейс для одного интересного российского стартапа. Старые знакомые, с которыми уже работали прошлым летом. Особенно здорово в этом, что они отлично знают о полезности детального проектирования. Тем более в условиях, когда сама концепция проекта еще только начинает переноситься из головы на бумагу.
В условиях работы над стартапом, когда есть общее представление и очень мало конкретики, объем и трудоемкость работ оценить сложно. Хороший способ разрулить эту коллизию — устроить плотную рабочую сессию с заказчиком. В ходе этой серии обсуждений четко описывается, что должна делать система и как. Тут работает принцип “пока рассказывал, сам понял” — функциональность проговаривается по нескольку раз. И по ходу этих обсуждений снимаются неувязки, всплывает забытое и отбрасывается ненужное.
Первым результатом нашего обсуждения стали персонажи ключевых пользователей и их user stories. Персонажи приобрели цели, задачи и общий бекграунд. А их user stories описали, каким образом функциональность системы позволяет пользователю выполнить задачи и достичь своих целей — то есть примерный алгоритм работы с системой. В нашем случае персонажами выступили, скажем, автор и редактор (назову их так, чтобы не навредить создателям проекта). Цели автора — создать хороший материал и получить за него приемлемую оценку. А вот его задачи уже более приземленные:
- найти подходящие источники для материала;
- выцепить из них необходимую информацию;
- подготовить текст материала;
- получить от редактора подтверждение того, что материал хорош;
- при необходимости внести исправления в материал.
Зная эти задачи, мы спускаемся на уровень интерфейса. Например, найти подходящие источники автор может с помощью каталога, поиска или рекомендаций. Это уже функциональность системы, которую необходимо реализовать. Добавим сюда служебные и сервисные страницы — например, ведение учетной записи пользователя (регистрация, авторизация и т.п.). И получим на выходе процентов на 90 точный перечень ключевых страниц интерфейса, которые необходимо отразить в спецификации. А также набор функциональности, которая должна быть в системе.
Здорово, если в рамках этой сессии получается набросать низкоуровневые wireframes — на уровне набора блоков (“черных ящиков”), содержащихся на странице. На бумаге или в электронном виде — не так важно. Это позволяет проговорить функциональность еще глубже, максимально приблизившись к конкретике. Также полезно определиться с составом интерактивного прототипа — задача это достаточно трудоемкая и лишнюю работу в ее рамках делать не стоит. На это во многом влияет цель, с которой он создается — юзабилити-тестирование или презентация инвесторам.
На этом мы и закончили рабочую сессию. У меня на руках оказался достаточный пакет материалов, чтобы спланировать работы по проекту. Кроме того, сложилась четкая картинка интерфейса системы — теперь его осталось только глубоко детализировать. Не забыли и про спецификацию — business rules, сущности и их атрибуты, особенности реализации и прочие технические моменты. Ну и контакты, которым можно задать любые уточняющие вопросы. После того как ключевые детали прояснились, их список не будет многостраничным.
29 comments
Где-то я эту шапочку в визио уже видел!
Это я, Максим, у Лебедева заимствовал — ему можно верить! 🙂
А в чем все это нарисовано?
Это MS Office Visio — все wireframes рисую в нем.
2003?
Кстати, нотификации на емейл не ходят.
Да, 2003й. Но они все начиная с 2002 более-менее пристойные.
Нотификации попробовал починить — надеюсь, сработало 🙂 Спасиб за информацию!
Я поэтому и спросил – сам пользуюсь 2002, оно не очень-то похоже визуально.
Нотификации нашел. В спаме. Странно, в CBL вашего домена нет 🙂
А это стенсил специальный, вот и не похож 🙂 По функциональности что 2002, что 2007 — отличаются минимально.
Насчет попадания в спам — странно, возможно рассылающий нотификации плагин спамоподобно письма формирует.
>А это стенсил специальный
А скачать его где-нибудь можно?
Я использую сильно доработанный напильником стенсил Garrett Dimon: http://v1.garrettdimon.com/resources/templates-stencils-for-visio-omnigraffle — там есть версия и для Visio 2002.
Юра, в кратком обзоре процесса ты эта озаглавил всё это как предпроектный анализ. Хотел бы уточнить артефакты которые были на входе и получились на выходе.
Я успел высмотреть следующие
– Описание персонажей(задачи и цели) и их user stories
– Низкоуровневый прототип (в идеале – детализированный)
– Куски функциональной спецификации исходя из пользовательских задач и прототипа
А что ты имел в виду тут?
“Не забыли и про спецификацию — business rules, сущности и их атрибуты, особенности реализации и прочие технические моменты”
Что тут в результате создается ?
Если можно перечисли все полученные артефакты на всём этапе. Спасибо.
Паша,
На входе был поток сознания клиента и пара набросков ключевых страниц. На выходе после рабочей сессии получилось вот что:
— перечень и краткое описание персонажей;
— набросок карты сайта;
— наброски схем страниц на бумаге (это очень и очень низкоуровневый бумажный прототип 🙂 );
— перечень user stories с примерной оценкой страниц для каждой;
После того как обсуждение закончилось, я привел это все в порядок и получил:
— описание персонажей;
— карта сайта и схема навигации — в каких меню какие разделы будут отображаться;
— низкоуровневые wireframes, как на скриншоте в статье;
— расписанные в базовом виде user stories — как раз вышла нулевая часть статьи о них;
— куски спецификации — описание хитрых алгоритмов работы со сторонней базой данных. Тут вообще в достаточно свободной форме все, описана бизнес-логика работы связки пользователь/наша система/сторонняя система, требования к безопасности и т.п.;
Примерно так. Заняло все это вместе с написанием коммерческого предложения и договора неделю.
Юра, спасибо тебе большое за ответ. Учусь на твоих статьях и на твоём опыте. Ты как Прометей несёшь людям огонь юзабилити. Жду анонсированных материалов.
В планируемой своей статье о персонажах буду ссылаться на тебя
Паша,
До Прометея мне еще далеко, но здорово что получается помогать 🙂 Сейчас плотно занят написанием пачки статей для нового сайта моего отдела — так что текстов в феврале будет адски много 🙂 За будущие ссылки тоже спасиб 🙂
Юрий, оцени пожалуйста программу, подготовленную для рабочей сессии с заказчиком (волнуюсь немного, первая встреча):
Исходные данные
– Формализация предпосылок и оснований для разработки проекта.
– Необходимо дать общее описание ситуации и условий, в которых возникла идея создания проекта.
Бизнес-возможности
– Обсуждение и формализация бизнес-возможностей проекта.
– Необходимо зафиксировать бизнес-возможности проекта: источники получения прибыли и/или иной выгоды.
Формулирование бизнес-целей и критериев успеха
– Формализация целей проекта и критериев успеха.
– Необходимо сформулировать конечную цель (цели) проекта и критерии её (их) достижения (как мы поймём, что мы достигли цели).
Описание целевой аудитории
– Определение и сегментация целевой аудитории.
– Необходимо в общем описать целевую аудиторию и составить портреты типовых пользователей (персонажи).
Пользовательские истории
– Необходимо описать типовые истории использования системы пользователями (используя предопределённые персонажи).
Образ решения
– Необходимо сформулировать общее описание продукта, его функциональность, особенности.
Масштабы и ограничения
– Необходимо определить функциональность, реализуемую в первой версии продукта, функциональность последующих версий, а также рамки проекта – функциональность, которая вообще не будет реализована в проекте.
Приоритеты проекта
– Необходимо распределить по степени важности следующие параметры проекта:
– объём функциональности;
– качество;
– сроки реализации
– бюджет.
Из поста сделал выводы, что по возможности следует набросать низкоуровневые wireframes, а также определить основные сущности и их атрибуты. Можно про сущности с атрибутами поподробнее, на примерах?