UX-стратегия на практике: доклад Юрия Ветрова на UXPeople
Доклад Юрия Ветрова с конференции UXPeople.Всем привет, меня зовут Юрий Ветров (@jvetrov), из компании Mail.ru. Сегодня я расскажу о UX-стратегии. UX-стратегия — это некая необходимость, которая назрела давно в дизайне. Ранее дизайн был чем-то вроде средства для решения базовых задач, однако сегодня он становится более важным для продуктов, намного более критичным, проникая на уровень «продуктового управления». Я расскажу, что это такое в моем видении, как это происходит в Mail.ru, и постараюсь объяснить, куда мы вообще движемся, и в Mail.ru, и, как мне кажется, в профессии.
Презентация доклада: www.slideshare.net/jvetrau/ux-people2013-yvetrovuxstrategyПолное видео: uxpeople.ru/video
В идеальном мире дизайном продуктов занимаются на самом старте, сразу все делается в соответствии с идеальными процессами. Однако в жизни все несколько не так — на старте продукта гораздо важнее доказать, что он собственно существует именно как продукт. Важнее растить аудиторию, применять концепцию, чтобы найти свою нишу, свой подход. Бывает, кстати, что и вообще нет денег — у стартапа есть какой-то минимальный бюджет, который тратится на самое-самое критичное. Потому на дизайн бывает совсем не остается времени. Если взять для примера известные бренды, то Windows первой версии в 1985 году выглядела примерно вот так, была не понята ни пользователями, ни рынком и в результате продалась менее 500 тысячами копий. Сейчас же у них 90% рынка и космические тиражи.
Или если мы возьмем Android — когда они стартовали, в 2007 году, все над ними насмехались. В 2009 году у них было менее 2%, и опять же все над ними насмехались. Сейчас все знают, где они находятся. Почему так происходит? Потому что на старте компании рост прибыли и рост аудитории гораздо важнее качества продукта, гораздо важнее того, как именно он сделан в плане качества технической реализации и качества дизайна. Приходится сначала доказывать, что продукт в принципе имеет право на существование на рынке. Затем приходит понимание, что и дизайн важен. Причины для этого могут быть разными. Например, конкуренты усилились, у которых с дизайном все хорошо, или существует негативное общественное мнение о продукте, или от пользователя идет плохой фидбэк, или отток пользователей начинается, или просто становится модно заниматься дизайном. И в этот момент компания переходит от агрессивного накопления пользовательской базы к ее удержанию.
В опыте компании Mail.ru — у нее примерно 40 продуктов, многие из них обладают планшетными и мобильными версиями, в общей сложности получается проектов 200. В нашем подразделении их около 20. По всем продуктам ежемесячная аудитория составляет свыше 100 млн. пользователей. Все это в итоге накладывает свои ограничения — опасно менять что-то слишком резко и нужно десять раз подумать до того, как ты что-нибудь сделаешь.
Я разделяю три уровня зрелости UX, исходя из нашего опыта и опыта многих других компаний. Первый уровень — оперативный, дизайн-команда в этом случае решает задачи по созданию артефактов. Для примера — дизайнерам говорят создать макет, они его рисуют, отдают и на этом их работа заканчивается. Второй уровень — тактический, на котором дизайнеры уже являются частью продуктовой команды, тесно взаимодействуя с разработчиками, тестировщиками, менеджерами и другими специалистами. Третий уровень — стратегический, он уже подразумевает влияние самих дизайнеров на конечный продукт.
Дизайн стратегия позволяет решить проблемы бизнеса и добиться отсутствия скачкообразного уровня качества, когда один проект делается хорошо, следующий — плохо и т.п. Для всего этого важно знать, какова в компании зрелость UX и какова зрелость самой компании.
Зрелость компании понимать очень важно, потому что это та среда, в которой вы будете работать. Компанию можно охарактеризовать тремя основными составляющими: ресурсы, процессы и приоритеты. Ресурсы в самом базовом понимании — деньги (бюджет, который можно потратить на какие-то базовые задачи, хотя бы на поддержание работоспособности проекта и какое-то накопление аудитории), люди (специалисты, которые будут заниматься дизайном, здесь важна их квалификация и доступность), время и кредит доверия. Последний показатель демонстрирует, насколько руководство доверяет дизайн-команде и прислушивается к ее идеям.
Вторая важная составляющая — процессы. Первый процесс — инициация продуктов, откуда вообще берется потребность в их создании. Вторая часть — разработка, здесь важно понимать, как организована работа в компании и в какой среде вы будете работать. Также важно понимать, какие артефакты дизайнеры будут передавать разработчикам. Третий этап — обеспечение качества. Тут важно понимать, имеет ли команда влияние на этот процесс, чтобы, к примеру, задержать релиз, если обнаружены серьезные проблемы в дизайне и в UX. Четвертый процесс — маркетинг. Обычно он бывает в двух пониманиях, это отдел, который рисует баннеры, листовки и т.п., то есть, занимается обслуживанием, и второе — когда маркетинг является частью продуктовой команды, когда он глубоко проникает в продукт — для примера можно взять компанию Apple, где все это тесно интегрировано. Здесь также важно понимать, насколько обещания, которые даются в маркетинге, соответствуют реальности продукта. Пятый этап — поддержка, то есть, на каких этапах и в каком виде компания помогает пользователю продукта. Важно чтобы дизайнер участвовал на всех этапах работы.
Также важно понимать и принципы работы компании — каковы полномочия участников процесса работы, и какова их ответственность. Важно как согласовываются задачи, как оценивается и мониторится эффективность работы, плюс важна оргструктура — как именно компания делится на продукты, отделы. Еще один важный момент — большинство организаций на старте представляют собой маленькие команды, где все участвуют в целом в рабочем процессе. А вот по мере роста компании уже начинается специализация. Потому важно понимать, на каком этапе компания находится в настоящее время и куда она идет.Наконец, в каждой компании есть политика — она подразумевает то, как вы общаетесь с другими подразделениями и учитываете их интересы. Если вы помогаете каким-то сотрудникам делать их работу хорошо, то и они помогут вам в будущем.
Присутствуют также четыре уровня понимания дизайнером своей роли. Первый — простое решение задач разработки, когда дизайнер просто рисует какие-либо артефакты и отдает их вышестоящему руководству. Второй — когда дизайнер начинает решать задачи пользователей, думая о них, понимая, что нужно потребителю. Третье — когда дизайнер начинает решать задачи бизнеса, понимая потребности компании, чего она хочет достичь и как можно решить стоящие перед ней проблемы. Четвертый этап, самый интересный — когда дизайнер может спросить компанию:
«а вам точно нужно решать именно эту проблему? Может быть, нужно решать другую?»
. Чем выше вы поднимаетесь по этим уровням, тем более вы востребованы на рынке и более ценны в этой компании.Также важно понимать, что в компании могут быть неэффективными какие-то общие процессы, помимо дизайна. И даже если вы построите идеальную цепочку макетов у себя внутри, то отдавая их наружу, вы можете столкнуться с плохими разработчиками, или маркетологами, или кем-то еще. Тогда в вашем маленьком мирке все будет хорошо, но дальше все будет неправильно, что отразится в конечном итоге на качестве самого продукта. В этом случае дизайнеру придется вмешиваться и в другие процессы, добиваясь от других сотрудников идеального исполнения их обязанностей. То есть придется изменить не только свой процесс дизайнерской работы, но и всю компанию.
К примеру, в компании Mail.ru никогда не выкладываем вещи, про которые можно сказать «нарисовали и все испортили». Мы выкладываем исключительно то, на что уже есть рабочие ссылки. Если мы смогли добиться чего-то хорошего — значит, есть чем похвалиться. Если не смогли — значит надо работать лучше.
Третья, очень важная составляющая компании — это приоритеты. Это то, куда компания идет, как она выбирает эти направления и почему они именно такие. Просто потому, что если вы не решаете проблемы бизнеса, то со временем вы становитесь не нужны и от вас отказываются.
Есть несколько ключевых контекстов, которые влияют на выбор паритетов. Первое — поиск рынка, продукта для него и бизнес-модели. В этот момент компания постоянно меняется, экспериментирует, ищет тот подход, который позволяет ей накапливать пользовательскую базу и прибыль. В это время бывает тяжело думать о дедлайнах, потому что может случиться, что ваша гипотеза продуктовая не сработала, придется через неделю выкинуть все наработки и идти совершенно в другую сторону. Условно говоря, задачи по созданию чего-либо вам не нужны на данном этапе, а нужно активное участи в исследованиях, в изучении аудитории, в отслеживании эффективности текущих решений, и оперативное создание версий продукта.
Следующий контекст — рост прибыли и пользовательской базы, когда ниша уже нащупана и продукт начинает обрастать некоторыми фичами, а также получает какие-либо новые способы распространения. Третий этап — когда с ростом все хорошо и возрастает потребность удерживать пользователей, когда усилились конкуренты, и от них нужно как-то отстраиваться. Требуется повышать общее количество продуктов, качество сервисов, визуальные качества дизайна. Четвертый контекст — эффективность работы над портфелем продуктов. Это когда у вашей компании уже много сервисов, есть много различных подразделений, и они должны работать как-то координированно друг с другом, и продукты должны быть связаны, и вам нужно работать над тем, чтобы все это в единой связке было хорошо. Наконец, плохой контекст — когда продукт находится в кризисе, и вам требуется его спасать. Опять-таки, в такой ситуации нужно забыть про какие-то идеальные процессы и прочее, занимаясь, во-первых, поиском источника проблемы, а во-вторых — решения, которое позволит оттуда выйти. Еще один критический момент, то, на чем прокалываются многие организации — у вас должен быть некий «защитник наверху», то есть топ-менеджер, который понимает, что то, что вы делаете, помогает продукту и бизнесу, и он за вас горой стоит и вас тянет вперед. Потому что очень часто встречаются ситуации в стиле «увидели, что дизайн это модно, давайте играться, поигрались, получили не то, чего ожидали — давайте расстанемся». И очень многие достаточно большие компании на этом прокалываются. Важно, чтобы «человек наверху» понимал, что ваш труд важен, а если он этого не понимает — важно всеми силами донести до него глубину важности.Все, что сказано выше — это чеклист компании, ее «портрет», который важно понимать, прежде чем вы начнете что-то делать по дизайну. Помимо этого чеклиста есть еще и другие модели зрелости компаний, которые также будет полезно изучить. Одна из самых известных — модель жизненного цикла Ichak Adizes. Она достаточно наглядно показывает, как компания «живет» и позволяет установить, в какой именно точки ее жизненного цикла вы находитесь сейчас.
Второй ключевой момент — понимание того, насколько зрелая у вас компания, и какой путь вы должны пройти, чтобы влиять на продукт и чтобы ваши результаты не терялись «внутри» компании, и чтобы ваше развитие шло исключительно вверх. Первый этап — это хаос, когда дизайн в компании делается бессистемно, а целью является решение задач дизайна, пусть даже и формально — хоть каким-то способом. Итоговое качество — по принципу «как повезет». Разработчики на этом этапе справляются сами, возможно появляются и первые дизайнеры, которые будут между собой не связаны, также, возможно, будут подключаться аутсортеры. Это такой этап, на котором некоторые компании топчутся долго, некоторые — бесконечно, а какие-то его и вовсе перепрыгивают.
Следующий этап — оперативный. В компании появляется некий человек, лидер, который начинает тянуть ее вперед. Для перехода к этому этапу руководство должно осознать свои проблемы. Это то, о чем говорилось вначале — негативный фидбэк или отток пользователей. Здесь явные проблемы в продукте, которые завязаны на дизайне, который постоянно критикуют и говорят, что что-то у вас не так. Внутри компании находится лидер, либо он приходит со стороны. Лидер показывает, в чем именно проблемы компании, и как их можно решить. Один из самых простых способов — провести несколько тестирований, с целью собрать реальный фидбэк, доказывающий, что у компании существуют проблемы.
Следующий этап — появление команды и рабочего процесса. Команда может быть собрана самостоятельно, либо куплена, либо организована каким-либо другим способом. На Западе сейчас модно покупать целые стартапы, в результате чего его команда либо становится отдельным подразделением внутри компании, либо «раскидывается» по другим подразделениям. В России тоже такие методы применяются и получают они все большее распространение. Важно чтобы ставилась процедура постановки и приемки задач. Многие это недооценивают, в нашем опыте я понял, что это была ключевая проблема, чтобы все начало двигаться. Когда я пришел, я думал «вот сейчас за месяц процесс построим», потому что у меня был хороший опыт построения процесса и сбора команды до этого, и компания в меня верила, и вроде все хорошо, и компания согласна это делать. Когда начали делать, мы увидели, что уровень застопорился и не можем задачу подвести. Потому что вроде бы все хорошо, задачи ставятся, мы их выполняем. Однако в любой из поставленных задач есть несколько решений, ведь вы можете решать ее, исходя из различных вводных данных и различных паритетов. Одно решение лучше подходит для привлечения аудитории, другое — для консистентности всего проектного портфолио, третье лучше привлечет рекламу, и т.п. и чем больше людей к этому подключаются, тем больше таких контекстов дается. Вы в итоге смотрите на пул решений и понимаете, что выбрать что-то одно вообще невозможно.
Пока мы не смогли этот процесс задач зафиксировать, чтобы они могли у нас решаться, было очень сложно. Как только мы это сделали — сразу же весь процесс пошел. Поэтому я всегда стараюсь на этом акцентировать внимание.Есть три основных уровня планирования: краткосрочное (когда вы, к примеру, на неделю планируете), среднесрочное (планирование на месяц или на квартал), и долгосрочное (планирование на год или на два вперед). На первом этапе важно научиться планировать хотя бы на среднесрочную и краткосрочную перспективу. Важно также, чтобы появились какие-то четкие, типовые процессы выполнения задач. К примеру, как вы решаете задачу по выполнению концепта продукта, как вы занимаетесь тестированием, как у вас налажены ревью интерфейсные, и т.п. то есть, важно, чтобы под любую типовую задачу у вас был понятный, отлаженный и четкий процесс.
Также очень важно выбрать инструментарий для вашей работы и по созданию артефактов, макетов и т.д., и по ведению документации, и по обмену знаниями. Важно чтобы этот инструментарий у вас сработался. Можно подключать на этом этапе аутсорсеров, но важно чтобы они решали не продуктовые задачи, а какую-то часть задач — к примеру, вы приносите им готовую концепцию и они уже работают в соответствии с ней. Важно не отдавать продуктовую часть наружу, потому что это сильно затягивает сроки, и при этом у вас все равно нет на данном этапе понимания, каким должен быть продукт, что затрудняет вашу работу.
У меня уже были возможности посмотреть на процесс и со стороны подрядчика, и со стороны заказчика. Я понял, что тут заложен извечный конфликт: задача подрядчика выполнить проект как можно быстрее, с как можно меньшей потерей незапланированных ресурсов, тогда как задача компании — сделать как можно более качественный продукт. Причем на старте компания зачастую не понимает, что именно нужно — у нее имеется некая гипотеза продукта, но нет понимания деталей. Как только гипотеза начинает превращаться во что-то осязаемое, сразу же начинается проблема альтернативных путей. Потому лучше наружу отдавать уже готовое четкое задание.
Также важно, чтобы был налажен процесс обучения и развития конечных специалистов внутри компании. Результат этого этапа — команда, которая отлично работает как производственная линия, выдает превосходные результаты и способна выполнять любые задачи.
Когда эта цель достигнута, можно переходить к следующему уровню — тактическому. На этом уровне вы являетесь уже не просто дизайнерским подразделением, а выступаете органичной частью продуктовой команды. Самое главное — это интеграция, когда вы включены во все процессы разработки, тестирования и т.п., когда вы напрямую общаетесь со всеми. Не через какого-то менеджера, который передает ваши решения, словно буфер, и ставит вам задачи, а уже именно напрямую. Важно при этом пообщаться со всеми менеджерами продуктов. Важно чтобы они понимали, в чем важность хорошего дизайна, почему вы пришли в эту компанию, почему руководство вам доверяет и почему вы делаете именно так. Тогда они будут вас поддерживать и к вам постоянно приходить. Они не будут приходить к вам с неким решением, а будут говорить, «вот у нас есть такая-то проблема, помогите нам ее решить». В этот момент у команды появляются авторитет и доверие, и ей не приходится каждый раз потом и кровью доказывать, что вот это правильно, а вот это — не правильно. Этот авторитет нужно постоянно повышать и поднимать, потому что это в итоге облегчает будущую работу.
Дальше вам уже начинают доверять конечные специалисты, такие как верстальщики, разработчики и тестировщики. Они сами приходят к вам, общаются с вами напрямую в стиле «вот смотри: есть вопрос, помоги мне его решить». Ведь все знают, что просто нарисовать недостаточно, и самое сложное начинается при разработке. Там всегда есть много белых пятен, много нестыковок, «вылезает» множество проблем при «натягивании» на контент, на движки и т.п. если нет человека, который будет помогать это все решать, то разработчики будут делать это сами, и понятно, что получившиеся результаты будут довольно сильно отходить от первоначального видения. В этот момент также важно, чтобы появилось долгосрочное планирование, когда вы смотрите на год вперед. Вы понимаете, чем команда будет заниматься, знаете куда продукты развиваются, а также как вы будете завязаны на это развитие. В этот момент должен появиться и механизм, благодаря которому вы можете быть уверены, что все, что вы нарисовали в итоге появится в проекте именно так, как было задумано.
Далее можно переходить к дизайн-принципам и стандартам. Когда то, что вы делаете можно уже как-то структурировать в плане продуктов и решений, и строить на данной основе уже некое узнаваемое лицо и предсказуемое качество. Чтобы это появилось, у вас должны быть «модельные продукты». Такие продукты, которые вы сделали. Которые вам нравятся и решают поставленные задачи. Критическая вещь — технологизация дизайна. Мобильный framework для мобильного web, который мы сделали, и на котором мы сейчас собираем активно mobile web, и он нам позволил за 2 месяца перерисовать и оперативно запустить более 10 проектов, которые выглядят и работают одинаково. Они быстро разрабатываются и быстро обновляются, потому что там единый движок, и если вы меняете что-то в одном месте, то изменения «раскатываются» на все 13 проектов. Это хорошо вот чем — в случае если вы работаете с макетами или даже гайдлайнами, вы «бегаете» по каждой реализации проекта, и смотрите, правильно ли сверстали макет, правильно ли сверстали гайдлайн, и т.п. в итоге вы либо устанете, либо наймете лишних дизайнеров, которые будут все это контролировать — и в любом случае это будет неэффективно, бесполезно и долго.Что можно сделать в этой ситуации — свести множество проектов в большие, когда вам уже приходится контролировать не сотню мелких проектов, а пять мега-проектов. Благодаря такому решению вы можете быть уверены, что реализация дизайна будет точно такой же, как это запланировано в самом дизайне, и контролировать эту реализацию вам будет намного удобнее.Нужно также обязательно определить общие принципы, нужные для работы — принципы, согласно которым и должен существовать дизайн. Можно использовать яркие и сочные проекты, которые передают «дух» дизайна — 10–15 правил, которые позволят ваши гайдлайны свести воедино, и далее вы можете влиять на то, как создаются проекты и зачем они вообще создаются.
Важной вещью является система обмена знаниями. Когда то, что вы узнаете на одном проекте, переносится на другой, когда вы не повторяете своих ошибок, когда компания все эти знания накапливает и развивает. Вам нужен инструментарий, который позволит переносить знания о работе проектов из одного проекта в другой, благодаря чему складывается общее понимание о том, как работает компания в целом. Мы сейчас занимаемся построением аналогичного инструментария, и это достаточно сложно, потому что важна как сама система сбора и анализа данных, так и то, откуда эти данные берутся. Создается база знаний о том, как пользователи работают с продуктами, о конкурентах, там учитываются идеи и то, откуда они берутся. В этот момент можно говорить о том, что продуктовые идеи уже идут снизу вверх — от дизайнеров к продукт-менеджерам и к руководству. Завершающий этап — это когда дизайн уже становится средством рыночной дифференциации. Когда он уже эффективный инструмент, когда именно за счет дизайна компания может повышать прибыль и свою значимость на рынке. Появляется свой узнаваемый визуальный язык, а дизайн продуктов уже может влиять на отрасль в целом.
Также полезно изучить и другие модели зрелости UX. Их несколько, одна из самых крутых — модель Нильсена, насчитывающая 8 этапов, от неприятия юзабилити до большой дизайн-кампании. Модель Брюса Темкина, насчитывающая пять уровней. Модель датского дизайн-офиса, включающая поднятие по этим этапам. Модель Макадамиана, очень хорошая, где на каждом из этапов подробно расписано, какие востребованы скиллы от дизайн-команды. Есть также и модель адаптивной UX-стратегии от Andrea Vascellari.
К сожалению, универсальной модели нет, и у каждой конкретной компании будет собственная ситуация. Потому что, даже если у компаний цели одинаковые, то структура внутри всегда разная. И наложение будущего на реальность создает разные ситуации, которые для каждой из компаний будут уникальными. Однако вышеописанная модель может стать хорошей отправной точкой.Подводя итог, нужно отметить, что, чем выше вы продвинулись по данным уровням зрелости UX, тем более качественный продукт будет получаться в итоге. Нужно стараться ориентироваться на долгосрочные цели. Причем заниматься исключительно дизайн-процессом не получится, нужно менять и другие производственные цепочки в компании.Отдельно напомню, что связка между дизайнерами и другими сотрудниками должна быть довольно тесной. Не должно быть такого, мол «я менеджер, так что делай, как я говорю». Дизайнеры и другие специалисты должны работать именно как одна команда над решением проблемы.
Далее — сегодня очень ценятся продуктовые дизайнеры, которые разбираются не только в одном дизайне, а и во множестве смежных профессий. Потому всем рекомендуется не ограничиваться одним дизайном, а учиться смежным профессиям.
Весь доклад можно увидеть здесь: uxpeople.ru/video
