Дизайн цифровых продуктов. Цель, роль, метод29.09.2018 09:49

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

В Альфа-Лаборатории мы строили процессы продуктовой разработки как раз по скраму, где каждая команда является самостоятельной единицей, способной делать поставки так быстро, как смогут (в идеале — недельными или двухнедельными спринтами).

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

В конце 2017 года в Лаборатории было около 30 команд (может больше), и почти для каждой нужен был свой дизайнер. Даже на таком относительно большом масштабе важнее работать на уровне стратегии, верхнеуровневых понятий и подходов, потому то «контролировать» работу 30 дизайнеров, которые работают над разными продуктами и в разных командах и с разной скоростью технически качественно не получится. Тактику определяет каждая команда самостоятельно, в этом вся прелесть.

Такая простая цель. Разберем каждое слово, ведь она не просто так сформулирована именно этими словами.

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

У меня есть грустная статистика. Из десяти дизайнеров, приходящих «делать продукт и влиять на него» на результате фокусируется один, остальные — на процессах. Доходит долго, и хорошо, если доходит вообще.

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

Anyway, вернемся к формулировке.

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

Допустим, продукт не работает. Тут всё понятно: пользоваться им (как минимум по назначению) не будут.

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

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

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

Эту мысль с разных сторон обсуждают и когда говорят про Agile, и про частые поставки, и про Скрам и про работу в командах, но даже при таких практиках дизайнеры почему-то порой скатываются в уютную колею «процессов». Допускаю такие причины:

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

P.S. Ссылки на описания перечисленных методологий, Википедия:

Часто роль дизайнера в продуктовой команде преувеличивают, потому что мыслят категориями процессов и последовательности действий (ватерфолл) вместо результата.

(Правильно мыслить от результата, категориями цели.)

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

«Мы ждём макеты» — если такое звучит, значит процессы в команде организованы неправильно.

(Увы, многие разработчики и дизайнеры не знают о стандартах — хотя бы W3C для веба, а там заложено очень много фундаментальных принципов, которые помогают строить лучший опыт. По аналогии существуют описания/стандарты для ведущих мобильных и настольных платформ; iOS, Material.)

Обратите внимание на стартапы — Facebook, Вконтакте, Одноклассники и те же Apple с Microsoft: в их основе лежат инженерные решения (Возняк, Гейтс), к которым впоследствии присоединились дизайнеры. Они создавали продукты в соотвествии с Целью.

Сначала — работающий продукт.

(Красивый, справледивости ради, сделали идейные ребята в лаборатории Xerox, но масштаб последствий совсем иной.)

•••

В чем же тогда роль дизайнера?

В том, чтобы добавить ценность.

Добавить можно к чему-то существующему, обратите внимание.

Ценность в глазах клиентов, пользователей.

•••

Зачастую последовательность переворачивают с ног на голову и «ждут дизайн». Это, конечно, говорит о незрелости команды и неадекватном менеджменте этой самой команды.

•••

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

Начинайте с кода вместо макетов.

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

Именно поэтому продвинутые дизайнеры мигрируют в прототипы с реальными данными. Хорошо ли это? Считаю, это избыточно — зачем программировать прототип, когда можно (и логично) сразу программировать продукт?

Лучше сразу двигаться от разработки к дизайну. Начинать именно с кода — прототипа, выполняющего задачу клиента в минимальном виде. Прототипа, который может пойти в рабочую поставку (вспомним позже про Customer Development).

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

Takeaway

Осознайте задачу пользователя.

Начните с разработки. Трудитесь в паре с разработчиком (как арт-директор и копирайтер).

Совершенствуйте работающий продукт вместо макетов.

Мыслите категориями цели, результата вместо процессов.

Дизайнер продукта создаёт продукт, а не макеты.

Этот метод вместе с библиотекой компонентов стал базой банковской дизайн-системы.

Предлагаю работать в такой последовательности:

1. Осознать задачу клиента (пользователя) и зафиксировать в виде User Story.
2. Определить метрики. Как мы понимаем, что задача пользователя решена? Зафиксировать.
3. Сформулировать гипотезы. Зафиксировать.
4. Customer Journey Map.
5. Работающий прототип. MVP. Customer Development.
6. Макеты. (При слаженной работе команды и существующей дизайн-системе можно обойтись без макетов).

Задача клиента

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

Задачу клиента выявляют либо на основании жалоб («боль клиента»), либо исследований потребностей.

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

Когда задача осознана, она записывается в виде User Story. Об этом написано много статей и книг, поэтому я здесь повторяться не буду — изучите самостоятельно.

Для погружения в вопрос настоятельно рекомендую книгу User Story Mapping: Discover the Whole Story, Build the Right Product (Jeff Patton and Peter Economy).

Два типа метрик (важно фиксировать оба!)

1. Сформулированный ответ на вопрос «Как мы понимаем, что задача пользователя решена». Что мы хотим получить в виде решения.
2. Цифровые: относительные и абсолютные величины. Чаще про количественные показатели (финансовые, скорость, клиенты, время). Как мы поймем что решение удачное. Тут есть уловка: часто в презентациях за относительными величинами скрывают, преувеличивают или теряют объективный масштаб решения. Например, «прирост аудитории составил 3%» — это много или мало? Если это 150 000 человек (поселок городского типа, со школами и садиками, магазинами и своей администрацией) — то уже внушительное число, хотя кажется что мелочи. С другой стороны, «рост прибыли 300%», если это 300 рублей за месяц — уже сомнительный показатель. И снова, если 150 000 человек — статистическая погрешность в размерах аудитории всего продукта (допустим, посещения главной страницы поисковика в год), то этими размерами скорее всего можно пренебречь, хотя речь про население того самого поселка городского типа.

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

Гипотеза — ответ на вопрос о самом быстром способе решить задачу пользователя

Всегда существует несколько решений задачи. В разработке (дизайне) нельзя ограничиваться одним! Никто не знает наперед, какое сработает лучше всего.

Проведите ментальную работу и придумайте, как минимум, три разных решения.

Имейте в виду, что «развитие» одной идеи в виде прогрессивно меняющегося макета это одно решение, а не три (или сколько у вас получилось сделать разных макетов).

Для простоты попробуйте три подхода:

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

Лучшее решение находится исключительно эмпирическим путём (см. «Научный метод»). Любое даже самое дикое на первый взгляд решение/идею необходимо проверять. Гипотезы надо проверять. Идеальный случай — проверка всех трёх гипотез, выполненных в виде MVP. Для этого вы сделаете прототип.

Customer Journey Map погружает в контекст

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

Если задача — проработка фичи в существующем приложении, то CJM погружает в контекст и обеспечит бесшовное бесшовное решение задачи. Часто, игнорируя контекст, дизайнеры и продуктовые менеджеры делают «новый раздел», размножая сущности, усложняя навигацию и порождая неразбериху в интерфейсе.

Про CJM написано довольно много, вам необходимо это изучить самостоятельно и применить в работе.

Начать можно с книги «Пользовательские истории» Джеффа Паттона.

Работающий прототип. MVP. Customer Development.

Договоритесь с разработчиком и сделайте работающий прототип для проверки каждой гипотезы. Это не обязательно будет идеальное в техническом и эстетическом плане решение — важно сделать минимально жизнеспособный продукт (MVP), в тестирование которого можно вовлечь новых и существующих клиентов (Customer Development).

Подробнее обо всём этом читайте в книге Эрика Риса «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели». Пересказывать книгу нет смысла.

Если вы не знакомы с термином MVP, начните со статьи на Википедии. Однако книга намного полезнее.

Обойдемся без макетов, потому что есть готовый продукт

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

Takeaway

User Story
Как определяем успех
Гипотезы (способы решений)
CJM
Прототип, MVP, Customer Development
Макеты (если потребуются)

Самое большое, на что вы способны

Последнее время всё чаще приходится повторять, что продукт/компания хорош настолько, насколько хорошо может отработать его самая плохая составная часть. На лекциях повторял, и новым сотрудникам говорю.

Придется пояснить.

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

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

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

Аналогия из физического мира: если на гоночном болиде установлены плохие колёса, то круто он не поедет. Поедет ровно настолько, насколько смогут вытянуть те самые колёса. Даже если всё остальное —  супер-крутое: мощный двигатель, сплошной карбон везде и всё такое — на ободах быстро не поедешь. Хотя инженер скорее всего был супер-крутой, раз болид создал. То же самое с банками, приложениями, студиями, издательствами, агентствами и так далее. Чем больше терпимость к посредственности и ошибкам (это называется «компромисс»), тем хуже будет продукт/компания. Продукт/компания настолько хорош, насколько плох самый плохой сотрудник или процесс: в магазине могут быть феноменально крутые/редкие товары, но если продавец хамит, то продажи будут хромать.

Думаю, мысль уже давно понятна.

Оказывается, многим это не понятно.

Зачем писать об этом?

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

Принцип применяется везде, не только к продуктам.

Пополам

Глядя на макет: Как решить задачу половиной элементов интерфейса?

Убрать половину текста? Сформулировать в два раза короче?

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

Провести встречу за 30 минут вместо часа? Вообще отменить её?

Убрать графику? Не делать её вообще, изначально?

Нужны ли иконки?

Что будет, если убрать половину пунктов в навигации?

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

Если появляются дополнительные идеи, можно заносить их в бэклог. Бэклог не может быть обязательным набором — жизнь богаче планов, нужно гибко реагировать на реальность: принимать и анализировать обратную связь, отслеживать продуктовые метрики. Многое из надуманного окажется бесполезным уже на этапе тестирования.

Дели на два.

В более широком смысле рекомендую ознакомиться с принципом «Бритва Оккама», если еще не знаете что это такое.

Научный метод

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

В моей трактовке идея принципа простая: справедлива только разведка боем.

Придумали решение? Выкатывайте на клиентов. Настаиваете на другом фоне? В бой.

Все заявления должны проверяться и подтверждаться экспериментальным путём. В цивилизованной среде они называются гипотезами, в любительских группах —  «мнением» :-)

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

Для проверки есть куча инструментов и методов. Все результаты можно оцифровать: воронки, скорость, суммы субъективных оценок и так далее.

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

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

Исходя из этого принципа я прихожу к таким соображениям:

1. Любой участник команды может выдвигать гипотезу и тестировать её, безотносительно формальной роли: дизайнер, продакт-оунер, разработчик чего угодно (фронта/бэка/мидла и чего еще бывает). Все могут делать свой вклад в достижение результата. Командам следует продумать прозрачный и простой механизм учета и порядка запуска таких идей (если их много).
2. У дизайнера нет индульгенции, права быть правым просто потому, что он — дизайнер. В некоторых командах я наблюдаю этот перекос, причем в обе стороны: разработчики и продакты манипулируют тем, что «ждут, пока дизайнер сделает дизайн» (отказываются думать самостоятельно), в то же время дизайнеры часто пользуются тем, что у них в должности прописано «дизайнер», и для некоторых название должности является аргументом в спорах. Продукт — совокупность усилий всех специалистов.
3. Бывает такое, что самые дикие и нелогичные на первый взгляд решения работают лучше всего. Мы окружаем себя предубеждениями и не можем выбраться из них, посмотреть с другой стороны — это и правда очень сложно. Всегда будет включаться сопротивление изменениям — как внутри команды/организации, так и клиентами. Единственный честный выход — решительно действовать, уметь рисковать, тестировать боем, собирать обратную связь, наблюдать результаты и реагировать на них. По-другому ничего интересного не появляется. Замечено и доказано, что всё необычное позавчера становится нормой сегодня и обыденностью завтра — см. «Окно Эвертона».

Итого

1. Тестировать боем —  выходить хотя бы на часть аудитории и проверять все гипотезы.
2. Всё оцифровывать — результаты должны быть прозрачными.
3. «Дичайшие» гипотезы тоже надо уметь проверять.
4. Всё, что подкрепляется только «экспертным мнением» и «опытом» (в конкретных интерфейсных/продуктовых решениях) смело отправляется на помойку — ориентироваться надо только на наблюдения за поведением реальных пользователей.

И еще бонус

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

Скачать ePub

© Habrahabr.ru