О ценности первоисточников
Если вы, как и я, занимаетесь проектированием цифровых продуктов, то наверняка знакомы с концепцией персон, придуманной Аланом Купером. Возможно, вы не знали автора этой концепции и познакомились с понятием персон в тематической статье. Также вероятно, что из той статьи вы узнали об устаревании и ошибочности этого подхода, а вместо него автор предлагает использовать другой подход к проектированию, например, Jobs-To-Be-Done и Job stories. Забавно, что и автор статьи, скорее всего, недостаточно знаком ни с методом персон, ни с новым методом, который он описывает. Он так же, как и вы, мог о них прочитать в профессиональном издании и решил собрать все вместе.
Мне грустно, когда я читаю подобные материалы. Ведь я знаю историю появления концепции персон из первоисточника. Изначально подход к проектированию продуктов, основанный на концепции персон, подразумевал выяснение их целей. Персоны ни в коем случае не подразумевали демографические и прочие атрибуты, которые сводили бы их к понятию аудитории продукта, разбитой на возрастные и прочие сегменты, больше похожие на маркетинговые инструменты. Нет, персоны задумывались как способ определения требуемой функциональности продуктов, основываясь на мотивах людей, которые будут их использовать. Таким образом, отдельные персоны, будучи обобщением мотивов пользователей, позволяют спроектировать продукт не как набор равнозначных функций, а как систему, сфокусированную на целях разных групп людей. Такая сфокусированность дает возможность создать интерфейс, более удобный для каждой из них.
Так почему большинство не понимает персоны так, как они задумывались? В одном из интервью Алан Купер рассказывает, как пришел в ужас, когда увидел книгу от Microsoft с описанием концепции персон. Там все было перевернуто, персоны были описаны с точки зрения атрибутов разных групп пользователей. Так поняли концепцию авторы книги. Поскольку охват читательской аудитории у издательства Microsoft шире, чем у независимого консалтингового агентства Купера, то теперь мы имеем, что имеем.
Большинству людей это не интересно. Они не любят задумываться, ищут простые ответы и даже гордятся этим. Но если вы профессионал, я рекомендую всегда работать с первоисточниками. Так вы избежите ошибок, сможете полноценно воспользоваться опытом других, вместо того чтобы быть дилетантом как большинство в нашей профессии. С одной стороны, это дань уважения к авторам инструментов и методов, которыми мы пользуемся, а с другой – возможность глубже разобраться в сути предложенных ими идей.
Экспедиции в мир других
Возможно вы знаете, что те, кто много путешествует, смотрят на мир по-другому и обращают внимание на вещи, которые никто не замечает. Вспомните, как по-новому вы смотрите вокруг себя даже после недели в другой стране. Если вы долго там прожили, это даст вам совершенно новые ощущения после возвращения. Возможно, вы вернетесь с новыми привычками и захотите придерживаться их в своей обычной среде. Этот же подход можно использовать для развития профессиональной насмотренности.
В работе над проектом я предпочту сотрудничество с дизайнером с опытом в вебе, мобильных приложениях, а лучше, если кроме этого он занимался версткой журналов. У специалистов с узкой специализацией отсутствует «профессиональная мудрость» – им кажется, что их знания единственно верные. Тем, у кого разноплановый опыт, легче посмотреть на задачу с альтернативной точки зрения и, возможно, привнести в проект что-то полезное из другой области.
Для проектировщика такое качество не просто желаемо, а обязательно. Специалистам, которые реализуют продукт по готовым решениям, важнее иметь отточенные навыки владения соответствующим инструментарием: языками, средами разработки и прочим. После проектирования становится ясно, какие требования предъявить к разработчикам, и найти лучших из них с необходимой специализацией. Но пока идет проектирование, должны быть рассмотрены совершенно разные идеи.
Опыт можно заимствовать не только в цифровой среде. Несколько раз я наблюдал, как специалисты, в прошлом работники, например, сферы строительства и даже ракетостроения, синтезировали совершенно необычные для IT-среды решения. У них существует еще одно измерение, которое позволяет развернуть задачу так, как нам не придет в голову.
Чтобы прокачивать насмотренность, необязательно менять работу или прикладную специализацию. Попробуйте периодически отправляться в профессиональные экспедиции, делайте перерывы в обычной деятельности и погружайтесь в работу в новой среде. Если вы дизайнер и всегда работали с вебом, договоритесь с командой, которая занимается интерфейсами мобильных приложений, и включитесь в их проект на пару недель. Уверен, вас ждет масса сюрпризов. Это касается не только знаний в области проектирования продуктов, но и управления проектами, и работы с клиентами.
Такие экспедиции в другие профессиональные области, как и путешествия по разным странам, дадут то, что невозможно прочитать в книгах и статьях. Самое важное спрятано между строк, и это можно увидеть только вживую. Поэтому посмотрите в свой календарь, договоритесь с коллегами, которые занимаются интересной для вас темой, и удачи!
Аналитика ≠ проектирование
В моей практике был случай, когда для работы над проектной документацией я привлек только аналитика. Это было рациональное решение, ведь все так делают, не правда ли? Предполагалось, что он соберет требования к продукту и оформит задание для разработчиков в виде спецификации. Все шло замечательно, пока я, как куратор проекта, не оказался на защите первой версии проектной документации.
Я ожидал увидеть размеченную на разделы функциональную схему продукта, общую техническую архитектуру, детализацию структур данных, которая складывалась из функциональных требований, и сценарии взаимодействия с продуктом, связанные с набросками пользовательского интерфейса. Как вы наверно догадались, ничего этого не было.
Можно было подумать, что у аналитика низкая квалификация, но, по опыту предыдущих проектов, с профессиональным уровнем все было в порядке. Из рук этого специалиста всегда выходили качественные материалы. Проблема была в другом. Аналитик, оставшись один на один с требованиями к продукту, изложил свое видение будущей реализации проекта, основанное на собственном понимании задачи. Там не было ни продуманных идей по технической архитектуре, ни сбалансированных пользовательских сценариев, ни эргономически выверенных набросков интерфейса. С таким же успехом я мог поручить задачу любому человеку, разница была бы только в оформлении документов. Это был провал.
Раньше аналитик работал над проектами в паре с проектировщиком, но здесь он был предоставлен сам себе. Этот своеобразный эксперимент показал истинную ценность компетенции проектирования. Я убрал из команды специалиста с необходимым опытом и знаниями в моделировании продукта, и увидел только каркас документации без содержания.
Этот пример показал, что нельзя механически переложить требования к продукту в модель его реализации. Это творческий процесс. В простых проектах можно действовать по шаблону, но даже тогда нужно интерпретировать требования в соответствующие интерфейсные и архитектурные паттерны. В случае же сложных проектов их успешность напрямую зависит от навыков и таланта проектировщика.
Опытный проектировщик отличается достаточным запасом возможных решений. Он по опыту знает, насколько они подходят для текущей задачи. Без практического опыта проектирование неизбежно превратится в череду проверок разных идей, что равносильно написанию кода с дальнейшим тестированием. В таком случае даже ценность комплексного взгляда на продукт, которую дает проектировщик, может быть упущена.
Если команда не будет уверена в качестве предложенных проектировщиком решений, ей придется отказаться от них и искать способ реализации продукта самостоятельно. Разработчики будут вынуждены подбирать техническую архитектуру в соответствии с требованиями так, как они их понимают. Дизайнеры тоже будут моделировать интерфейс исходя из своих представлений о пользовательских сценариях. Все это будет сделано на локальном уровне каждого специалиста без учета общих целей проекта, что безусловно скажется на его качестве. Хотя о чем беспокоиться? Большинство проектов в индустрии и так выполняются подобным образом.
Для чего нужны исследования в проектировании
Иногда требуется очень много времени и сил, чтобы найти нужное проектное решение. Например, это может быть способ организации интерфейса для системы с множеством функций или структура базы данных под нестандартные требования. Бывает очень жаль, если удачное решение видишь только в конце проекта, когда уже поздно что-то менять.
Насмотренность проектировщика позволяет видеть решения задач за пределами личного опыта. Поэтому так важно развивать это качество. Но простого знания этих способов для использования в проекте недостаточно. В этих решениях нужно быть уверенным, знать их детально и понимать их сильные и слабые стороны. Каждый проект уникален, и простое копирование решений может не сработать. От проектировщика требуется не только знать технологии, но и понимать стоящие за ней принципы, чтобы оценить, насколько кажущееся удачным решение применимо.
Там, где опыт не дает однозначного ответа, гипотезы нужно проверить. Ведь именно в этом цель проектирования – передать разработчикам описание решения, в котором все гипотезы подтверждены. Устранить ошибку на этапе проектирования значительно дешевле, чем на этапе разработки. Во время проектирования вы работаете с идеями, а на уровне разработки – с готовыми частями системы. Даже в случае выявленной ошибки будет нелегко отказаться от кода, на создание которого могли быть потрачены сотни, а может и тысячи человеко-часов.
Чтобы проектирование не превратилось в бесконечную проверку гипотез, у проектировщика должен быть запас наработок. Часть из них накапливается с профессиональным опытом. Продвинутые проектировщики целенаправленно работают над расширением своего профессионального актива, занимаются самостоятельными исследованиями, ищут решения интересных задач, которые могут им пригодиться в будущих проектах. Таким образом насмотренность конвертируется в интеллектуальный актив, который позволяет проектировщику перейти из ресурсной бизнес-модели работы над проектами к модели знаний.
Извращенная корпоративная модель использования исследований
Перенесемся из мира идеальных проектов в реальность. Каждый раз, когда я сталкиваюсь с классической корпоративной культурой, мои убеждения и здравый смысл проходят серьезную проверку на прочность. Насмотренность и исследования кажутся неуместными на фоне того, что там творится.
Если в описанном подходе исследования нужны для проверки гипотез, рождающихся в процессе поиска концепции продукта и его проектирования, то в корпоративной среде все наоборот. Исследования служат формальным источником требований к будущим продуктам, снимая ответственность с тех, кто их высказывает. Поскольку при достаточном старании с помощью исследования можно обосновать любую идею, это отличный способ скрыть личные интересы за формальными правилами.
Корпоративный мир – закрытая экосистема, количество мест и ресурсов в нем, как правило, ограничено. Если вы придумываете что-то новое, то вступаете в конкурентную борьбу и в результате претендуете на чье-то место или на чьи-то ресурсы. Без понимания этого факта происходящее там действительно может показаться абсурдом. Но абсурдом только с точки зрения того, чья цель – сделать удобный и решающий задачи пользователей продукт. Вы либо играете по этим правилам, либо оказываетесь в ситуации жесткой конфронтации с коллегами.
Сотни миллионов тратятся впустую. В продукте, цель создания которого в большей степени – личные амбиции конкретного сотрудника, например банковского руководителя по развитию, не находится места для интересов конечного пользователя. Подобные продукты строятся вокруг исследований «маркетинговой стратегии», фокус-групп и экономического обоснования. Все это, в случае отсутствия интереса к продукту со стороны пользователей, позволяет сослаться на низкое качество реализации или на ошибки в исследованиях, но не на истинные причины. Профессионалы из отрасли никогда в этом не признаются, но «по гамбургскому счету» польза для людей от подобных продуктов определяется как минимально возможная разница между стоимостью проекта и интересами бизнеса – по остаточному принципу.
Сколько выдающихся продуктов, созданных внутри компаний с жесткой корпоративной культурой вы видели? Скорее всего, немного. Продукты, которые могут прийти вам на ум, скорее всего, были куплены вместе с небольшой командой создателей. Альтернативный сценарий – когда внутри компании есть автономная группа или подразделение, на которое не распространяются общие правила. Деньги не рождают продукты, которыми хочется пользоваться. Они появляются в результате увлеченной работы отдельных людей.
Через несколько дней после того, как я закончил эту главу, в блоге Алана Купера вышла статья «Practitioners in Businessland». Она созвучна моим идеям, и я не могу не процитировать ее фрагмент (а лучше прочитайте ее целиком):
«Basically, everyone in business is looking for a way to do things more quickly, more easily, and with less skilled people. The solution, of course, is to take more time, work harder and use more highly skilled people.
In other words, the best business people are wrong. Sadly, those same business people often make lots of money being wrong.
Don’t conflate making money with making successful products. Your boss will not reward you for taking time and working harder. Do you want a raise and a promotion? A nice house and a new Tesla? Or do you want to create a supportive, healthy, peaceful world in which your children can grow old in happiness? You have to make a choice about how you wish to shape the world you live in. That’s a very tough choice».
Личный опыт показывает, что преодолеть такую ситуацию можно, только если вы, как создатель продукта, работаете с руководителями напрямую, и их статус позволяет им принимать самостоятельные решения. Обычно это собственники или редкие топ-менеджеры, чьи интересы связаны с интересами бизнеса. Они готовы брать на себя ответственность и понимают, что это сопряжено с риском, но только так можно прийти к интересной продуктовой идее. Любая фокус-группа никогда ее не пропустит.
Для чего нужны исследования в вашей профессиональной жизни
Почему же мнению тех, кто профессионально занимается проектированием продуктов, должны доверять больше, чем остальным? Есть ли у них что-то, что придает их точке зрения особый вес, кроме их нескромной уверенности в своей правоте только потому, что они называют себя специалистами?
С этим вопросом часто сталкиваются дизайнеры и проектировщики, чья работа – искать неочевидные решения сложных задач. При этом не существует по-настоящему объективных критериев оценки результатов такой работы, особенно когда решается судьба будущего продукта и проектировщик продумывает его внешний облик и внутреннее устройство. Пользователи еще не попробовали его, а служба технической поддержки не столкнулась с фактическими ограничениями в эксплуатации.
У неопытных специалистов ситуацию усугубляет отсутствие навыка объяснить, как они пришли к своей идее. Путь, который прошел дизайнер или проектировщик, чтобы добраться до итоговой версии решения, неочевиден для остальных. Почему была выбрана такая схема организации функций в пользовательском интерфейсе? Обеспечит ли выбранная архитектура нужный уровень гибкости при работе над следующими версиями продукта? Часто приемлемое проектное решение является компромиссным, но единственно возможным с учетом известных ограничений. Понять это можно, только разобрав всю логическую цепочку.
Люди готовы принять чужую точку зрения, только если за ней стоит что-то поубедительнее, чем просто «мнение». Например, успешный опыт прошлых проектов или ваша позиция в корпоративной иерархии. Хотя, конечно, это плохой пример, но он показывает, почему административный способ принятия решений приводит проекты в тупик. Уровень компетенции участников проекта должен соответствовать его сложности. Это касается и проектировщиков, и заказчиков. Не существует гениальных управленцев, интуитивно принимающих верные решения в вопросах, в которых они не разбираются. Сложные вопросы требуют сложных ответов. Не стоит обманываться кажущейся простотой элегантных решений.
Если все-таки говорить про профессиональную дискуссию, когда вы к ней подходите подготовленным, это играет в вашу пользу. Поставьте себя на место оппонентов. Разве вы для решения ответственного вопроса приняли бы идеи, не подкрепленные доказательствами? Особенно если на кону стоят ваши деньги. По этой причине, если ваши идеи базируются на прочной доказательной базе, их нельзя просто проигнорировать. Кроме того, не в этом ли заключается профессиональная этика – синоним ответственности за свои решения?
Когда опыта недостаточно или вы оказались в новой области знаний, исследовательская работа помогает получить убедительные аргументы. Чем серьезнее вопрос, который перед вами стоит, тем более глубокую работу вам необходимо проделать. Проиллюстрирую этот тезис на следующем примере.