Привет, меня зовут Максим, я дизайнер и сооснователь Marquiz.ru. В этой статье поделюсь тем, как выстроен продуктовый процесс в команде Марквиз, расскажу принципы создания и безопасного внедрения в своей команде.
В незрелых компаниях к дизайнеру относятся как к рисовальщику: продакт приходит с готовым макетом и ждет красивых кнопок. В такоме случае, задача состоит не только в том, чтобы нарисовать идеальный процесс, но и создать культуру дизайна в компании через последовательные успехи, рост доверия, изменения в процессах и оргструктуре. В зависимости от зрелости организации есть 2 основных сценария:
-
Вы в стартапе, культуры дизайна нет — взять лидерство и построить самостоятельно
-
Вы в большой организации или корпорации — получить доверие ключевых лиц, принимающих решения, стать полезным, договариваться об изменениях
Для того, чтобы обеспечить высокую степень самореализации дизайнера в продукте, позаботьтесь о том, чтобы к дизайнерам приходили с запросом или исследованием, а не готовым решением.
Как создать хороший процесс
Чтобы создать хороший процесс попробуйте ответит на вопросы из этого списка:
- Какие есть роли в этом процессе
- За что они отвечают, какие бывают зоны ответственности
- Кто с кем взаимодействует, по каким правилам
- Когда заканчивается один этап и начинается следующий, как называются эти этапы
- Что является результатом каждого этапа, а что — системы в целом
Визуальный язык описания процессов
Для описание бизнес-процессов существует визуальный язык — BPMN (Business Process Model and Notation). Им пользуются бизнес-аналитики для наведения порядка в процессах. Нам как дизайнерам необязательно его выучить, но знать некоторые базовые принципы полезно.
В BPMN для каждого типа события и связи существуют своё конкретное отображение, это помогает избавиться от двусмысленности символов и интерпретаций. Пожалуй, это и есть самое важное — добавление ясности за счёт создания единого визуального языка.
Визуальная схема продуктового процесса в Марквиз
5 этапов продуктового процесса в Марквиз
Описание задачи → Поиск решения → Ревью решения → Проработка карточки → Готово в разработку
1. Описание задачи
- Продакт, продакт-оунер или дизайнер заводит задачу на доску задач в бэклоге.
- Описывает задачу через Job Story
- Как мы будем считать успех: Исследование или метрика
- Заполняет статусы, определяет приоритет
- Назначает ответственного дизайнера
Хорошо подумайте: какие роли и какого грейда в вашей команде уполномочены заводить карточки? Если чёткого распределения нет, установите правило на 2.3 Законодательные встречи, шаблон.
2. Поиск решения- Карточка находится у дизайнера и прорабатывается до понятных визуальных артефактов, на основе которых можно вести предметное обсуждение и тестирование.Double Diamond дизайн-процесс:Исследование → Понимание проблемы → Детализация → Тестирование
- Обсуждение промежуточных решений с дизайнерами на Дизайн-митапе
- Тестирование решения с пользователями.
1. Подготовка к презентации решения
- Называем задачу и ссылаемся на карточку задачи
- Напоминаем контекст задачи: какую проблему решаем
- Какое решение предлагаем и почему считаем, что оно сработает. Прикрепляем скрины, видео или прототип, аргументируем то, что сделали.
- Задаём вопрос, на счёт каких элементов или решений нужна обратная связь
2. Презентация решения
Дизайнер публикует в канале Слэка своё решение в письменной форме, если задача сложная — организует созвон с ключевыми ролями круга «Продукт».
В нашем случае ключевые роли участвующие в обсуждении: продакт-аналитик, продакт-исследователь, продакт-оунер, системный аналитик, лидер круга «Пользовательский опыт», лидер круга «Чистый код». (Марквиз организован по Холакратии).
3. Интеграция возражений
Понимаем, с чем имеем дело: реакция, мнение, вопрос
- Реакцию игнорируем или просим озвучить своё конкретное предложение
- Мнение — уточняем, на основании чего такое мнение. Стараемся понять чужую точку зрения. Берём в доработку, либо оставляем текущее решение.
- Вопрос — даём исчерпывающий ответ, уточняем.
- Если нет валидного возражения в течение 48 часов, ревью считается пройденным и карточку двигаем дальше.
Проходит все этапы уточнения с дизайнером до передачи в разработку. На этом этапе изменения концепта и улучшения не вносятся.
Дополнительные вопросы по логике, недостающие макеты или состояния, уточнение анимаций, текстов.
5. Готово в разработкуКарточка ждет своего разработчика в порядке приоритета.
Как безопасно внедрить новый процесс
Изменения правил, процессов, создание новых ролей или обязательств в моей команде происходит на законодательных встречах. Это специальный тип встреч с четким алгоритмом и фасилитатором, где решения принимаются консентом. Консент, в отличие от консенсуса, требующего единогласного решения всех участников, требует лишь отсутствие аргументированных возражений о вреде. — «Видишь ли ты вред?»
Я подробнее рассказываю о законодательных встречах, о дизайн-менеджменте и о том, как системно строить сильные продукты в своем телеграм-канале.
