На практике случается, что вы разработали продукт, а после запуска клиенты используют его не так, как предполагалось. Затем выясняется, что задачи пользователя уже другие, и они идут вразрез с запланированным развитием продукта и вашим видением проекта. Почему?
На самом деле, вы работаете с задачей пользователя, которая не понята до конца и которая меняется под влиянием продукта. Это наталкивает на мысль, что продукт нужно доработать, причем в паре с клиентом. Так вы сразу обезопасите себя от создания ненужных решений, основанных лишь на гипотезах.
Я думаю, что лучше всего выстраивать коммуникацию с пользователем по принципу continuous design, о котором и пойдет речь в статье.
Дорогой и сомнительный IT хаос
Большая часть продуктов и функций, поставляемых IT, не находят применения на практике. Ресурсы, приложения, софт остаются невостребованными. Не все компании задумываются о том, нужны ли их продукты на самом деле.
Ярким доказательством служит рынок мобильной разработки, который имеет измеримые показатели. Хотя здесь сконцентрированы передовые практики, статистика оставляет желать лучшего: в 2017 году аналитическая компания Localytics опубликовала исследование Sql, из которого следует, что 24% приложений пользователи открывают лишь один раз.
Это с учетом того, что процент пользователей, которые открывали приложение менее 10 раз, не превышает 63%. Если брать во внимание «стабильность» статистики, то становится ясно, что выводов из нее не делают. Люди умеют разрабатывать, но они упускают аспект того, как продукт войдет в жизнь человека, то есть не пользуются человекоцентричной моделью. Последняя предполагает долгосрочное взаимодействие с клиентом; обычно в течение нескольких лет.
Это приводит нас к выводу: в к клиентоцентричном подходе нужно обратиться к существующим практикам разработки вроде DevOps, agile или scrum, которые обычно применяются по отдельности. Но если объединить их, мы получим нечто большее под названием continuous design. Он состоит из классических принципов DevOps и дизайн-мышления. Его мы и предлагаем рассмотреть и взять на вооружение, но чтобы внедрить принцип в разработку нужно пересмотреть отношения между двумя составляющими: дизайном и операциями.
Вводные со стороны операций и дизайна
Операции — то, что происходит сейчас. Это могут быть системное администрирование, пользовательская поддержка, бизнес-процессы. Операции строятся по разным моделям, например, с помощью упомянутого DevOps. Она предусматривает постоянный процесс обратной связи, доработок и поставку решений. Создается «петля» из фидбэка, планирования, поиска решений и их презентации. И для каждого из этапов есть инструменты, которые помогают в работе, автоматизируют процессы и обеспечивают постоянный обмен информацией и решениями.
Дизайн — все, что участвует в определении действий, методах построения и способах упаковать продукт для потребителя. Обычно мы подходим к дизайну, как к решению проблемы. Если мы понимаем суть проблемы, то можем предложить верное решение.
Это традиционный подход.
4 обстоятельства, которые не учитывает традиционный подход
Но при объединении дизайна и операций выявляются 4 фактора, на которые ранее не обращали внимание команды, работающие по отдельности. И для этих аспектов continuous design становится решением:
#1. Проблему нельзя понять полностью
С помощью аналитики и исследований мы строим гипотезы о том, как люди будут пользоваться продуктом, но они дают неполное представление о проблеме, так как мы не можем охватить все ее аспекты. Только когда продукт попадает в руки потребителя, мы видим, насколько полезным для потребителя он оказался, какие задачи помог решить или что поменял.
Простой пример: на джинсах есть маленький кармашек для часов. Его изобрела компания Levi Strauss в 1873 году. С тех пор кармашек никто не использовал по назначению. Компания даже выпустила целый ролик, посвященный этому.
#2. Продукт меняет потребителя
Активный опыт взаимодействия с продуктом меняет пользователя. А это трансформирует проблему, которую продукт решает, что создает новые затруднения для вас и клиента.
Вспомните, как мы заказывали такси 5-6 лет назад: оператор на другом конце провода принимал заказ и говорил, что машину подадут через 20-30 минут. И мы были готовы ждать. С запуском сервисов вроде Uber, Gett и Яндекс.Такси наше восприятие поменялось: в 2018 году оптимальное время подачи авто для нас 2-3 минуты. Если мы ждем дольше, это начинает раздражать. И дело не в диджитализации или уберизации, а в изменении нашей модели потребления.
#3. Ценность — нечто, создаваемое совместно
Ценность продукта невозможно представить на момент его создания. После запуска сервис начинает жить своей жизнью и обретать новую ценность, которая формируется при использовании. Часть функций будет востребованной, а другая — нет. Так и созревает ценность, созданная вами и потребителем. Поэтому часто полезность остается неочевидной до тех пор, пока товаром или услугой не воспользуются.
Вспомним AppStore, который появился вопреки представлениям о ценности Apple. В 2007 году Стив Джобс презентовал iPhone со словами: «Вам не нужно писать программы. Это ни к чему: у вас есть html5». Пользователей это не остановило: они взламывали устройства и писали свой софт, распространяемый через программное приложение Cydia. Его запустили в марте 2008 года, а уже 10 июня того же года ребята из Купертино переняли успешный опыт и запустили AppStore, изменив ситуацию в свою пользу и став игроком №1 на мобильном рынке.
Этот тезис приводит нас к выводу, что разработчик и потребитель являются частью проблемы и решения.
#4. Сложность исключает контроль
Мы постоянно создаем сложные системы, которые невозможно полностью проконтролировать. И это ведет к неизбежным отказам и ошибкам в них. Одна из главных проблем в работе с такими системами — попытки контроля на слишком многих уровнях, когда вы тщательно продумываете, что произойдет или может произойти.
Я уверен, что все мы когда-то звонили в клиентскую поддержку, где нас уйму раз перенаправляли на разных операторов. И мы снова и снова описывали проблему и ждали ответа под фоновую музыку компании. Это те случаи, когда сервис — операторы — продуман слишком тщательно. У сотрудников есть алгоритмы общения с клиентам, которые постоянно переписываются и детализируются. Вместо того, что служить на благо пользовательским интересам, они лишь усложняют и запутывают систему. Один оператор из-за политики компании не может решить вашу проблему, даже если она простая. Он просто обязан перенаправить вас на кого-то еще.
Софтверизация в цифровой среде
Посмотрите на эволюцию iPod
Эти неучтенные факторы влияют не только на цифровой, но и на физический мир. Становится труднее получить опыт, который не включает промежуточную программную составляющую. Среда, в которой мы живем, софтверизируется, и это меняет восприятие вещей и то, как мы ими пользуемся.
Например, Tesla выпустили обновление ПО, которое увеличивает время автономной работы автомобиля. При этом совершенствуются его физические характеристики: теперь можно съездить не только до супермаркета или работы, но и до соседнего города. Изменилось не количество поездок и не длина пути, а качества автомобиля, а с ними и понимание задач и целей его использования. Теперь не нужно тратить деньги на такси или ставить другие ограничения, ведь аккумулятор работает в 2 раза дольше. Одна машина закрывает все задачи ее владельца.
Бренд уходит от обещания к диалогу
Если с операциями и дизайном все стало понятнее, то остается более крупное и абстрактное понятие бренда. Он тоже работает в связке continuous design.
Раньше мы воспринимали бренд как обещание. Например, стабильности или неизменности. Но сейчас его основа смещается к диалогу, потому что мы живем в парадигме меняющихся ценностей. И диалог с пользователем не должен быть односторонним, он завязан на постоянном общении.IT именно та среда, где это делается быстрее всего. Ведь у нас есть инструменты для обеспечения постоянной обратной связи на разных уровнях: от внешних аналитических сервисов до методов DevOps.
IТ становится средой непрерывного диалога
Мы начинаем безостановочно менять продукт благодаря обратной связи клиента, за которым наблюдаем и чьи действия анализируем. Так петля DevOps замыкается в бесконечность, когда в этом процессе участвуют операции, разработка, дизайн и маркетинг: мы выбираем одно решение из многих, внедряем его и смотрим, как оно поведет себя на практике. Именно в таком виде и работает continuous design.
Парадигма непрерывного проектирования
И для того, чтобы дизайн становился увлекательным диалогом, есть 4 рекомендации:
#1. Проектируйте взаимодействие клиентов и сотрудников в точках их соприкосновения
Прежде чем выпускать продукт, спроектируйте пользовательский опыт. И изучать его надо не только в идеальных условиях, когда товар или услугу используют правильно, но и там, где клиент соприкасается с бизнес-процессами: бэкофисом или IT-архитектурой. Проектирование опыта с опорой на внешнюю среду и на образ жизни пользователя помогает выявить, как продукт и сотрудники, с которыми он взаимодействует, впишутся в жизнь человека. Это также прояснит, какие будут точки соприкосновения с подразделениями компании и при каких условиях. Для этого можно использовать CJM и jobs-to-be-done клиентов и коллег.
#2. Минимизируйте задержку, максимизируйте обратную связь
Гибкие методологии разработки вроде agile и практики DevOps дают не только скорость и поставку апдейтов или бета-версий. Используя их мы можем быстрее получить обратную связь, проверить гипотезы и скорректировать действия, чтобы улучшать продукт и дальше. Мы учимся на каждом спринте работы или обновлении продукта и выжимаем из нее знания на протяжении всего жизненного цикла сервиса.
#3. Проектируйте для ошибок. Делайте, чтобы учиться
Превратите провалы в информацию, служащую вашим и пользовательским интересам. Ошибки неизбежны на все этапах, будь то проектирование функций или разработка маркетинговой кампании. Но к ним нужно быть готовым и строить continuous design, чтобы уметь вовремя заметить ошибку и сделать выводы. Здесь важно использовать практики Lean UX, такие как UX-тесты, АВ-тесты, гипотезы и так далее.
В конечном итоге формируется культура работы с ошибками и инструменты, которые она создает: как Chaos Monkey или Blameless post mortems.
#4. Понятия «сделано» не существует
Мы находимся в условиях, когда проблему нельзя понять полностью, а решение при этом изменяет ее. Поэтому команда не может просто следовать гипотезам о ценности продукта и дальше проектировать IT-архитектуру и сервис. Вместо этого нужно смотреть, как работают продукты и услуги, когда окажутся за пределами контроля. Обратная связь в петле DevOps бессмысленна, пока операции и окружающий мир не влияют на процесс усовершенствования продукта. И в этом случае исключается понятие «сделано». Вы постоянно меняете продукт. Значит, процесс продолжается и дальше в системе DevOps и дизайн-мышления.
Работа в парадигме continuous design учит быстро реагировать на ошибки, проще относиться к ним и не делать бесполезной работы. Ее преимущество в том, что шаг за шагом закрывается все больше задач клиента, что приносит дополнительную прибыль и благотворно сказывается на бизнесе.
p.s. На написание этого материала меня вдохновило выступление Джеффа Сассна.
Автор: AndrewYaremko
