Как эффективно проектировать продукты и интерфейсы и не утонуть в деталях: журнал проектировщика

Как эффективно проектировать продукты и интерфейсы: журнал проектировщика — Андрей Шапиро

Когда в процессе решения сложной задачи проектирования объем информации начинает «съедать» вас и становится предельным, необходимо структурировать работу и детали проекта. Андрей Шапиро, арт-директор и партнер в Byndyusoft, рассказал о журнале проектировщика — инструменте, который помогает структурировать процесс проектирования, не размывать фокус и получить на выходе подробное описание проекта.

Проблемы проектирования систем

Рассеянность и неспособность уследить за целым

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

Чтобы обуздать ментальные метания, я рекомендую записывать в единый реестр всё, что появляется в ходе размышления. Это избавит от необходимости удерживать большой объем информации в голове, а значит, освободит когнитивный ресурс (см. опыты Канемана).

Обычная последовательность действий при этом такова:

  • Понять, что наш ум начал метаться, а мы увлеклись чем-то в ущерб проектированию.
  • Остановиться или намеренно замедлиться.
  • Перейти в режим журналирования — выложить все проблемы, гипотезы решений, противоречия, задачи, идеи на бумагу, доску или поля макета.
  • Удостовериться, что ум успокоился и можно двигаться дальше.

Предельная сложность

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

У меня когда-то был разговор с одним очень известным человеком (не буду называть фамилию), который во время аварийной ситуации вручную вывел реактор из закритического состояния. Много времени прошло, это уже пожилой человек с орденами и медалями. Я спрашиваю: «Как?» Он ответил: «Я моделировал в голове, что происходит с реактором». Так вот, сейчас нет человека, который может смоделировать в голове, что происходит в сложной системе. Технические системы по степени своей сложности вышли за пределы интуиции инженеров-конструкторов. 

П. Г. Шедровицкий, интервью «Эксперту»

Коммуникационные потери

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

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

«Инженерная онтология. Инженерия как странствие», В. Никитин, С. Переслегин и другие

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

Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Product Mindset, а обсудить любые продуктовые вопросы можно в Product Sense Chat.

Журнал проектирования как решение

Что происходит, когды мы пытаемся решить в голове задачу с предельной сложностью:

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

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

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

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

Журнал проектировщика — авторская компиляция из разных методик. Например, я взял некоторые подходы из метода организации работы Форстера в «Сделай это завтра» (фокус, неотвлечения, входящие) и у Щедровицкого в концепции программирования (иерархированные списки, категоризация). Эти идеи уже существовали, но я объединил и выкристаллизовал их в журнале проектирования — и наши дизайнеры его успешно применяют на практике.

Задачи журнала

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

Этапы работы с журналом

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

  1. Первичное складирование. На любом этапе работы всё, что приходит в голову, выгружается в условное пространство — что-то вроде папки «Входящие» в электронной почте. В этом процессе лучше просто фиксировать все новые мысли и не утруждать себя размышлениями. Важнее всего обеспечить беспрепятственную поставку в это место.
  2. Сортировка. Переформулируем выгруженные мысли и раскладываем их по категориям.
  3. Проверка записей. Закрываем все сложные моменты проектирования, проверяем и убеждаемся, что решение соответствует необходимым критериям и снимает проблемы.
  4. Чистка журнала. Перенос отработанного материала в хранилище знаний по проекту или продукту. К этому моменту часть вопросов превращается в ответы — обычно это предварительно сформулированные допущения или постулаты относительно устройства системы.

make sense #65: об особенностях продуктового дизайна, роли продакт-дизайнера и дизайне процессов с Александром Кудымовым

Формат журнала проектировщика

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

Я успел опробовать несколько форматов и инструментов. В основном все они отличались дихотомией «дробный — цельный». Отдельные записи удобны и полезны тем, что они изолированы и самодостаточны. Благодаря этому их проще воспринимать и изучать, но теряется общая картина. А большое цельное полотно текста хотя и наглядно показывает количество нерешенных вопросов и связи между ними, но усложняет работу — особенно с ростом объёма журнала. Классическое противоречие.

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

Заметки на полях макета — часть журнала проектировщика
Заметки на полях макета — часть журнала проектировщика

На изображении — заметки о проблемах, которые я обнаружил, пока размышлял над деталями макета. Я аккуратно сгруппировал их под заголовком «Проблемы» и вынес слева от макета. К некоторым из них мне в голову сразу пришли варианты решений — их я собрал в «Гипотезах».

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

Организационная структура журнала проектировщика
Организационная структура журнала проектировщика

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

По счастью, у нас есть множество инструментов для структурирования информации — в них можно группировать записи с помощью разнообразных иерархий: распахивающиеся списки иерархий, дерево страниц или списков. Хорошие примеры — Notion и Workflowy. Также существуют средства тегирования и динамической сборки документов по тегам — например, Airtable. Экспериментируйте в поиске своего лучшего формата.

Пример организации иерархий в Notion

Пример организации иерархий в Notion

Пример организации иерархий в Workflowy

Пример организации иерархий в Workflowy

Категории журнала

Это элемент вашей личной системы, в особенности, если вы работаете командой. О категориях важно договориться — на старте проекта или по ходу работы. Я обычно работаю с такими категориями.

  • Ситуация, сценарий
  • Проблема, нежелательный эффект
  • Задача
  • Идея
  • Противоречие
  • Критерий готовности / успешности
  • Договоренность
  • Цель

Привожу их в том порядке, в котором они обычно появляются у меня — от неопределенности до законченного решения. Я специально поставил «Цель» на последнее место. Да, чаще всего всё начинается именно с того, что мы её выявляем, но она кристаллизуется и превращается в конечную цель, которую все участники процесса проектирования понимают одинаково, на довольно поздней стадии работы над проектом.

Примеры категорий в журнале на основе Notion
Примеры категорий в журнале на основе Notion

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

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

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

Кто такой продуктовый дизайнер, что он делает и как с ним взаимодействовать?

Ведение журнала проектировщика на примере

Для примера возьмем отдельную задачу в процессе проектированию цифрового сервиса (маркетплейса), который помогает покупателю найти продавца и обезопасить сделку. Мы подключимся к проектированию, когда уже сформированы пользовательские сценарии и разберем эпизод выдачи предоплаченного товара. Он включает в себя такие сценарии:

  1. Когда заказ готов, покупателю приходит код выдачи. Он необходим продавцу для фиксации завершения сделки и разблокировки оплаты и вводится в специальное поле программы в пункте выдачи заказов.
  2. Продавец идентифицирует покупателя по ФИО или номеру телефона, после этого приносит товары для осмотра.
  3. Покупатель осматривает товары из своего заказа, убеждается, что это те самые позиции, которые он заказал, и с ним всё в порядке. После этого он сообщает код выдачи продавцу.
  4. Продавец вводит в систему код выдачи, который ему сообщает покупатель, и маркетплейс понимает, что пора перевести деньги покупателя продавцу.

Рассмотрим весь эпизод и набросаем вопросы, которые определят направление для дальнейших размышлений. В списке вопросов сразу отметим тегами категории из журнала:

  • Каким будет канал доставки кодов выдачи? Будут ли дублирующие каналы? #задача
  • Как быть с частичной выдачей при отправке кода? Если выдавать покупателю все товары и заказы под одним кодом, ускорится выдача и очередь будет меньше. Зато частичная выдача затруднится или будет невозможна. Если же выдавать товары или заказы по одному, то с частичной выдачей все будет в порядке, а вот покупателю придется оперировать сразу несколькими разными кодами — к тому же это замедлит работу продавца. #противоречие
  • Заказ оплачен и уже приехал в пункт выдачи, а покупателя нет неделю или больше — кто и как вернет ему деньги? #проблема
  • Что будет, если покупатель потерял код, но уже находится в пункте выдачи? Есть ли альтернативные способы получить заказ? #проблема

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

  • Каналы отправки кодов: СМС (ссылка на макет) и ЛК покупателя, страница заказов. #договоренность
    • Добавить в кабинет покупателя код выдачи. #задача
  • Если покупатель потерял код или код не подходит, продавец снова отправляет код на телефон, указанный в заказе. Система позволяет выпустить три СМС-кода подряд, а после этого блокирует выдачу товаров из заказа на полчаса. На каждый код дается три попытки ввода — если код три раза введен неправильно, система предлагает отправить новый код. #договоренность

Когда на все вопросы найдутся ответы, сценарии обогатятся и трансформируются в подробную проектную документацию.

Литература