-
All responses Most smiled responses
-
Мы пишем концепцию в двух вариантах. Первый -- на этапе предварительной продажи, когда в общих чертах описывается будущий продукт, его целевая аудитория, цели создания, возможности, как и зачем он будет использоваться, какие аналоги существуют в Рунете и в мире вообще. Это полу-формальное описание, для которого какого-то четкого формата нет, главное чтобы общий посыл был понятен и достаточен для предметного обсуждения и утверждения. Делается для более-менее крупных проектов, когда заказывается в том числе и общая проработка концепции.
Второй вариант -- это что-то среднее между описанием концепции и требований. Делается уже после начала работ по проекту, как правило выделяется в отдельный этап и договор -- сложно подписываться на детальное проектирование, дизайн и разработку, когда будущий продукт описан только в общих чертах. По ходу работ мы "сверяем с заказчиком часы"; ищем и устраняем белые пятна в концепции; изучаем предметную область, рынок и целевую аудиторию; выявляем требования на различных уровнях (бизнес-, пользовательские, функциональные и т.п.).
Результат этапа -- набор документов, описывающих концепцию. Как правило это видение проекта (http://www.uimodeling.ru/process/docs/vision.html), описание целевой аудитории и ее сценариев работы с продуктом (персонажи -- http://www.uimodeling.ru/process/docs/personas.html), краткие сценарии взаимодействия (http://www.uimodeling.ru/process/docs/use-cases.html), перечень функциональности (http://www.uimodeling.ru/process/docs/user-stories.html), wireframes roadmap. Плюс результаты предварительного проектирования (карта сайта, схема навигации, первые wireframes), а также разные вспомогательные документы, если необходимо -- например, спецификация контента/сущностей, описание механизмов социализации пользователей и т.п.. Ну и по окончании этапа у нас уже есть более четкое представление об объеме работ и потенциальных рисках, так что можно давать более-менее точную смету на детальное проектирование, дизайн и разработку. -
Сейчас есть большая путаница в названиях наук, дисциплин, подходов и методов, связанных с интерфейсами -- user experience, usability, information architecture, human-computer interaction, user-centered design, user interface design, interaction design и т.п. Кто-то использует названия по делу, кто-то путает их местами, кто-то сам себе рождает термины вроде "юзабилити-проектирования" (хотя английский вариант термина -- usability engineering -- звучит более-менее пристойно). Я бы в этот терминологический спор влезать не стал, хотя на пальцах, а не в виде текста, объяснить смог бы. Иван Дегтяренко несколько лет назад сделал подробное исследование темы терминологии, я бы посоветовал полистать ее -- http://www.gui.ru/ivan/terminilogy_wars_1/.
-
Буду банален -- все сильно зависит от типов проектов, их длительности, ролей в команде (не только специализаций) и т.п.. Процесс должен быть гибким -- где-то усложняться, где-то упрощаться в зависимости от проектных задач. Инструменты также должны соответствовать процессу -- тот же Визио может быть чересчур громоздким, если рисуешь пару wireframes в месяц, но очень мощным и тонко подстраиваемым, если ты их делаешь сотню. (тут вода заканчивается)
Я бы задал несколько вопросов, исходя из которых давал рекомендации:
1) Работает ли команда сама по себе или связана с другими группами (заказчик и его представители, сторонняя группа разработки)? Т.е. документы будут использоваться внутри команды или должны выдаваться наружу.
2) Делается один большой проект или есть регулярный поток проектов? Может ли идти несколько проектов одновременно? Т.е. нужно ли выстраивать какой-то процесс, который будет повторяться на новых проектах, а значит его можно будет оптимизировать и накапливать знания/опыт.
3) Если команда маленькая, то как распределяются роли внутри нее? Будет ли, например, работа аналитика переложена на менеджера или будет распределена между ним и проектировщиком?
Я бы выделил несколько группы инструментов:
1) Создание проектной документации.
Для небольшой команды оптимально, как мне кажется, использовать Axure (http://www.axure.com/) или Balsamiq (http://www.balsamiq.com/) в качестве средства отрисовки wireframes. Сейчас появляются более комплексные инструменты, которые позволяют вести весь процесс (описание требований, проектирование, создание интерактивного прототипа, тестирование интерфейса) -- например, JustInMind Prototyper (http://www.justinmind.com/wireframe/justinmind_prototyper). Есть, кстати, большой и полный список таких инструментов -- http://ciohappyhour.com/wp-content/uploads/2009/10/ultimate%20wireframing%20toolbox.html.
Требования можно описывать в виде отдельных документов, если это нужно отдавать наружу (лучше MS Office пока ничего не придумано), или в рамках веб-сервиса, если работа будет вестись внутри команды (вполне сгодится вики).
Для простой проверки интерфейсных решений можно пользоваться сервисами веб-аналитики типа Google Analytics (http://www.google.com/analytics/), WebVisor (http://www.webvisor.ru/), CrazyEgg (http://www.crazyegg.com/), а также инструментами для сбора фидбека типа Loop 11 (http://www.loop11.com/), Usabilla (http://usabilla.com/).
2) Обеспечение командной работы.
Сложно сказать, не зная процесса -- кому-то вполне хватает Basecamp (http://basecamphq.com/), для кого-то он слишком ограничен. Мы пользуемся Acunote (http://www.acunote.com/), простая и мощная штука. Остальное -- почта/Скайп/мессенджер. -
У нас есть 4 основных этапа работ:
1) Концепция. Это выявление, формирование и описание требований к системе, а также предварительные работы по проектированию.
2) Детальное проектирование интерфейса. Это проектирование конкретных страниц (wireframes и сопроводительные документы к ним).
3) Дизайн интерфейса. Это создание общей концепции, отрисовка ключевых страниц и подготовка сопроводительных элементов (пиктограммы, иллюстрации).
4) Поддержка внедрения. Это консультации команды разработки по внедрению, доработка "белых пятен" и нестыковок, сбор фидбека от пользователей и реакция на него. Здесь что-то идет как обновление созданных ранее документов, что-то в живом общении (разговоры, письма и т.п.).
В общих чертах схема работы и документы по каждому из этапов описаны у нас на сайте — http://www.uimodeling.ru/process. Она немного упрощенная -- постарались сделать описание не слишком грузящее клиента деталями, но и не совсем примитивное при этом. В дополнение к схеме есть различные вспомогательные или служебные документы, которые нужны всегда (например, wireframes roadmap или спецификация контента/сущностей) или на отдельных проектах (например, формулы работы рейтинга), а вносить их в общее описание смысла нет.
Общий посыл этого процесса -- документы создаются "каскадным" способом. Это значит, что каждый документ по цепочке служит основой для предыдущего. Например:
*) в видении мы кратко описываем целевую аудиторию и ее потребности;
*) в персонажах раскрываем ее подробно, с потребностями, контекстами и ключевыми сценариями;
*) в сценариях взаимодействия подробно расписываем упомянутые в персонажах ключевые сценарии.
Это позволяет, во первых, всегда видеть цепочку решений ("Почему у нас эта функция в user stories? Смотрим ключевые сценарии персонажей, для чего она служит."). Во-вторых, при завершении работы над каждым документом он готов примерно на 80%, а остальные 20% уточняются по ходу его обсуждения и работы над следующими документами. Это позволяет и процесс ускорить, и как-то жить с тем фактом что нельзя все специфицировать изначально. Еще на эту тему есть график работы команды проектирования в agile-процессе -- http://www.jvetrau.com/2008/07/01/proektirovanie-v-agile-protsesse-grafik-rabotyi-komand-razrabotki-i-analitiki/, там также описан процесс создания документов.
-
Loading...
Juras Vetrau’s Bio
UX designer from Saint-Petersburg, Russia. Chief of UI Modeling Company (http://www.uimodeling.ru/), author of http://www.jvetrau.com/.
