ПРОЕКТИРОВАНИЕ ДЛЯ СТАРТАПОВ: КАК ДОНЕСТИ СВОЙ МЕССЕДЖ
Как наладить эффективное взаимодействие между разработчиком и клиентом при проектировании. Многие стартап-организации представляют собой исключительный пример хаоса. Пожалуй, больше, чем кто-либо другой, члены стартовой команды должны понимать цели, поставленные перед ними в различных областях: исследованиях, маркетинге, проектировании, разработке, архитектуре и др., — так же хорошо, как и роль каждого из них в развитии компании.
Предприниматели должны выбрать направление, проектировщики — продумать варианты, разработчики — выбрать функциональный продукт или услугу, и все это нужно делать, тесно взаимодействуя друг с другом. Как минимум нужна идея. Большинство начинающих предпринимателей, как правило, ведут себя по-разному. Некоторые начинают свой путь с создания новой бизнес-модели, в то время как другие — с красивого дизайна. Третьи пытаются тестировать первый продукт на функциональном прототипе, даже если это выглядит немного некрасиво.
Все они, независимо от первоначального подхода, со временем адаптируют свой бизнес-процесс для создания сбалансированного продукта или услуги. Поэтому сегодня большинство начинающих компаний называют себя «agile» – «гибкими».
«Гибкие» стартапы, как следует из названия, должны иметь возможность мгновенно изменить свой план, разработки и/или бизнес-цели. Но сегодня это гораздо легче сказать, чем сделать. UX-дизайнеры (UX дизайн - направленный на взаимодействие с пользователем) для «гибких» стартапов, должны четко выполнить две задачи:
Понять сущность разрабатываемого продукта или услуги, и
Максимально эффективно на доступном языке донести его преимущества до непосредственного потребителя.
Это не так просто, как может показаться. В идеале, разработчики начинают работу с тщательного выбора предпринимателей для сотрудничества, но что происходит, когда они вообще чужды сообществу, для которого работают?
Головокружительная скорость развития «гибких» стартапов делает их работу по созданию рекламных обращений, соответствующих целевой аудитории, невероятно трудной.
Только на основе понимания преобладающих процессов и мнений, разработчики могут сделать различия для конечных пользователей своей продукции или услуг.
Проектирование с ориентацией на пользователя
Проектирование с четким пониманием того, кто есть пользователи, никогда не было простой задачей. Большинство проектировщиков, у которых был опыт работы с явлением, известным как «бережливый стартап», согласятся: процесс разработки в стартап-организациях чрезвычайно сложен. А это значит, что большинство стартап-организаций приходят к тому, что возможность продажи товара выходит на первый план, или форма превосходит функциональность.
Но тогда как «гибкие» среды очень хорошо подходят для этого, создание хорошего дизайна занимает определенное время, что практически всегда затрудняет процесс проектирования.
Запомни уровни UX
Одним словом, гибкое, ориентированное на пользователя, проектирование имеет тенденцию игнорировать эстетические, нематериальные, эмбиентные качества, которые, в общем-то, являются положительными. Как следствие, начинающие руководители, профессиональные и интерактивные разработчики начинают беспокоиться. Не имея возможности понять аудиторию, для которой они работают, эти члены команды не могут выполнять свою работу.
Возникает закономерный вопрос, как им работать? Как разработчики могут эффективно общаться с аудиторией, которую они даже не видели?
Книжное определение UX-дизайна дает небольшую подсказку. Ориентированным на пользователя разработчикам рекомендуется сначала провести проектное исследование, создать образец и потом получить конечный продукт. Конечно, это могло бы пролить свет на факторы, влияющие на отношения компании с ее клиентами… не так ли?
Возможно. Хотя исследования, безусловно, необходимые в процессе проектирования, не являются его целью.
Я уже писал раньше, что разработчики должны развивать в организациях собственную UX-культуру. В этой статье я постараюсь развить эту идею: для эффективного общения стартапа с целевой аудиторией, каждое решение компании должен пронизывать дух сопереживания, который проявляется в привлечении клиента к постоянному, ориентированному на его потребности диалогу.
Куда исчезло сопереживание?
Работа любого проектировщика, работающего в стартап-среде, требует эмпатии. Он, возможно, более чем любой другой член команды, должен взаимодействовать с заинтересованными сторонами (чтобы понять бизнес-цели проекта), разработчиками (чтобы понять технические требования проекта) и, конечно, пользователями (чтобы понять природу решаемой проблемы).
Проектирование с учетом мнений всех трех сторон наиболее эффективно. Это важно, однако, большинство начинающих предприятий не испытывают чувства сопереживания. Вспомните, как часто вы слышали что-то подобное: «Мы нацелены на богатых одиноких мужчин, в возрасте от 45 до 55 лет», или «Мы Амазон для бэби-бумеров». Описание продукта, подобное этому, возможно, сначала и поможет понять идею компании, но этого знания будет недостаточно.
Каждая электронная коммерческая компания продает продукт. Новички могут (и часто делают это) научиться всему на примере профессионалов в своей отрасли (действительно, на эту тему написаны целые книги). Но давайте внесем ясность: фраза «Я хочу быть как Amazon» не вдохновит проектировщика. Создание чего-то, что смотрится и ощущается как Amazon, будет, конечно, смотреться и чувствоваться как Amazon. Но если этот веб-сайт будет продан совершенно другой группе людей, то полученный результат будет неискренним — совершенно противоположным эмпатическому.
Для того чтобы создать что-то реальное, уникальное, ценное и выглядящее и воспринимаемое как нечто самостоятельное, члены стартап-команды должны выйти из своих кабинетов.
Один…. Нет… Три процесса
Ко всему этому нужно добавить существующие определенные процессы (подходы), которые всегда направляют стартап-организацию. Недавнее сообщение в блоге Уитни Гесс противопоставляет три определенных типа. Стоит отметить, что все подходы, подробно изложенные ниже, показывают одни и те же глаголы в одной и той же последовательности. Отличают их основные действия, которые приводят к изменениям. Гесс пишет:
Я вижу множество продуктов, разработанных с использованием Активного подхода:
Я почесал зудящее место;
Должен ли я продолжать его чесать?;
Я почешу другое.
Как разработчик, часто работающий с «гибкими» стартапами, я согласен с Уитни: реактивный подход («построй это, и они придут») является, несомненно, наиболее распространенным. Для таких действий, конечно, есть серьезное основание: развитие приводит к изменениям. Стартапы действуют так, чтобы построить первоначальный прототип. Прототипы, в свою очередь, продвигают компанию вперед.
К сожалению, прототипы, разработанные большинством стартапов, демонстрируют полное отсутствие внимания. На кого нацелен прототип? На кого-то от 40 до 50? Определенно на многих из них. А смогут ли люди от 40 до 50 понять его? Так как это все очень субъективно и неясно благоразумные стартапы полагаются на опытных UX-разработчиков, способных помочь им ответить на все вопросы. Неудивительно, что мы с Уитни часто с этим сталкиваемся.
Как опытный разработчик, консультант и участник нью-йоркского технического сообщества, я выступаю за использование Преактивного подхода:
У кого зуд?
Этот зуд не устранили.
Вот так можно устранить зуд.
Я считаю, что большинство UX-разработчиков согласятся (осмелюсь сказать, даже будут сопереживать) предписанному преактивному подходу Уитни. Начинать с размышления – с исследования – это в крови ориентированных на интерес пользователя разработчиков; это помогает им понять своих клиентов и правильно осуществить их пожелания. Более того, «предварительная деятельность» — это единственный реальный способ для них получить эмпатию.
Но большинство стартапов идут вразрез с этим подходом. Действие и последующее размышление обычно оставляют мало места для исследования. Встречалась ли Уитни со стартапами, пытающимися совместить все? По счастливому стечению обстоятельств — да. Недавно она работала с предпринимателем, который пошел по другому пути:
Кэмпбелл Маккеллэр, основатель Loosecubes, является первым человеком, который заставил меня понять, что есть что-то лучшее, чем Преактивный подход, а именно — Превентивный подход
Действуя раньше, вы фактически достигаете большего. Вы создаете будущее вместо того, чтобы просто предсказывать и подстраиваться под него. Вы изобретаете новую реальность, основанную наполовину на том, в чем люди нуждаются, и наполовину на том, что вы им желаете. Наблюдая за реакцией потребителей, можно вовремя изменить стратегию. Этот подход является наиболее поддающимся преобразованиям из всех трех как для субъекта, так и для объекта действий. Как предприниматель в глубине души, я хочу согласиться и здесь. Превентивный процесс кажется жизнеспособной альтернативой напряженности между проектировщиками и разработчиками стартапов. Но только то, что в результате применения превентивного подхода группа работает без сбоев, еще не значит, что дизайнер организации понимает пользователей лучше.
В целом, легко представить себе сценарий стартапа, в котором конкретный процесс развития является более ценным, более производительным, чем его альтернатива. Что должна делать команда - думать, действовать или решать? Это зависит от обстоятельств. Независимо от того, как разработчики присоединяются к новым компаниям, они часто обнаруживают, что их сфера находится там на втором месте, если, конечно, эта организация не следует преактивному подходу. Но для большинства новых компаний это просто не тот случай.
Как правило, для того, чтобы организация, больше узнала о своих пользователях, участники-проектировщики должны настаивать на том, что для этого подойдет изменение пути разработки. Проектировщики должны отстаивать свою часть процесса. Как проектировщик UX Джошуа Портер говорит, «Чем дальше проектировщик от людей, для которых он работает, тем тяжелее ему это делать». Стартапы, а точнее их разработчики, должны максимально приблизиться к своим клиентам. Разработка продукта не должна находиться только в руках одного предпринимателя и/или разработчика.
Почему дизайн был неудачным
Большинство проектировщиков не дают честного ответа на вопрос о том, почему процесс проектирования одинаково важен и для разработчиков, и для предпринимателей. Но только то, что точность и красота хорошего проектирования очевидны для большинства проектировщиков, не означает, что их коллеги разделяют это мнение.
Если это не приносит деньги…
Новые компании — и что еще более важно, их сотрудники — сталкиваются с огромным количеством психологических барьеров, стоящих на пути создания их эмпатии с конечными пользователями. Вышеупомянутые ускорение темпов и изменение запланированных процессов, вот эти препятствия:
У стартап-команд есть твердые убеждения. Любой, кто верит в дело (будь то идея или веб-приложение… или и то, и другое), идентифицирует себя с ним. Если проектировщик подвергает сомнению обоснованность идеи, он опрашивает команду. Это - трудная, но неотъемлемая часть процесса проектирования.
Исследование (немедленно) не продает. Для того чтобы продать кому-либо продукт не требуются недели исследований, и при наличии достаточного количества времени, хороший маркетолог любому может продать все что угодно — особенно что-то красивое. Соответственно, члены команды, скорее всего, будут судить о книге по ее обложке. Исследование редко влияет на их представление о красоте.
Новые компании доверяют тем результатам, которые они могут измерить (предпочтительно в долларах). Веб-аналитика сегодня — это хлеб с маслом для современных опытных интернет-маркетологов. Сказать, что проект просто хороший – это одно. А сказать, что он увеличил конверсии на 200% — другое. Присоединение цифр к чему-то делает предпринимателя (да и разработчика, тоже) более уверенным в решении появившихся проблем. Если текущий процесс поддается измерению, нужно ли допускать замедление первичного процесса проектирования? В целом, краткосрочные суждения (да или нет, идти или не идти, Решай! Действуй!) пронизывают стартап пространство. Реальность такова, что большинство «гибких» стартапов поддерживают процесс «design-less» – «минимизирование дизайна». В то время как UX-разработчики считают, что эмпатия (или понимание) равноценна успеху стартапа, их товарищи по команде могут в это не верить. Для того чтобы добиться изменений, они должны бороться за целостность своей конструкции изнутри.
Иди вперед с сопереживанием
Чтобы внести ясность скажем, что хороший проект в стартап-компаниях не появляется только в результате изучения метрик, сгенерированных прототипом, или общения с пользователями через прокси, например, электронную почту. Нельзя сказать, что эти вещи не важны — они, конечно, могут (и часто делают это) указать на последствия ранее принятых решений. Обратная связь, по определению, не может определить следующий — или, что более важно, первый шаг.
Вот в чем загвоздка. К сожалению, это распространенная проблема, с которой обычно сталкиваются стартап-проектировщики.
Создание эмпатии и приобщенности.
Никто не будет спорить, что определение того, что такое "хорошо" для веб-дизайна субъективно. Как писал Д. Кейт Робинсон в A List Apart еще в 2005 году:
Узнать, что люди хотят в сети, может быть трудно. Вы должны иметь невероятный уровень эмпатии и уметь поставить себя на место потребителя или провести довольно обширные исследования. Эмпатия о которой я говорю, на мой взгляд, действительно может быть создана только спустя длительное время наблюдения за тем, как все типы людей делают всевозможные вещи на всех видах веб-сайтов и приложениях. Даже пока вы двигаетесь от проекта к проекту, люди, их проблемы и потребности меняются. С каждым новым проектом появляется новый целевой пользователь, новый сопереживающий человек. И так же, как при знакомстве с новым человеком, понимание того, что им нравится и не нравится, требует времени. Если проектировщики должны обратиться к новым клиентам, то сначала им нужно узнать их. Тогда, как утверждали Уитни Гесс и Кеннидд Боулз, фокусировка на быстром превентивном процессе — решать, действовать, думать — дает большинству новых компаний хороший план атаки.
Кроме того, что команды проходят первую проверку рыночной жизнеспособности, они могут думать о том, как вскоре после этого они будут дифференцировать свой продукт. Да, этот процесс беспокоит и связывает сознательных бренд проектировщиков, что и понятно. В начале, тем не менее, без контекста, создающего прототип, проектировщики должны склоняться к “относительно безопасной” стороне, где начинается дизайн взаимодействия: кнопки выглядят как кнопки, раскрывающиеся списки выглядят как раскрывающиеся списки, и возможно даже названия новых компаний похожи на новые компании.
Роберт Хоекмен младший называет это "Проектированием очевидного". Я называю это "проектированием сверла", потому что тому, что компенсируется удобством использования, не хватает уместности. Чтобы определить, что является уместным (субъективно), проектировщики должны провести вне кабинетное исследование.
Придерживайтесь своих убеждений
Множество UX-проектировщиков является сторонниками преактивного подхода; это те, кто хочет понять — для получения эмпатии — свою аудиторию и создать что-то адаптированное специально для нее. Кроме того, у них есть относительная роскошь работы в организациях. Для них Кеннидд Боулз и Джеймс Бокс написали прекрасную книгу "Секреты UX дизайнера". Если вы работаете в компании, где дизайн это слабое место, и вы хотите это исправить, предлагаю незамедлительно приобрести эту книгу. Если вы независимый консультант или проектировщик, работающий с новой компанией, то для того, чтобы создать наилучшее впечатление я хотел бы дать несколько советов:
Создайте стратегию проектирования. Сформулируйте, для кого вы будете проектировать (даже если они будут только воображаемыми) и как они будут использовать сайт. Я уже писал раньше, как я это делаю. Независимо от того, как это делаете вы, знайте того, кого пытаетесь узнать.
Найдите решение. Работайте с командой разработчиков, чтобы создать быстрый прототип, демонстрирующий ваше лучшее (хотя и необоснованное) решение. Найдите, по крайней мере, двух человек использующих прототип так, как положено. Подружитесь с ними и посмотрите на их реакцию, когда вы усовершенствуете свою концепцию развития.
Убедитесь в этом сами. И наконец, самое главное, убедитесь в этом сами. Навестите пользователей в их обычной среде и удостоверьтесь, что их проблемы решаются. Если у вас есть возможность, задайте им вопросы, связанные с проблемами вашего стартапа. Во всех случаях стартап-проектировщики должны сосредоточить процесс проектирования на выслушивании пользователей. Разговаривайте с клиентами. Эмпатия, связь между людьми, может дать или наоборот разрушить опыт. Поскольку большинство из нас работает за компьютерами в течение многих часов, дней или недель за один раз, о завоевании эмпатии очевидно, легче говорить, чем делать. Однако она является единственным способом превратить хорошую бизнес-идею в продуманный конструктивный диалог. Уважение заслуживается и рождается бренд тогда, когда организация взаимодействует со своими клиентами открыто, серьезно, честно и правильно.
