Управление продуктами: Увидеть продукт глазами пользователя

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

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

    Суть проблемы


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

    Это чудесные формы по заполнению совершенно непонятной информации, как на рисунке слева.

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

    Мне очень грустно работать с таким ПО. Я понимаю, что его писали первоклассные специалисты, я допускаю, что код этих систем тоже в полном порядке. Однако я не стану ими пользоваться. В крайнем случае, если у меня не будет выбора, я всё-таки буду «плакать, колоться и жрать кактус», но при этом окончательно испорчу карму разработчикам своими мало литературными комментариями.

    Почему?


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

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

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

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

    Пользователи не всегда могут описать, чего конкретно они хотят, иногда они даже сами этого не знают. Они могут чувствовать, что им «не удобно», но очень редко могут объяснить, почему. Более того: они могут превратно истолковать свои неудобства или попытаться самостоятельно придумать «как им было бы удобнее», на деле не понимая того, как им было бы удобно на самом деле.

    Как в своё время сказал Генри Форд: «Если бы я спрашивал людей, чего они хотят, они бы попросили более быструю лошадь».

    Что делать?


    Итак, что же делать, если пользователи сами не знают, чего хотят, а, если и знают, то не могут нормально сформулировать?

    Во-первых, забыть слово «пользователь». На мой взгляд, оно крайне вредно при проектировании продукта. Его имеет смысл использовать только при составлении требований в связке «пользователь должен иметь возможность…». Почему? Всё достаточно просто: «пользователь» безлик. У него нет имени, пола, возраста, причёски, детей, которые сидят у него на коленях во время работы. Он не думает о том, что надо отвезти машину в ремонт или сварить ужин. «Пользователь» никогда не воскликнет «как же мне надоело вносить одну и ту же кнопку десять раз!», он никогда не скажет «чёрт возьми, я опять промахнулся мимо этого элемента на экране смартфона, т.к. автобус тряхнуло!».

    «Пользователь», он же “The user” или даже «Зэюзер» — самое серое, безвольное, бесправное и угнетаемое существо на планете.

    Итак, мы забываем слово «пользователь». Чем его заменить? Для начала, можно воспользоваться замечательным инструментом под названием «персоны». Персонификация позволит безликим «зэюзерам» обрести имя, лицо, профессию и хобби. Так гораздо проще. Но и это ещё не всё.

    Полное перевоплощение


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

    Это требует развитой эмпатии. Это требует долгой и усиленной работы, понимания своего пользователя. Не «зэюзера», а того самого Васи или той самой Ани. Эта работа сродни работе актёра, вживающегося в роль. Но эта работа всегда приносит плоды. Чем глубже вы залезете в шкуру пользователя, тем лучше поймёте, что именно ему надо, почувствуете ту боль, которую будет лечить ваш продукт.

    Кстати говоря, стандарты советуют формировать пользовательские истории, примерно в таком виде: «как <роль> я хотел бы…». Таким образом, они прямо ставят того, кто их пишет (а обычно это Product Owner) на место пользователя.

    Eat your own dog food


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

    «Мы сами едим собачий корм, который производим». Эта фраза впервые появилась в 1970-е годы в рекламе компании Alpo, производящей корм для домашних животных и теперь, с лёгкой руки Microsoft, активно используется при разработке программного обеспечения. Наш продукт настолько хорош, что мы пользуемся им сами.

    Наверное, одним из самых ярких примеров такого подхода является популярная система контроля версий Git. Через три дня после старта проекта его исходный код был помещён … в Git, и в дальнейшем разработка этого инструмента велась с помощью него самого.

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

    Кому нужен ваш продукт, если вы сами им не пользуетесь, предпочитая продукт конкурентов? Какого он качества? Зачем вы вообще его выпускаете и кого пытаетесь обмануть?

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

    С другой стороны, нужно очень чётко отдавать себе отчёт в том, что ваши личные предпочтения могут не совпадать с предпочтением большинства пользователей. Например, я привык вызывать программы, нажав Win+R, после чего набираю имя исполняемого файла запускаемого приложения. Но я прекрасно понимаю, что, с огромной вероятностью, ни один из пользователей нашего продукта так не делает.

    Для менеджера продукта очень важно отложить в сторону собственное эго и рассматривать продукт непредвзято. Но это уже совсем другая история.

    Выводы


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

    И тогда ваш продукт будет полезным, удобным и востребованным. А значит – успешным.

    Удачи в разработке ваших продуктов!
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 17

      +4
      >Кому нужен ваш продукт, если вы сами им не пользуетесь, предпочитая продукт конкурентов? Какого он качества? Зачем вы вообще его выпускаете и кого пытаетесь обмануть?

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

      Это хорошо работает, только если ваш продукт для программистов.
      Например на IDEA писать IDEA, или что разработчики TeamSity используют его у себя постоянно.
      Это хорошо и правильно.
      Но вот что делать программистам, которые делают продукт для сторонних сфер?
      Например программы для продавцов. Программисты не торгуют, у них нет торговых точек и т.д.
      Или же например какая нибудь встраиваемая штука для автомобилей, самолетов, поездов…
      Т.е. в ситуации, когда создаваемый продукт не может быть использован в процессе создания этого продукта.
      А ведь в большинстве случаев это именно так.
        +4
        Я уверен, что помимо написания кода программисты ещё иногда живут :). Они используют сервисы навигации, ищут информацию в интернете, играют в боулинг и лазертаг, ходят на дни рождения к друзьям, дарят подарки любимой девушке, копают тёщин огород :)

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

        Про встроенную штуку — вопрос немного более сложный. Кто её пользователи? Вероятно те, кто её встраивают. Сможете ли вы её встроить на самом деле? Сможете ли вы попасть на атомную станцию, чтобы протестировать софт для её оптимизации? Всё зависит от вас. И не акт, что получится. В этом случае придётся просто долго наблюдать их работу и представлять себя на их месте.
          0
          вот именно — тестовые закупки обязательны для использования ПО «на поле»
        +4
        «чёрт возьми, я опять промахнулся мимо этого элемента на экране смартфона, т.к. автобус тряхнуло!» — обычный кекс тоже так не скажет, он скажет «б… ть» и закроет чудо-приложение.
          +2
          Программа на скриншоте — не иначе, раннее творение от создателей PaintCad for Windows.
          –3
          Чтобы нормально пользоваться гитом большинству разработчиков нужно ставить гитфлоу, иначе это инструмент чужих для хищников. После меркириула у меня волосы вставали дыбом от мелочей, нужных последовательностях и нужных параметров. Гит рулит, когда вы ведёте несколько стабильных версий продукта, как ядра в линуксе.

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

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

            0
            Опять же — ничто не ново под луной.
            Спольски писал об этом в 2001, и до него подобные идеи уже были, как я понимаю:
            www.joelonsoftware.com/articles/fog0000000012.html
            Здесь есть на русском:
            www.books.ru/books/dzhoel-o-programmirovanii-fail-pdf-651529/?show=1
              +7
              Рекомендую «Психбольница в руках пациентов».

              Первоисточник этих идей и не только их.
                0
                Спасибо, это именно та книга, которая не перестаёт меня вдохновлять.
                0
                Для разработки интерфейсов подключаются люди (не программисты) которые проектируют этот самый интерфейс.
                Всегда спрашиваю дизайнеров или пользователей удобно пользоваться продуктом или нет.
                Как программист скажу, что порой связи в БД, между полями формы бывают настолько «хитрыми», что пользователя принудительно приходится ограничивать.
                  +6
                    0
                    Именно так и стараемся действовать, когда заказчик позволяет участвовать в работе Product owner-а. Я уже писала об этом подробнее — есть тут и персоны и еще некоторые инструменты, которые позволяют более глубоко проникнуть в шкуру пользователя. Давай замутим доклад на HappyDev?
                      0
                      Отличная статья, да!

                      Кстати, в отличие от этой, предельно практическая. Так что, всем читать :).

                      По поводу доклада — давай спишемся. В целом очень «за», но есть пара нюансов
                      0
                      Про персонажей при проектировке не пишет только ленивый, но на деле дипломированный UX не может на минуточку стать продавщицей Зиной и эти персоны ему как пятое колесо у телеги. Очень спорная тактика имхо, использование которой, на мой взгляд, лучше заменить более тесным общением с Product owner'ом и его сотрудниками.
                        +2
                        Начали за здравие закончили за упокой.
                        Человек который обосновывает плохие интерфейсы недоразивтием полушарий никогда в промышленой разработке больших проэктов не участвовал, а если и участвовал то вследствие высокой натуры не прочуствовал.
                        Во первых низашто не поверю что у автора окна на картинке все в порядке с кодом. Боюсь там крошиво из code behind и спагетти кода.
                        Во вторых уверен что проблема с порталом госуслуг не только в неумении разработчиков. А главная первопричина, что заказчику было наплевать на удобство интерфейса и его тестирование и вся оценка удобства проводилась по наличии интерфейса как такового. Сохранение вводимых данных говорите, это скорее всего непростой функционал который требует значительных усилий(кроме того возникает вопрос безопасности). Давайте угадаю как все случилось: до этапа программирования, бизнес аналитик получил требование что с точки зрения безопасности пользователя нужно выбрасывать из сесии через 15 минут. Хороший аналитик сразу спросит, а что будет с введенными даными, нужно ли их сохранять, потому что хороший бизнес аналитик отвечает за целосность и непротиворечивость бизнес требований. Допустим что наш аналитик даже увидел нужность сохранения данных. Дальше бизнес аналитик выясняет у заказчика, а что с удобством исспользования, а с удобством исспользования заказчик не понимает зачем оно ему и почему он должен за это платить. К тендеру приходим с понимает что чтобы выиграть нужно чем-то пожертвовать, потому пожертвовали «менее» критичным функционалом. Идем дальше, допустим что не пожертвовали, но пропустили по недогляденью, а где же итеративность процеса, развития проэкта. А нету заказчик готов максимум платить за сопровождение и мелкий багфиксинг, а надо будет что-то радикальнее править, так новый тендер и не факт что вы будете победителем. Где здесь роли, где здесь usability? Вопрос риторический. Usability появляется там где есть осознанное желание платить и понимание зачем мне это нужно у заказчика.
                        В третьих о полушариях. Можно спросить, а вы проводили какой-либо релевантный опрос с целью определить степень способности индивида? Потому что если смотреть оригинальные исследования, то речь шла о большей и меньшей способности индивида к решению определенного вида задач, а не полного неимения таковой, вы ведь не о имбецилах говорим. И программисты прекрасно учатся, особенно при наличии хороших примеров и менторства. Да возможно они не будут вам рисовать как Дали, но как эту формочку с двумя кнопочками расположить поверьте справятся, если им не будет лень и не до этого. Только проблема ведь не в этом, а в том чтобы заказчик (внешний или внутренний) был готов за это платить и понимал что ничего бесплатного не бывает. И 99% проблем с usability происходят из этого. И не стоит к каждому «творческому» заданию лепить уже заезженый штам о полушариях как обоснование.
                          0
                          Вот вы пишите, что программисты — они не за что не отвечают и обычно тупо пишут что сказали. Я с этим спорить не буду. Возможно в отдельных компаниях так принято. Может быть даже их большинство.

                          Я не о том сказать хотел: вопрос не в том, что «работает только одно полушарие из двух» а в том, что в проекте у программиста и маркетолога-аналитика-продакта-заказчика (зовите как хотите) принципиально разные ценности. Сам долгое время работал программистом, кроме того, с несколькими десятками девелоперов взаимодействовал в роле ПМа, аналитика, продакта и заказчика. Ага, на вполне крупных промышленных проектах.

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

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

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

                        Only users with full accounts can post comments. Log in, please.