Идеология продуктового подхода: от хаоса к водопаду

Предыстория

Я работал в компании DEVIM в качестве продуктового дизайнера. Первый заказ мы получили на разработку системы из веб-приложений для одной известной кредитно-финансовой организации. В команде дизайнеров нас было трое. Процесса проектирования не было. Все старались продвигать дизайн-процессы, как могли, но потом поняли, что надо взяться за это и структурировать наши действия.

Проблема

Команда дизайнеров одновременно работала над одним проектом, разделяя между собой функций проектирования и работая совместно над общей концепцией продукта.

Проектирование начиналось со спонтанно выбранных артефактов: карта взаимодействия, пользовательские сценарии, пользовательские истории или сразу приступали к формированию гипотез. Без очевидного понимания требований проектирование переходило на стадию формирования гипотез. Гипотезы не подтверждались очень долго, и приходилось возвращаться к требованиям, дополнять их и создавать новые гипотезы. Только формирование и тестирование гипотез могло занимать месяц и более.

Обострение

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

Команда не могла приступить к следующему проекту, пока не были закончены доработки и согласования по проекту в работе.

Когда ответственные все — никто не ответственен. Внутри команды четкого распределения не было. Поэтому проводились долгие дискуссии и обсуждения какое решение будет реализовано. Как результат — разлад и деморализация команды.

Переходный период

Команда дизайна пришла к выводу, что процесс необходимо урегулировать.

Для этого нам было необходимо:

  • Получать максимально точные требования и участвовать в их формировании
  • Правильно понимать требования
  • Отслеживать учитывание всех требований
  • Рационально использовать время команды

Новый процесс

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

Описание этапов

1. Бизнес-анализ

Для чего этап: выявить и зафиксировать требования от бизнеса.

Цели с измеримым критерием — действительный пункт назначения. Помогает понять результат, чтобы цель считалась достигнута.

Список бизнес-запросов — субъективное видение продукта со стороны бизнеса. Список требований, без которых продукт не может существовать. Помогает определить полный объем проекта.

Фиксация бизнес-процессов (текущих и требуемых) — описание последовательностей действий, направленных на оказание услуг. Помогает описать истории и сценарии.

Описание сегментов ЦА — конкретные группы людей, на которые направлены все маркетинговые коммуникации бренда. Помогает создать персон.

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

Конкурентный анализ. Идентификация конкурирующих продуктов и компаний. Помогает понять сильные и слабые стороны конкурирующих продуктов.

2. Пользовательский анализ

Для чего этап: проанализировать кто является пользователем продукта и какие у него есть потребности.

Персоны\роли. Формируются из описания сегментов ЦА. Помогают команде проявлять эмпатию к пользователям. Для создания использовали принципы, описанные у Алана Купера в книге «Интерфейс. Основы проектирования взаимодействия»

Интервьюирование пользователей\бизнеса. Помогает выявить истории и сценарии поведения персон.

Пользовательская история — это ситуация, в которую попадает персона. Помогает понять проблемы персон. Пример: Я как пользователь, хочу авторизоваться в личном кабинете, чтобы узнать статус моей заявки.

Скоп итераций — это набор историй, которые будут разрабатываться в текущей версии продукта. Помогает понять объем текущей разработки. Выявить скоп и концепцию помогает книга Карла И. Вигерса и Джой Битти «Разработка требований к программному обеспечению»

Оценка. Оценивается скоп по срокам работ.

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

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

3. Проектирование взаимодействия

Для чего этап: составить полное представление о взаимодействиях пользователя.

Карта взаимодействия — это карта всех путей и решений, необходимых пользователю для прохождения по всем сценариям. Помогает интегрировать бизнес-запросы в продукт.

Тестирование карты взаимодействия. Проводится на пользователях или бизнесе в соответствии с разработанными сценариями. Помогает удостовериться в том, что взаимодействие пользователя затрагивает все бизнес-требования. Проводится путем интервьюирования пользователей и сверки их ответов с картой взаимодействия.

Карта взаимодействия распечатана для тестирования

Сбор фидбэка. Принимается решение о необходимости повторить этап проектирование взаимодействия сначала.

Варианты использования — это финальные документы к этапу проектирования взаимодействия на основе карты взаимодействия, которые будут описывать необходимые элементы интерфейса и его ограничения. На этом этапе могут подключиться QA, чтобы уточнить требования к интерфейсу. Помогает определить, какие элементы интерфейса необходимо разработать и с какими состояниями.

4. Формирование и проверка гипотез

Для чего этап: быстро сформировать и проверить идеи.

Прототип с низкой детализацией — это скетчи для быстрой демонстрации гипотезы. Помогают быстро визуализировать гипотезу. Могут использоваться бумажные скетчи, карточная сортировка, быстрые макеты в Axure или Sketch + библиотека элементов + Invision. На этом этапе главное — не сильно вдаваться в детали отрисовки, а уделить больше внимания архитектурному решению.

Пользовательское тестирование.Пользователь проходит по сценарию, используя прототип с низкой детализацией. Помогает проверить гипотезы.

Сбор фидбэка от пользователя. Оценивается прохождение истории по KPI на каждую разработанную историю. Принимается решение о необходимости сделать повторить проверку гипотезы или изменить ее.

Демонстрация команде.Команда дает технические советы по реализации гипотезы. Помогает понять сложные места в интерфейсе.

Сбор фидбэка от команды. Принимается решение о необходимости пересмотра гипотезы.

5. Проектное решение

Для чего этап: предоставить готовое решение для передачи в разработку.

Компоненты интерфейса — это детализированные макеты проверенных гипотез. Создается библиотека элементов в Sketch, которая переносится в Craft для общего доступа. Это делается для упрощения дальнейшей поддержки проекта.

Интерфейсная анимация. Описывается или демонстрируется на интерактивных прототипах или видео. Помогает разработке понять микроанимацию. Она важна при проектировании интерфейсов, так как помогает понять пользователю поведение интерфейса.

Прототип с высокой детализацией — это собранный из компонентов и анимации интерфейс, максимально приближенный к реальному поведению. Осуществляется с помощью Invision для несложной анимации и Principle для более детальной.

Финальное пользовательское тестирование.Пользователь проходит по сценарию, используя прототип с высокой детализацией. Помогает определить слабые моменты в компонентах интерфейса и анимации.

Валентин Спицын проводит тестирование

Сбор фидбэка от пользователя. Принимается решение о необходимости сделать итерацию этапа проектное решение.

6. Исследование

Для чего этап: проверить работу пользователей с реальным продуктом.

Тестирование готового продукта пользователем. Проводится оценка эффективности системы и выявляется, как реально работает пользователь с продуктом. Определяются новые механики в поведении.

Пользовательские отклонения. Формируются новые пользовательские истории. Выявляются новые механики, связанные с использованием нового функционала. Отмечается функционал, который работает плохо согласно KPI.

Оценка. Оценивается скоп новых пользовательских историй и возможный срок работ.

Передача в разработку

Для передачи в разработку необходимы документы, макеты и прототипы всех предыдущих этапов, которые прошли тестирование.

Хинт

Чтобы этот процесс работал, необходимо разделить ответственность между дизайнерами. Дизайн команда остается командой. Но дизайнер берет ответственность за определенные проекты на себя и является «проектным лидом» внутри команды.

Вся коммуникация по проекту идёт через проектного лида: между проджект-менеджером и командой дизайнеров, между разработчиками и командой дизайнеров.

Помимо этого, проектный лид отвечает за дальнейшее сопровождение проекта — проводить новые исследования, внедрять новые требования.

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

Итог

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

Плюсы для нового процесса

  • Проектирование идет более маленькими этапами
  • Нет необходимости возвращаться к предыдущему этапу
  • Каждый этап является опорой для следующего в аргументации решений
  • Работа над несколькими проектами ведется параллельно
  • Тестирование на каждом этапе приводит к более качественному решению по проекту

Минусы нового процесса

Но в каждой ложке меда есть капля дегтя.

  • Каждый новый функционал должен пройти через все этапы
  • Кажется для заказчика долгим и дорогим, однако таким не является.
  • Трудно собрать команду с равным опытом

Требования у заказчиков часто размытые, они сами не знают, чего хотят. Или хотят несовместимых вещей, а ведь на каждом этапе необходимо сверяться с начальными бизнес-требованиями. Соглашусь, процесс выглядит сложно и ресурсоемко, однако, это не так. Работая по такому процессу, первый же проект был спроектирован и протестирован за 3 недели до состояния MVP и передан в разработку.

Спасибо команде дизайнеров DEVIM за потрясающий опыт.