Design X

Published in

DesignSpot

14 min read2 days ago

… или нет предела совершенству дизайн-процесса

Человек-дизайнер всегда стремился к систематизации и созданию четкого пути развития в профессии. Отсюда выросло так много курсов, программ обучения и матриц компетенции. В каждой уважающей себя компании должна быть такая модель, иначе очень сложно синхронизировать ожидания и эффективно развивать новые кадры. Успех сложно переоценить: люди, жаждущие войти в профессию, несут свои кровные денежки и меняют их на четкий план, куда расти. Более зрелые дизайнеры имеют адекватное представление о своем уровне и могут получать внятную обратную связь, вместо “Ну что-то не так, еще годик подрасти бы…”. Для лидов стало легче отслеживать прогрессы и аргументировать промоушены перед начальством. Все довольны.

Но если такая модель существует для самих дизайнеров, почему ее нет для продуктов? Ну, почему нет? У нас в компании уже довольно давно существует такое направление, как EngX (Engineering Excellence). Это специальное подразделение, которое при помощи специального фреймворка проводит аудиты так называемых Product Delivery Pipelines, то есть процесса разработки. В продуктовую команду внедряется ревизор, который в течение недели общается со всеми в команде, смотрит показатели продуктивности, как устроены процессы разработки и тестирования, насколько всё покрыто тестами, как разработчики взаимодействуют друг с другом, нет ли поножовщины на митах и т.д. По мере своего пребывания в команде, наш ревизор помечает карандашиком оценочки в журнальчике, а потом генерирует отчётик, который является конечным продуктом сервиса. Он показывает, на каком уровне зрелости находится процесс разработки, где в нем есть белые пятна, и сколько они обходятся продукту каждый месяц, сколько стоит эти пятна закрыть и каков будет конечный ROI. В конечном итоге и продукт и команда выигрывают, если даже не от конкретных действий, то от осознания своих слабых сторон.

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

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

Long story short: такой фреймворк мы разработали, и если у вас чешутся руки его протестировать, то листайте в самый конец, где рассказано о том, как он проходит и как его пройти. Если ещё короче — то пишите мне здесь или в телеграмм и мы договоримся, как нам провернуть это тёмное дельце. А если кто-то захочет посмаковать и узнать, что там за фреймворк такой и как он создавался — читайте дальше.

С чем имеем дело?

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

Таким образом, мы взяли три наиболее популярные модели (Double Diamond, Lean UX и Стендфордскую модель) и попробовали их наложить друг на друга, а заодно рядом примостырить фазы фактического деливери. Получилась вот такая схема:

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

Разработка фреймворка

Откровенно, идея разработки модели зрелости для продуктов пришла не только в наши головы. К этому снаряду уже были сделаны подходы со стороны Nielsen/Norman Group, McKinsey, Design Management Institute и даже Invision.

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

Так мы пришли к выводу, что «своровать, как художники» у нас не выйдет — нечего, и придётся пилить своего Буратино. В следствии коллективных усилий мозгового напряжения и анализа эмпирических данных, на свет появились 13 категорий, измерений, если угодно, которые мы будем рассматривать:

Business stakeholders relations. Всё, что касается взаимоотношений с бизнес-стейкхолдерами, их поддержка, возможность коммуникации, доверие и т.д. Этот разрез служит лакмусовой бумажкой качества собираемых требований, доверия клиента и выравнивания ожиданий, что непосредственно влияет на финальный результат, ведь никому не хочется во время презентации услышать фразу «Это не то, что мы хотели!».
Product strategy. Разрез вобрал в себя всё, что касается формулирования долгосрочного видения продукта, чёткой стратегии его реализации, а также понимания насколько команда разделяет заданный курс. Понимание цели помогает грамотному планированию и увеличению эффективности дизайн-процесса, а отсутствие ориентира обрекает продукт на реактивный дизайн. Просто плыть по течению.
Opportunities creation. Под своей крышей собрал такие понятия, как автономия команды, определение бизнес-ценности и позиционирования, уровень легаси, а также текучка кадров. Все эти, на первый взгляд разрозненные показатели, помогают определить как быстро продукт может производить инновации, доставляя дополнительную ценность пользователям и бизнесу.
Decision making. Определяет на основе чего принимаются решения, как они фиксируются и насколько часто меняются. Отказ от невыгодных стратегий — проявление силы, но если принятые в реализацию решения постоянно меняют, это негативно сказывается как на раздувающемся скоупе (невозможность планирования), так и на эффектности (не эффективности) дизайн процесса, так как работа будет идти в стол.
Data relations. Всё, что касается работы с количественными данными: источники, влияние, роль дата-аналитика и т.д. Разрез даёт понимание того, насколько мы можем полагаться на количественные данные во время дизайн-процесса, а значит экономить ресурсы на подтверждении гипотез.
User relations. Категория, определяющая, насколько хорошо команда знает своих пользователей, и как они работают с продуктом. Без понимания пользователей дизайн-процесс становится бессмысленным, и скорее начинает походить на рулетку, где мы ставим деньги и пытаемся угадать, понравится это пользователям или нет.
Planning, prioritization. Здесь у нас лежат долгосрочное и краткосрочное планирование, видимость дизайн-скоупа для стейкхолдеров, приоритезация и всё, что с ними связано. Этот срез даёт понимание, насколько продукт жизнеспособен в долгосрочной перспективе и как эффективно дизайн-команда может распределять свои усилия, чтобы в минимальное время наносить максимальную пользу.
Design process. Запахло рекурсией, но под этим названием имеются ввиду применимость передовых методологии дизайн-процесса, а также процесс работы с инновациями. Хаотичный дизайн процесс тоже может работать, но это не значит, что он работает на 100%. Данная плоскость даёт понимание нераскрытого потенциала, который можно использовать на благо продукта.
Design delivery optimization. Здесь оказались довольно низкоуровневые вещи, вроде документации, версионирования, использование реальных данных и прочие, казалось бы, мелочи. Но вы не представляете, насколько большое влияние они способны оказать на стабильность работы, задержки и переделки.
Design system. Название говорящее — всё, что связано с построением глобальной и локальной дизайн-систем и работы над ними. Всё довольно очевидно, ведь атомарный дизайн (в том и ином виде) стал уже необходимым стандартом, чтобы обеспечить консистентность опыта и ускорить проектирование.
Design evaluation. Здесь оказалось всё, что связано с проверкой дизайн-решений и оценки их эффективности. Сюда попадают модерируемые или немодерируемые тесты, работа с KPI продукта и т.д. Всё, что может минимизировать риски сделать что-то не так и потратить бюджет впустую.
Design team. Всё, что относится к построению работы внутри дизайнерской команды: церемонии, процессы и коммуникация. Все эти составляющие не менее важны, чем всё, описанное выше, так как климат в команде невероятно сильно влияет на её эффективность.
Cross functional collaboration. Похоже на предыдущий пункт, но уже в отношении команд других дисциплин: BA, разработчики, тестировщики и т.д. Всё по тем же самым причинам: дабы оценить, возникает ли между командами синергия и насколько они эффективны.

Как можно заметить, мы не делали упор на каких-то конкретных исследовательских активностях, взаимодействии с пользователями или фазах проекта, так как главным фокусом у нас была эффективность работы, а не её характер. Само собой внутри каждой из категорий лежат более детальные критерии, но здесь я их описывать не буду.

Оценки

Первая версия нашего фреймворка включала в себя 13 категорий, по 6–7 критериев в каждой. Оценки при этом были универсальны для любого из них. От «ничего нет», до «превышает любые ожидания». Желание упрощения и унификации (читай «лень») сыграло с нами злую шутку, но о ней позже. По изначальной задумке, мы хотели, чтобы любой дизайнер, лид или менеджер, который заполнил наш оценочный лист, получал чёткое числовое значение рейтинга, насколько его проект пионерский или прососный, и где лежат основные области улучшения. Таким образом, мы бы ворвались с двух ног в дизайн процесс продукта и сразу нанесли непоправимую пользу. Вооружённые юношеским максимализмом и собранным на скорую руку шаблоном в Coda, мы перешли к тестам.

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

Недостаток деталей даёт слишком большой простор в интерпретации критериев и оценок (непонятно, какая оценка для каждого критерия, что значит),
Рейтинговая система работает для создания общего впечатления, но не для объективной оценки рисков и возможностей (У нас 50 баллов из 100, мы где-то посередине, но что с того? Зачем нам 100?),
Слишком субъективная модель оценки даёт разгуляться внутреннему отличнику, готовому глотки рвать за «отлично». Страх, что оценка окажется ниже внутренних ожиданий заставлял людей неверно интерпретировать вопросы и игнорировать «горькую правду».

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

Анализ рисков

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

Так что вместо того, чтобы пытаться сразу выразить всё в деньгах, мы решили ввести прослойку рисков, которые могут возникать в следствии (дерьмого) не самого лучшего процесса. На основе эмпирических данных задали базовую вероятность их возникновения и построили зависимости с критериями. Таким образом, у нас получилась связка «Плохие оценки → Увеличение рисков → Увеличение вероятности потерять деньги».

Например, отсутствие сформулированного видения продукта влечёт за собой следующие риски:

Упущенный Product-Market fit,
Увеличение Time to market,
Переделки,
Дефицит бюджета.

Свести это в деньги можно используя количество FTE (цена рабочего места) задействованного в итерации продуктовой разработки (nFTE) и продолжительности этой самой итерации (tITR).

Увеличение Time to market: фактическое количество итераций, необходимое для закрытия потребности × Продолжительности итерации (k×tITR).
Переделки: фактическое количество итераций, необходимое для закрытия потребности-1 × количество людей замешанных в авантюре ((k-1)×nFTE×FTE).
Упущенный Product-Market fit: время разработки × FTE, ведь мы сделали то, что никому не нужно (k×tITR×FTE×nFTE).
Дефицит бюджета, как итог всего вышеперечисленного, может привести к смерти продукта.

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

Я потерял вас ещё два абзаца назад, когда начал бить в лицо какими-то непонятными формулами? Давайте по-босяцки. Если конкретный шаг вашего дизайн-процесса находится не на высоте, то это может привести к негативным последствиям… А может и не привести. Всё это вероятности. Но у каждого негативного события совершенно точно есть цена. Например, поменялись требования → вы не можете отдать дизайн команде → команда курит и ждёт, а денежка капает. И в зависимости от того, сколько людей курят и ждут, и как долго они курят и ждут, суммы меняются. Так вот мы посмотрели на зависимость шагов дизайн процесса со всем непотребством, которое может возникнуть и прикинули вероятности больших и маленьких «потопов».

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

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

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

Все риски так или иначе сводятся к ним, чтобы потом не нужно было самим сортировать весь негатив по кучкам.

Уровни зрелости

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

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

Reactive design

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

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

Collaborative Design

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

Продукт функционирует через коллаборативные обсуждения, приоритизацию и предопределенные процессы. Но реальные потребности пользователей и бизнеса скрыты.

Empowered Design

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

Продукт понимает ценность дизайна и рассматривает дизайнеров как защитников пользователей. Область продукта реагирует на потребности пользователей через проверку гипотез.

Holistic Design

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

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

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

Как происходит ревью?

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

Два. Мы рассылаем приглашения всем «подозреваемым», с которыми мы бы хотели пообщаться, чтобы прояснить все неясности и показания.

Три. Переходим к Measurements и заполняем всю инфу, что знаем о проекте. Эти данные очень нужны для корректного прогноза сумм потерь, которые мы высчитаем по ходу.

Четыре. Переходим к Assessment и начинаем по очереди проходится по всему процессу от критерия к критерию. И так, итеративно заполняем все пробелы. По времени каждое интервью занимает ~40 минут. И нет, я не офигел :)

Пять. Когда все готово переходим к подготовке Summary, где даём прогнозы по потерям, а также общий скоринг со списком рекомендаций.

Рекомендации и скоры по одному из критериев

Шесть. Если станет интересно узнать, на каком уровне зрелости находится процесс организации сейчас, мы делаем сравнительный анализ Maturity level.

Семь. Обсуждаем результаты с командой и проведим брейн-сторм приоритезацию идей по улучшению. Остаётся только следовать плану. Следующий осмотр через 6 месяцев.

Помним заслать часть сэкономленных денег на благотворительность автора статьи (Шутка).

Заключение

Какой профит мы получили из этого гигантского упражнения в своей организации? Помимо данных, собранных во время пилота, наш фреймворк как раз сейчас превращается во отдельный сервис и интегрируется в EngX, о котором я писал в самом начале. Таким образом он сможет использоваться как самобытное предложение или как модуль одного громадного всестороннего аудита. Короче, сейчас как наэкономим денег всем-всем, что на целое «Спасибо» хватит.

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

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

Счастья-здоровья и корабль любви всем вам. 🛳❤️