UXPUB 🇺🇦 Дизайн-спільнота

Cover image for Роль рефлексии в процессе проектирования
Редакція
Редакція

Опубліковано

Роль рефлексии в процессе проектирования

#ux

Последний шаг, о котором часто забывают.

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

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

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

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

Электросчетчики и петли обратной связи

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

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

— Системное мышление, Донелла Медоуз.

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

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

Волшебный дашборд

Если бы я мог взмахнуть волшебной палочкой, то каждое утро я бы начинал с просмотра дашборда с показателями продукта. Это может быть эквивалент Mixpanel или Segment. Я бы сразу увидел, как пользователи приняли новую фичу, и как она повлияла на показатели, которые мы для нее установили. Я бы знал, как моя работа влияет на стратегию компании, например, как функция X, улучшающая удержание на Y% и открывающая Z возможности получения дохода.

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

Предвидьте необходимость корректив

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

Мы можем представить разработку продукта, как грузовой поезд, движущийся вперед предсказуемым темпом. Дизайны – это топливо, поддерживающие огонь инженерной мысли, способствующий росту продукта. Разработчикам необходимо, чтобы дизайны были вовремя готовы, когда работа над последней фичей будет завершена. Это нужно, чтобы избежать простоев. График процесса дизайнера часто ограничивается оценками разработчиков. Чем больше разработчиков поддерживает дизайнер, тем меньше у него времени на сам процесс.

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

Мне казалось будто в прошлом я был в этом грузовом поезде. Всегда смотрю вперед, никогда не оглядываюсь назад. Не задаю сложных вопросов, например, были ли наши действия эффективными? Повторим ли мы те же ошибки? Теперь, когда вы упомянули об этом, допустили ли мы какие-либо ошибки? Узнаем ли мы о них, если клиент не скажет нам?

Фидбек с задержкой

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

Это не так. Дизайн передается разработчикам, и, в зависимости от сложности фичи, разработка кода займет недели, а иногда и месяцы. Запуск в производство может занять еще неделю. К тому времени, когда клиенты увидят фичу, этот дизайнер уже будет работать над следующей функцией в дорожной карте своей команды – и может быть глубоко вовлечен в процесс ее проектирования. Это резкое переключение контекста позволяет сменить текущий процесс и вернуться к предыдущему, поскольку обратная связь начинает поступать.

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

— Системное мышление, Донелла Медоуз

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

Конец начинается с начала

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

Изобразите структуру процесса, например, в виде двойного ромба (double diamond). Если визуализировать процесс, он выглядит как два ромба, расположенные рядом. Они представляют собой четыре фазы процесса проектирования, которые колеблются между конвергенцией и расхождением. А теперь подумайте о пятом шаге, прикрепленном к концу. Это может быть рефлексия. Такой процесс мог бы выглядеть как два ромба, стоящих рядом, а затем длинная линия, соединяет ромбы с маленьким кругом. Линия представляет собой временную задержку между процессом проектирования и обратной связью, а кружок –напоминанием о том, что нужно забронировать тайм-аут, чтобы обдумать полученные метрики.

«Сейчас все мои проекты начинаются с резюме: Каковы мои цели? Чего мы ожидаем? И заканчиваются обзором: Каков был результат? Была ли моя гипотеза верной?»

— Ведение записей и отчетность, Хелен Тран.

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


Перевод статьи uxdesign.cc

Найстарші коментарі (0)