Стартуем проекты. Удачная рабочая сессия
На днях вернулся из командировки — делаем интерфейс для одного интересного российского стартапа. Старые знакомые, с которыми уже работали прошлым летом. Особенно здорово в этом, что они отлично знают о полезности детального проектирования. Тем более в условиях, когда сама концепция проекта еще только начинает переноситься из головы на бумагу.
В условиях работы над стартапом, когда есть общее представление и очень мало конкретики, объем и трудоемкость работ оценить сложно. Хороший способ разрулить эту коллизию — устроить плотную рабочую сессию с заказчиком. В ходе этой серии обсуждений четко описывается, что должна делать система и как. Тут работает принцип “пока рассказывал, сам понял” — функциональность проговаривается по нескольку раз. И по ходу этих обсуждений снимаются неувязки, всплывает забытое и отбрасывается ненужное.
Первым результатом нашего обсуждения стали персонажи ключевых пользователей и их user stories. Персонажи приобрели цели, задачи и общий бекграунд. А их user stories описали, каким образом функциональность системы позволяет пользователю выполнить задачи и достичь своих целей — то есть примерный алгоритм работы с системой. В нашем случае персонажами выступили, скажем, автор и редактор (назову их так, чтобы не навредить создателям проекта). Цели автора — создать хороший материал и получить за него приемлемую оценку. А вот его задачи уже более приземленные:
- найти подходящие источники для материала;
- выцепить из них необходимую информацию;
- подготовить текст материала;
- получить от редактора подтверждение того, что материал хорош;
- при необходимости внести исправления в материал.
Зная эти задачи, мы спускаемся на уровень интерфейса. Например, найти подходящие источники автор может с помощью каталога, поиска или рекомендаций. Это уже функциональность системы, которую необходимо реализовать. Добавим сюда служебные и сервисные страницы — например, ведение учетной записи пользователя (регистрация, авторизация и т.п.). И получим на выходе процентов на 90 точный перечень ключевых страниц интерфейса, которые необходимо отразить в спецификации. А также набор функциональности, которая должна быть в системе.
Здорово, если в рамках этой сессии получается набросать низкоуровневые wireframes — на уровне набора блоков (“черных ящиков”), содержащихся на странице. На бумаге или в электронном виде — не так важно. Это позволяет проговорить функциональность еще глубже, максимально приблизившись к конкретике. Также полезно определиться с составом интерактивного прототипа – задача это достаточно трудоемкая и лишнюю работу в ее рамках делать не стоит. На это во многом влияет цель, с которой он создается — юзабилити-тестирование или презентация инвесторам.
На этом мы и закончили рабочую сессию. У меня на руках оказался достаточный пакет материалов, чтобы спланировать работы по проекту. Кроме того, сложилась четкая картинка интерфейса системы — теперь его осталось только глубоко детализировать. Не забыли и про спецификацию — business rules, сущности и их атрибуты, особенности реализации и прочие технические моменты. Ну и контакты, которым можно задать любые уточняющие вопросы. После того как ключевые детали прояснились, их список не будет многостраничным.
29 Comments
Leave a comment
Руководитель отдела проектирования и дизайна интерфейсов Mail.Ru. Работаю над коммуникационными и мобильными сервисами компании, а также общепортальными задачами.
Вакансии в интерфейсной команде Mail.Ru
- Дизайнер Почты Mail.Ru
Приоритетное направление со множеством интересных и сложных задач. Пользователи Почты Mail.Ru — это десятки миллионов людей. - Дизайнер мобильных сайтов и приложений
iOS, Android, Windows Phone, Symbian, J2ME, Bada. - Дизайнер для Futubra, нового продукта
Создавать совершенно новый проект. Такой дизайнер сделает 665 концепций и будет полон сил для 666-й. Он делает работу быстро, просто, эффектно. В его голове полно идей, он постоянно ими делится, но знает, что цена идеи самой по себе стремится к нулю и ни за одну не держится на смерть. У него есть в кармане пачка решений необычных задач. А если и нет, он знает, где такие решения найти. - Дизайнер стратегических продуктов
Работа над Почтой, главной страницей и другими продуктами.
Где-то я эту шапочку в визио уже видел!
Это я, Максим, у Лебедева заимствовал — ему можно верить! :)
[...] закончил и отправил коммерческое предложение на проектирование интерфейса одного российского стартап…. Не проходит и получаса, как сваливается новый запрос [...]
[...] закончил и отправил коммерческое предложение на проектирование интерфейса одного российского стартап…. Не проходит и получаса, как сваливается новый запрос [...]
А в чем все это нарисовано?
Это MS Office Visio — все wireframes рисую в нем.
2003?
Кстати, нотификации на емейл не ходят.
Да, 2003й. Но они все начиная с 2002 более-менее пристойные.
Нотификации попробовал починить — надеюсь, сработало :) Спасиб за информацию!
Я поэтому и спросил – сам пользуюсь 2002, оно не очень-то похоже визуально.
Нотификации нашел. В спаме. Странно, в CBL вашего домена нет :)
А это стенсил специальный, вот и не похож :) По функциональности что 2002, что 2007 — отличаются минимально.
Насчет попадания в спам — странно, возможно рассылающий нотификации плагин спамоподобно письма формирует.
>А это стенсил специальный
А скачать его где-нибудь можно?
Я использую сильно доработанный напильником стенсил Garrett Dimon: v1.garrettdimon.com/resources/templates-stencils-for-visio-omnigraffle — там есть версия и для Visio 2002.
[...] предварительный анализ и оценка проекта. Заказчик и подрядчик строят общую картинку будущей системы, оценивают работы по стоимости и времени и планируют их; [...]
[...] предварительный анализ и оценка проекта. Заказчик и подрядчик строят общую картинку будущей системы, оценивают работы по стоимости и времени и планируют их; [...]
[...] шаг — это предпроектный анализ. Нужно понять, что же все-таки требуется сделать. [...]
[...] шаг — это предпроектный анализ. Нужно понять, что же все-таки требуется сделать. [...]
[...] Еще раньше запустился Валентин Гернович, тим-лидер команды разработчиков стартующего в феврале масштабного проекта нашей компании. На valentin.gernovich.com он пишет о процессе и деталях разработке. А с запуском того самого проекта расскажет много интересных технических деталей. Я, кстати, как-то писал о том, как здорово он презентовал основные из них заказчику. [...]
[...] Еще раньше запустился Валентин Гернович, тим-лидер команды разработчиков стартующего в феврале масштабного проекта нашей компании. На valentin.gernovich.com он пишет о процессе и деталях разработке. А с запуском того самого проекта расскажет много интересных технических деталей. Я, кстати, как-то писал о том, как здорово он презентовал основные из них заказчику. [...]
Юра, в кратком обзоре процесса ты эта озаглавил всё это как предпроектный анализ. Хотел бы уточнить артефакты которые были на входе и получились на выходе.
Я успел высмотреть следующие
- Описание персонажей(задачи и цели) и их user stories
- Низкоуровневый прототип (в идеале – детализированный)
- Куски функциональной спецификации исходя из пользовательских задач и прототипа
А что ты имел в виду тут?
“Не забыли и про спецификацию — business rules, сущности и их атрибуты, особенности реализации и прочие технические моменты”
Что тут в результате создается ?
Если можно перечисли все полученные артефакты на всём этапе. Спасибо.
Паша,
На входе был поток сознания клиента и пара набросков ключевых страниц. На выходе после рабочей сессии получилось вот что:
— перечень и краткое описание персонажей;
— набросок карты сайта;
— наброски схем страниц на бумаге (это очень и очень низкоуровневый бумажный прототип :) );
— перечень user stories с примерной оценкой страниц для каждой;
После того как обсуждение закончилось, я привел это все в порядок и получил:
— описание персонажей;
— карта сайта и схема навигации — в каких меню какие разделы будут отображаться;
— низкоуровневые wireframes, как на скриншоте в статье;
— расписанные в базовом виде user stories — как раз вышла нулевая часть статьи о них;
— куски спецификации — описание хитрых алгоритмов работы со сторонней базой данных. Тут вообще в достаточно свободной форме все, описана бизнес-логика работы связки пользователь/наша система/сторонняя система, требования к безопасности и т.п.;
Примерно так. Заняло все это вместе с написанием коммерческого предложения и договора неделю.
Юра, спасибо тебе большое за ответ. Учусь на твоих статьях и на твоём опыте. Ты как Прометей несёшь людям огонь юзабилити. Жду анонсированных материалов.
В планируемой своей статье о персонажах буду ссылаться на тебя
Паша,
До Прометея мне еще далеко, но здорово что получается помогать :) Сейчас плотно занят написанием пачки статей для нового сайта моего отдела — так что текстов в феврале будет адски много :) За будущие ссылки тоже спасиб :)
[...] как-то писал о рабочей сессии для другого проекта. Впрочем, тогда нам было важно проработать [...]
[...] как-то писал о рабочей сессии для другого проекта. Впрочем, тогда нам было важно проработать [...]
Юрий, оцени пожалуйста программу, подготовленную для рабочей сессии с заказчиком (волнуюсь немного, первая встреча):
Исходные данные
- Формализация предпосылок и оснований для разработки проекта.
- Необходимо дать общее описание ситуации и условий, в которых возникла идея создания проекта.
Бизнес-возможности
- Обсуждение и формализация бизнес-возможностей проекта.
- Необходимо зафиксировать бизнес-возможности проекта: источники получения прибыли и/или иной выгоды.
Формулирование бизнес-целей и критериев успеха
- Формализация целей проекта и критериев успеха.
- Необходимо сформулировать конечную цель (цели) проекта и критерии её (их) достижения (как мы поймём, что мы достигли цели).
Описание целевой аудитории
- Определение и сегментация целевой аудитории.
- Необходимо в общем описать целевую аудиторию и составить портреты типовых пользователей (персонажи).
Пользовательские истории
- Необходимо описать типовые истории использования системы пользователями (используя предопределённые персонажи).
Образ решения
- Необходимо сформулировать общее описание продукта, его функциональность, особенности.
Масштабы и ограничения
- Необходимо определить функциональность, реализуемую в первой версии продукта, функциональность последующих версий, а также рамки проекта – функциональность, которая вообще не будет реализована в проекте.
Приоритеты проекта
- Необходимо распределить по степени важности следующие параметры проекта:
- объём функциональности;
- качество;
- сроки реализации
- бюджет.
Из поста сделал выводы, что по возможности следует набросать низкоуровневые wireframes, а также определить основные сущности и их атрибуты. Можно про сущности с атрибутами поподробнее, на примерах?
[...] шаг – это предпроектный анализ. Нужно понять, что же все-таки требуется сделать. [...]
[...] шаг – это предпроектный анализ. Нужно понять, что же все-таки требуется сделать. [...]
[...] самом блоге на смену рабочему дневнику с короткими записями, которые можно было набросать за пару часов в поезде [...]
[...] [...]