Дизайн без процесса, или ловушка форм-фактора

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

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

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

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

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

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

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

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

Дорога в ловушку форм-фактора вымощена оптимизациями

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

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

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

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

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

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

В каждой сфере есть инструменты для решения возникающих проблем. Также и дизайнеры разработали всевозможные инструменты, чтобы выйти из этого тупика и достигать результатов. Lorem ipsum позволяет генерировать контент для макетов. Дизайн-системы предоставляют набор виджетов, которые можно расположить в дашборде. Теперь у нас даже есть искусственный интеллект, обученный на образцах шаблонов и способный генерировать дашборд, соответствующий тому, как его базово представляют заинтересованные стороны. Он даже может перевести его в HTML, чтобы результат был действительно «идеальным до пикселя».

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

Наличие визуальных артефактов не означает конец проектирования

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

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

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

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

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

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

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

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

Эмпатия к пользователям, эмпатия к коллегам

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

Такая точка зрения ошибочна и непродуктивна. Дизайну никогда не удастся стать владельцем «правильной вещи для клиента», потому что все думают, что они делают правильные вещи для клиента. Дизайнеры не рождаются более благородными или проницательными. Желание, которое лежит в основе Agile — создавать программное обеспечение быстрее, чтобы мы могли убедиться в ценности того, что мы создаём, — уже было принято программистами задолго до того, как «дизайн» в программном обеспечении проявлялся преимущественно во фразе «детальное проектирование до начала разработки»*.

*Примечание переводчика. Суть подхода Big Design (детальное проектирование до начала разработки, англ. Big Design Up Front, BUFD) заключается в том, что у нас есть тщательно отобранный набор идеальных требований, и при помощи нескольких достаточно формализованных практик мы создаем красивую архитектуру для воплощения этих требований.

Разработчики никогда не переставали стремиться к этому. Немногие из наших коллег получают больше удовлетворение от закрытия тикетов, чем от того, что их работа ощутимо улучшает чью-то жизнь. Но по мере развития дизайн-методов дизайнеры всё чаще оказывались в цикле разработки. Благодаря методам низкой детализации, которые позволяли тестировать идеи гораздо быстрее, чем цикл «build – measure – learn» (обучение через эксперименты), дизайнеры стали первыми, кто указывал на то, что та или иная продуктовая идея не принесёт ценности конечному пользователю, а также первыми, кого обвиняли в «неправильной разработке концепции», когда это происходило.

Твёрдая позиция «только я знаю, что нужно пользователю» сработала для Стива Джобса, и больше ни для кого другого. Но поскольку наши коллеги хотят поступать правильно, мы можем пойти другим путём. Через механизм дизайн-процесса  команды могут увидеть, когда их идеи концептуально неполные, и коллективно проследить логику, связывающую то, что они хотят построить, с ценностью, которую они хотят предоставить.

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

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

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

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

Не придумывайте решения — сначала проведите мозговой штурм на тему основных выгод для пользователя

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

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

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

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

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

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

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

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

Напротив, если попросить команду UI-дизайнеров «проявить гибкость» и разработать идею, это создаст ложное впечатление о завершённости. Наличие визуального образа скрывает тот факт, что чего-то другого (ценности) на самом деле нет. Завершённый артефакт вводит в заблуждение; прерванный дизайн-процесс выявляет пробел.

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

1. Некоторые люди путают «UX vs UI». Не совсем правильно рассматривать UI как документацию UX-решений. Артефакты, которые документируют работу UX-дизайнера — пути пользователей, блок-схемы, карты персон. Они не имеют ничего общего с интерфейсами.
   

Перевод статьи Design without process, or the form factor trap из блога uxdesign.cc

В нашем Телеграм-канале UX Teddy публикуем так же переводы практических статей из блога UX Movement про проектирование сложных интерфейсов, форм и страниц — подписывайтесь!