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

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

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

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

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

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

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

Написано May 28th, 2007 · RSS комментариев · Темы: Workshops · Начало проекта · Пользовательские интерфейсы · Практика · Проект-менеджмент · Проектирование · Юзабилити

Подпишитесь на RSS-ленту блога, чтобы сразу получать свежие записи