– Окей. Сразу же вдогонку вопрос, в каком формате ты работаешь? Дома, в офисе, в продуктовой команде, в агентстве, на фрилансе, аутстафф и так далее. 

Я бы сказал, что это в первую очередь фриланс, просто достаточно специфичный. 100% удаленка прямо сейчас. На самом деле уже давно 100% удаленка. Я могу сказать, что примерно 80% удаленка меня преследует более или менее с начала карьеры. То есть это было еще задолго до ковида. Когда я в 2010-2011 году пришел в профессию, практически сразу, буквально первые пару лет джуном,  были с посещением офиса, а дальше большая часть работы, большая часть времени была удаленно, просто потому что очно надо проводить исследования, а все остальное можно делать дистанционно. После ковида возникла традиция, что исследования все стали проводить дистанционно. Так что сейчас совсем не видно причин почему нужно делать это очно. 

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

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

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

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

– Соглашусь, да, это намного эффективнее работает. Такой вопрос. Как ты пришел в профессию? С чего все начиналось? Откуда? 

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

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

– Программировал? 

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

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

– Согласен. 

А дальше случайно повезло на конференции познакомиться с парнем из UsabilityLab. Слово за слово. Параллельно с этим почитал Нормана.. Я не помню, мы раньше познакомились с ним, или я раньше начал читать Нормана, потому что под руку попался Норман. Причем вот самый попсовый Норман.

–  Дизайн привычных вещей?

Да-да.

–  “Design  of everyday things”. 

Да, оно самое. И это примерно параллельные события. Когда я открыл книжку, и такой: “Ого, а оказывается, есть сфера, которая мне подходит”. И параллельно с этим познакомился с человеком, который в этой сфере работал. Я узнал, что, оказывается, она еще и в России существует – совсем счастье. Ну, а дальше пошел на стажировку в UsabilityLab, и понеслось. 

– А там как-то специально обучали? Там был какой-то курс обучающий или это все прямо на практике пришло?

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

– Ага. То есть это была стажировка, где тебя обучали, и ты уже работал в проектах в реальных каких-то, да? 

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

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

– А, кстати, забыл спросить, а сколько по времени это заняло, вот этот период обучения?

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

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

Ну, плюс-минус. 

– Что было самое ценное в обучении на UX-исследователя? 

Я не знаю. Мне здесь очень сложно сказать. Отчасти потому, что обучение было не вполне формализованное. Отчасти потому, что мой бэкграунд не очень репрезентативный. 

То есть мы понимаем, что учить меня в тот момент, когда я пришел с IT-шным бэкграундом, академической исследовательской подготовкой и так далее, и учить человека, который пришел из какой-то далекой от IT профессии, –  разные вещи и были бы ценны разные аспекты. 

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

Наверное, основное, что было непонятно именно мне, просто в силу того, что теоретическая база общеисследовательская у меня уже была неплохая. Основные вопросы, которые нужно было освоить, это практика. Как нам с людьми разговаривать, а как мониторить состояние респондента, а как правильно модерировать исследования. И это все. 

Я помню, что в самом начале работы, ну, наверное,  более-менее, у всех был вот этот эффект. “Ко мне сейчас придет живой человек какой-то незнакомый, и мне надо будет ему вопросы задавать, и он что-то говорить будет. Вот как это вообще?” То есть, самые базовые вещи по установлению контакта. Особенно у меня  первый проект был из банковской сферы. То есть, это надо разговаривать с незнакомыми людьми про деньги. Неловко вроде бы.

–  Ну да, да. 

И все такие вещи, причем начиная от вот таких самых каких-то базовых вне профессии, просто по коммуникации и заканчивая более тонкими, типа того, как модерировать дискуссию, как модерировать тестирование, как давать подсказки, как не давать подсказки. Это все вещи, которые, если прочитать статью, кажутся элементарными. “10 правил”, “20 правил”, “сколько-то”. Это будет очень короткая статья с очень очевидными вещами. Но это вопрос именно практического навыка. На практике это делать сложно, потому что психологически такая вот непривычная задача. Я не привык часто  обращать столько внимания, сколько нужно,  на реакцию собеседника. Прогнозировать, как будет интерпретирован мой ответ или мой вопрос, как он повлияет на контекст деятельности, в котором находится респондент.

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

–  Классика. 

Я бы сказал так. 

– Были какие-то сложности, трудности на старте карьеры, и как ты их преодолевал? Вот именно в начале. 

Хороший вопрос. Я бы сказал, что больше всего трудностей…У меня получился достаточно простой вход в карьеру. В смысле, я довольно легко попал на стажировку,  у меня уже был бэкграунд лучше, чем у среднестатического стажера. В целом, все было не очень сложно.

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

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

– А какой у тебя стаж профессии, если примерно прикинуть, сколько лет? 

Чуть-чуть больше 10-12, наверное. 

– Можешь как-то кратко перечислить, в каких проектах тебе удалось поучаствовать? Ну, понятно, что когда ты работал в UsabilityLab, там были разные проекты.

 Да, кратко очень сложно, потому что я первые 5 или 6 лет, сейчас уже не помню, в общем, очень долго я работал именно в UsabilityLab, потому что консалтинг  это интересно, и UsabilityLab –  это прекрасная команда, просто интересно работать. Там мы успели поработать с кем угодно. Ты сам отлично понимаешь, как это работает  в агентстве. Когда я за первый год работы просто поймал себя на том, что:  банки из топ-три банка, я с ними работал; ретейлы, из топ-три ретейлы, я с ними работал и так далее. То есть просто оказывается, что с большим количеством самых разных продуктов ты уже сталкивался. Это тоже одна из прелестей работы в консалтинге, потому что появляется насмотренность на самые разные бизнесы. 

Из каких-то самых интересных или самых больших, ну, во-первых, много работал с крупными банками, во-вторых, был очень интересный проект с Яндекс.Маркетом в свое время. А в-третьих, долго работал с Госуслугами. Ну, вот это, наверное, такие самые интересные, самые знаковые для меня. 

– Классно. А что ты считаешь своими достижениями?

Тут, опять же, очень по-разному, потому что мы говорим больше, чем про 10 лет. Если говорить про первые годы, про UsabilityLab, был проект, в котором была буквально большая исследовательская работа, когда нужно было конструировать с коллегами новый исследовательский фреймвок, такой на стыке joint and study, которыми в России, по-моему, почти не занимались работая с аналитикой. Это все делалось на базе предварительных качественников. Ну, и вот это была просто такая интересная, открытая методологическая задача, когда мы понимаем, что надо придумать метод под задачу, которая существующими методами, в принципе, не решается. И это была такая… ну, очень интересный челлендж и очень такая академическая радость, когда ты конструируешь что-то методологически новое.

Из последних проектов… Я, наверное, скажу, что в последние годы мне уже меньше интересна чисто методологическая составляющая, такая карьерная составляющая, а больше интересны социальные эффекты тех продуктов, которые получаются. Ну, вот внутри Госуслуг было некоторое количество проектов, которые мне кажутся важными. Из того, что на слуху и довольно недавнее, например, года… по-моему, нет, не два года назад, год-полтора назад, кажется, прошлым летом запускались, была на госуслугах программа по бесплатным айтишным курсам, такой маркетплейс, он назывался, по-моему, “Цифровые профессии”. Это был маркетплейс  в отдельном дизайне, с отдельными паттернами, потому что фактически это маркетплейс по типу Coursera,  но на портале госуслуг. Ну, то есть таких сценариев взаимодействия на портале просто не бывает, потому что нет таких задач, не было до этого.

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

– Сразу:  ты говоришь, “как проектировщику”, то есть ты не только исследованиями, но и проектированием тоже занимаешься или занимался? 

Да, ну, это очень… я не знаю, не надо к этому переходить, я могу долго на эту тему говорить. Мне вообще кажется, что внутри профессии у нас, особенно сейчас, деление зачастую слишком мелкое. Причем особенно в крупных компаниях или в агентствах с каждым годом деление становится все более мелким. И… 

– Ты имеешь в виду специализацию специалистов, да? 

Да-да. И вот специализация специалистов в какой-то момент становится гиперспециализированной. И да, у нас сейчас бывает ситуация, когда, не знаю, есть исследователь, дизайнер, проектировщик, возможно, UI-дизайнер и UX-дизайнер как два разных человека, UX-редактор как еще один человек, и  так далее. Мне… ну, понятно, почему так происходит, но мне это кажется не очень эффективным и, наверное, не очень интересным, но в первую очередь, не очень эффективным.

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

Поэтому, да, я в своей карьере работал и как исследователь, и как проектировщик, местами как веб-аналитик, местами как бизнес-аналитик, местами как продакт менеджер. 

– Интересно. 

Я начинал как чистый исследователь, но в какой-то момент, я думаю, что и ты тоже с этим сталкивался, наверное, в какой-то момент понимаешь, что 90% запросов, с которыми ты сталкиваешься как исследователь, ты уже в состоянии с ними работать. И можно прокачиваться дальше как исследователь, в смысле, безусловно, если мы откроем научные статьи по Human-Computer Interaction, этим можно заниматься до бесконечности. Но расти как исследователь, на мой взгляд, можно только туда, если ты готов связать свою жизнь с академией. А в каких-то более практических областях, в какой-то момент сталкиваешься с тем, что написать хорошую рекомендацию важнее, ну, и вот донести решение, донести правильно сформулированный вывод до команды намного важнее для бизнеса и для конечного результата, чем  освоить еще несколько методов, которые тебе никогда не понадобятся, или погрузиться более глубоко в какую-то методологическую специфику. 

– Окей. У меня есть еще вопрос про процесс чуть позже. Сейчас мы говорили про удачные решения, говорили про какие-то достижения. Следующий вопрос Vice versa, наоборот, то есть про какие-то неудачи или, может быть, какие-то то, что считаешь, не знаю, провалы или что-то не так пошло. И с чем они, может быть, были связаны, как c этим приходилось иметь дело. Если такое было, конечно.

Такое безусловно было. Если говорить про консалтинг, чаще всего такое было на несовпадении ожиданий с заказчиком. И это самая классическая проблема, почему все время надо много обращать внимания на то, что на самом деле хочет заказчик. 

Были случаи, когда заказчик: “Хочу, чтобы вы провели конкретные исследования”. Ты ему проводишь конкретные исследования, он смотрит на результат, говорит: “Ну, слушайте, это бесполезно, это какая-то фигня”.

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

И да, были эпизоды вот такого толка, в которых просто приходилось так или иначе переделывать проект на ходу, переделывать проект под конец. 

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

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

Это, с одной стороны, вроде не провал субъективный, ну, в смысле, вроде сделали, что смогли. А  с другой стороны, постфактум просто оглядываешься и такой, я только что потратил год работы плотной, чтобы что? Вот такие истории. 

– А над чем ты сейчас работаешь? В каких проектах, может быть, если ты можешь что-то рассказать, над чем ты сейчас работаешь? 

Я сейчас в двух словах могу рассказать как раз про основной проект, о котором я немножко рассказывал. Это тоже около госсервисов. Это инфраструктура и мобильное приложение про ЖКХ, про управление домами, ориентированное, в первую очередь, на жильцов. 

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

–  Классно. Это основной твой проект  или ты еще чем-то занимаешься? 

Это основной. Просто большая часть других проектов, которые сейчас есть или были за последнее время, это разные исследовательские проекты. Где-то провести юзабилити-тест, где-то спроектировать систему мониторинга. Умеренно интересные вещи с одной стороны и такие интересные составляющие, про которые не нарушая nda не расскажешь, – с другой.

– Понял. Как у вас построен процесс проектирования интерфейса  в этой, я так понимаю, продуктовой команде? Какие там этапы? Что вы делаете? Как вы работаете?

Я  бы сказал, что достаточно близко к классическому Lean… Ладно, я, наверное, чуть попозже тут скажу. В общем, как везде, где я работал и с кем, где я работал в последнее время, обычно все-таки у всех сейчас оперативная разработка, у всех сейчас оперативное проектирование. И да, это  стандартный Lean-цикл, когда мы смотрим на продукт, формулируем гипотезы про то, что можно изменить и как, формулируем минимальные доработки, которые дадут измеримый результат, внедряем, измеряем, повторяем еще раз. То есть это просто итеративный цикл из проектирования, проверки гипотез и по кругу. 

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

Параллельно с этим есть какие-нибудь технические ограничения, которые невозможно на старте предусмотреть, и наоборот, какие-то технические решения, которые настолько долгие в разработке, что их невозможно делать итеративно. Условно: нужно полгода готовить инфраструктуру, прежде чем мы сможем выкатить фичу N. И это тоже приходится учитывать. Поэтому, да, мы стремимся к тому, чтобы дорабатывать максимально короткими итерациями, в зависимости от, по сути, размера фичи. 

В Lean  был термин minimal marketable feature, да? И хитрость заключается, конечно, в том, что слово minimal здесь, в зависимости от того, про какой конкретно сценарий, какой конкретно области и так далее мы говорим. Может сводиться к тому, что мы чуть-чуть переработали интерфейс или к тому, что мы сделали прототип, который протестировали, и вот у тебя понятные изменения, в которых ты уверен. 

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

– А какие специалисты задействованы в процессе проектирования цифровых продуктов, которые вы делаете? 

Я вряд ли здесь скажу что-то новое, потому что довольно классическая продуктовая команда. Да, продукт-менеджер, бизнес-аналитик, системный аналитик, дизайнер, он же проектировщик. 

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

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

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

– Можно сказать, что роль UX-исследователя, она такая эпизодическая конкретно в вашем проекте, да? То есть он все время не нужен постоянно. 

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

– В разных компаниях крупных, типа Mail.ru, например, Касперский тоже. Есть свои лаборатории исследовательские, в которых много продуктов, и они, соответственно, сидят все время загруженные работой. То есть у них довольно много чем заняться. 

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

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

– Скажи, пожалуйста, вот как ты для новичков, опять же, для тех,  кто не очень пока еще в теме, понимаешь разницу между понятиями UX-исследователь, UX-дизайнер, UX-аналитик, какой-нибудь UX-архитектор? Кто чем должен заниматься или занимается, на твой взгляд? 

Мне, кажется, я в самом начале ответил, что я, тем не менее, не вижу большого смысла рассуждать про технологическую базу, абстрактно. Да, но есть некие совсем абстрактные, понятные архетипы, что у нас UX-исследователь занимается в основном исследованием. То есть его основные компетенции – это разный спектр исследований, это и методология, и организация, и что угодно. А есть дизайнер и он большую часть рабочего времени занят проектированием/корректированием дизайна. 

Есть какие-то задачи, где это важно. То есть в случае, если нужно провести методологически неочевидные исследования, это то, чем занимается UX-исследователь. Если этот другой существует в номенклатуре компании. Если нужно что-то нетривиальное на стыке UX-UI, Pixel Perfect макеты, это, наверное, то, чем дизайнер, даже UX-дизайнер обычно занимается, а исследователь обычно не занимается. 

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

– А вот тебе какие смежные функции приходилось выполнять? Я так понимаю, что ты исследованиями занимался, проектированием, а еще что-то, бизнес анализ? 

А я, по-моему, немножко рассказал, что проектирование, исследование, бизнес анализ, немножко системный анализ, как это ни смешно, веб-аналитика, безусловно, продукт-менеджмент местами. 

– Понял. 

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

– Давай. 

Она десятилетней давности, это еще в консалтинге, когда ко мне приходили коллеги со словами, что вот есть проект в такой довольно запущенной стадии, и в нем на стороне заказчика есть разработчики, злые, которые рубят все наши решения, просто имей в виду, когда придешь работать. А дальше я… это было проектирование, грубо говоря, CRM. Дальше я прихожу к заказчику, мы общаемся, в том числе общаемся с лидом этой разработки, и лид разработки рассказывает, что: “Смотри, для того, чтобы сделать CRM-ку, как вы ее спроектировали…”, ну, а потому что мы изучили потребности пользователя этой CRМ и проектировали под нее. “Вы их хорошо спроектировали, но у нас нормализованная база данных, в которой хранятся вот эти данные, но она не сегментированная ни по регионам, никак, то есть в ней хранятся данные, условно, по всем клиентам всей страны. Это миллионы человек. И для того, чтобы вытащить те данные, которые вы нарисовали на экране, нам надо взять 20 таблиц из этой вот SQL-базы и их сджойнить по всей стране. И вот этот джойн нам надо сделать просто, чтобы вывести на экран ту картинку, которую вы хотите.”

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

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

– Можно сказать, что, в принципе, можно порекомендовать человеку, который хочет стать UX-исследователем: Во-первых, ему придется так или иначе как минимум иметь какие-то базовые навыки прототипирования, изготовления макетов. Это раз. Это уже, как говорится, проистекает:  что-то ты поисследовал, что-то ты хочешь порекомендовать, умея это как-то изобразить. Это раз. А второе смежная область – это реализация твоих идей, насколько это реализуемо, насколько это технически выполнимо. И здесь уже тебе понадобятся знания бизнес-анализа, возможно, даже какие-то зачатки программирования, хотя бы базовый уровень понимания, что можно реализовать… 

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

Да, да. Но при чем ты сейчас сказал про ту часть работы, которая касается взаимодействия с технической командой, то есть реализации, а еще есть взаимодействие с бизнес-командой, то есть со стейкхолдерами. И там тоже есть набор компетенций смежных, которые хорошо иметь. То есть в тот момент, когда ты проектируешь интерфейс, я не знаю, выдачу кредита в банке, ну, хорошо, если ты себе нормативно-правовые акты какие-то основные представляешь, которые это регламентируют. С одной стороны. С другой стороны, какую бы фичу ты не проектировал, если это что-то достаточно крупное в продукте, заказчик этого для чего-то хочет. Обычно у заказчика за этим стоит какая-то экономика. Зачастую, опять же, это мы видим в очень большом количестве продуктов, не знаю, в банковских, это особенно очевидно часто. Зачастую твое желание как хорошего UX-дизайнера или UX-исследователя сделать так, чтобы пользователь было на 100% хорошо, впрямую противоречит задачам бизнеса. 

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

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

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

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

– Спасибо. Я думаю, мы здесь сейчас немножко прервемся. 

Во второй части поговорим про методы UX-исследований, которыми пользуются Юрий в своей практике. Поговорим про различные трудности, с которыми приходится сталкиваться, про инструменты, которыми пользуется, опять же, сервисы, программы, приложения и так далее. Вот Юра поделится. 

Поговорим про стажеров и джунов. Опять же, я буду задавать вопросы, какие-то советы попрошу дать и по портфолио, и по стажировке и так далее. Про путь развития джуна. Мы уже немножко начали об этом говорить и продолжим. 

Немножко про рынок и другие вопросы. Сейчас даже углубляться не будем. 

В общем, есть о чем поговорить. Приходите на вторую часть, смотрите. Мы сейчас прерываемся, и во второй части снова с вами увидимся. С нами был Юрий Волков, UX-архитектор, UX-исследователь. Ну, и еще много чего, как мы это уже услышали. 

Увидимся во второй части. 

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

– Я считаю это большим преимуществом, потому что если человек этого не делает, то он становится таким винтиком, который, во-первых, легко заменить, а во-вторых, каких винтиков много, а вот тех самых универсальных ключей, таких, знаешь, которые можно вот это расширить, там, сузить, и это подойдет к любому механизму, вот таких людей мало. И это как раз те самые знания, навыки, которые у меня по жизни сформировались, потому что я заканчивал факультет ВМК по специальности “математик-программист”. Я учился на дизайне. У меня мама архитектор и прошел школу дизайна. Это дизайн. Мне самому стало интересно. Я пошел и обучился на психолога, потому что это психологическое образование. Ну, и дальше жизнь заставила изучать те сферы, в которых приходилось работать.

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

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