Отсутствие представления о пользователях

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

Скоро мы увидим, как можно достичь понимания пользователей и их поведения в контексте создания продуктов.

Конфликт интересов

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

Отсутствие процесса

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

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

Если речь идет о сложных механических устройствах, мы принимаем как должное, что эти устройства были тщательно продуманы с пози' ций практического применения, а не просто сконструированы с при' менением инженерных методов. Объекты промышленного производ' ства, как правило, достаточно просты, и даже сложные механические продукты оказываются простыми в сравнении с большинством про' грамм и продуктов, содержащих программный код. Цифровые про' дукты могут содержать миллионы строк кода (сравните с подавляюще сложным механическим артефактом – космическим челноком, содер' жащим 250 000 деталей, лишь малый процент которых составляют де' тали подвижные). И при этом большинство программ начинают жизнь, не пройдя скрупулезного проектирования, ставящего пользо' вателя во главу угла.

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

Некоторые организации осознают необходимость процесса проектиро' вания, но принятый ими на вооружение процесс оказывается неспосо' бен решать поставленную задачу. Многие программисты сегодня с го' товностью воспринимают идею, что интеграция представителей заказ' чика в процесс разработки на регулярной основе – еженедельной или даже ежедневной – способна решать проблемы проектирования чело' веческих интерфейсов. Хотя у такого подхода есть благотворный эф' фект – ответственность за проектирование частично возлагается на пользователя, – однако есть и серьезный методологический изъян: владение предметной областью путается со знаниями о проектирова' нии. Заказчики, даже если они способны четко сформулировать про' блемы взаимодействия, нечасто способны представить способы реше' ния этих проблем. Проектирование, как и программирование, – это специальный навык. Программисты никогда не просят у пользовате' лей помощи в написании кода; к проблемам проектирования следует относиться так же. Кроме того, постоянными пользователями про' дукта не всегда являются заказчики, приобретающие его, – это тон' кое, но важное различие.

Эволюция проектирования в промышленности41

Это отнюдь не означает, что проектировщики не должны интересовать' ся мнением других о предложенных решениях. Однако каждый участ' ник команды, работающей над продуктом, должен уважать специали' зацию других участников процесса. Представьте, что больной прихо' дит к врачу с ужасной болью в животе. «Доктор, – говорит он, – очень болит. Подозреваю, это аппендикс. Его нужно срочно удалить!» Разу' меется, ответственный врач не станет делать такую операцию по прось' бе больного. Пациент может описать симптомы, однако для постанов' ки верного диагноза требуются профессиональные знания врача.

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