«Психбольница в руках пациентов» Купера
Зачем читать книгу?
Для того, чтобы отбросить излишнюю «креативность» и перестать усложнять и без того непростые вещи. Понять, что не стоит взваливать на рациональных программистов (читай: проектировщиков функционала) такое иррациональное проектирование взаимодействия.
Чем крут автор?
Милый улыбчивый дядька с широким овалом лица — наш современник. Бо́льшую часть своей профессиональной деятельности занимался разработкой ПО. Еще в начале своей карьеры Купер всерьез задумался, почему разработчики не спрашивают у пользователей их мнения. Именно об этом он впоследствии написал книгу. Также Купер предложил метод проектирования с помощью персон, который теперь так популярен среди юиксеров.
Ключевые мысли из книги своими словами
Автор уверен, что деловой человек либо владеет высокими технологиями, либо… скоро перестанет быть деловым человеком, потеряв свой бизнес. Уж слишком широко вошли в нашу жизнь эти пресловутые IT. Если инфо-система неэффективно внедрена в бизнес, компания будет нести колоссальные убытки. Такова суровая реальность.
Именно поэтому в аналитику и проектирование программного продукта стоит вкладывать гораздо больше времени и денег, чем в его последующее производство и внедрение.
Бесполезная точность
Современные компьютеры зачастую могут сообщать нам факты, но вовсе не информируют нас. Их указания точны, но не способны привести к нужному результату.
Пилот рейса Майами — Кали в начале полета должен был выбрать радиомаяк по имени «ROZO». Но нажав на первый в списке маяк «ROMEO», он направил самолет неверным курсом, и произошла авиакатастрофа. Во всем обвинили пилота, но ведь компьютер мог бы сообщить, что «ROMEO» — неподходящий маяк для Кали.
Современные кофеварки, будильники, фотоаппараты, автомобили невероятно компьютеризированы. Но зачастую общаться с этими (призванными облегчать нам жизнь) устройствами так сложно! Например, банкомат при малейшей ошибке прерывает операцию, вовсе не уведомляя, что произошло. Он следует установленным правилам, а пользователь даже не может их узнать. И разница между ошибкой во взаимодействии с банкоматом и бортовым компьютером самолета лишь в масштабности последствий.
Банкомат постоянно уточняет, с какого счета пользователь хочет снять деньги, хотя у него один счет. Он налагает ограничение на сумму обналичивания. И если ввести число хотя бы на пару единиц больше заданного, то банкомат откажет в проведении операции, просто сообщив, что «превышен лимит».
Умалишенные программисты
Без обид. Именно такую аналогию проводит автор, обосновывая название книги. По его словам, во главе индустрии высоких технологий стоят рядовые разработчики. Они работают над сложным функционалом и высокой производительностью продуктов, но игнорируют ежедневные сложности его использования.
«Когда психбольница в руках пациентов, им сложно четко осознать природу собственных проблем» — заключает автор.
Пара важных терминов
Купер поясняет, что в вопросах проектирования много неоднозначно определяемых понятий и дает самым важным из них развернутое пояснение.
Когнитивное сопротивление
С ним сталкивается любой пользователь, пытающийся разобраться в сложной системе динамически изменяющихся правил.
Игра на скрипке кажется сложной, но вызывает меньшее когнитивное сопротивление, чем использование простой микроволновки. Ведь мы знаем, чего ожидать от скрипки — воспроизведения набора звуков при касании смычком струн. А как поведет себя микроволновка после нажатия на ряд кнопок, известно одному разработчику.
Проектирование взаимодействия
Любое проектирование — это принятие решений о том, как одна процедура будет связана с другими в рамках целостных операций, как будет передаваться, изменяться и храниться информация. Проектированием взаимодействия можно назвать все решения, напрямую влияющие на конечного пользователя. Остальное — проектированием программы.
Говоря об этом термине, автор упоминает о распространенных формулировках «проектирование интерфейса», «поведенческое проектирование» и «концептуальное проектирование». Все они кажутся Куперу недостаточно ёмкими.
Это наиболее сложный для восприятия термин, ведь по сути весь процесс создания ПО — это одно большое проектирование, начиная с выбора языка программирования, заканчивая подбором цвета бейсболки курьера.
Борясь с Законом Паркинсона
Ставя задачу подчиненным, любой руководитель уверен, что, согласно вышеупомянутому закону, работа заполняет время, отведенное на неё. Проще говоря, одно и то же можно делать месяц, а можно, при необходимости, успеть и за ночь.
Именно поэтому компании часто ставят разработчикам нереальные сроки и торопят поскорее выполнить работу. Главное, что б у выпущенного продукта было как можно меньше багов. Однако, нельзя с точностью сказать, готов ли продукт на 100%, потому что мало кто удосуживается детально описать его конченый вариант.
У многих программ нет четких описаний, зато имеется большой перечень требуемых функций. Но ведь список покупок, требуемых для приготовления пирога не поможет испечь вкусную румяную шарлотку.
Вредные советы
Автор систематизирует недостатки программ его времени, демонстрируя, как НЕ надо делать грамотному проектировщику.
Программа не запоминает уже проделанных действий или ранее вводимой информации.
Программа сложна настолько, что кажется, будто бы сделаны только для самих программистов.
Программа не выдает нужную информацию.
Программа возлагает на пользователя ответственность и всегда делает его «виноватым».
Программа постоянно переспрашивает очевидные вещи в диалогах подтверждения.
Слагаемые успеха
Ларри Кили утверждает, что существует всего три слагаемых качества продукта в сфере IT:
Потенциал. За него отвечают инженеры, имеющие те или иные ограничения своих способностей и возможностей.
Жизнеспособность. За неё отвечают продажники, понимающие, что может быть востребованным на рынке.
Привлекательность. За неё отвечаю проектировщики, изучающие, что сделает потребителей счастливыми и удовлетворит все их потребности.
В идеале разработка любого продукта должна начинаться с последнего пункта. Сначала проектировщики выясняют, что нужно пользователям, затем рекламщики продумывают стратегию реализации продукта, и только потом технари выполняют поставленные задачи по разработке.
Такое иррациональное проектирование
Автор уверен: проектировщик — это отдельная полноценная профессия. Например, многие разработчики считают себя отличными проектировщиками, но между проектированием функционала и проектированием взаимодействия лежит огромная пропастью. Ведь первое — крайне рационально, а в мире живых людей правят бал эмоциональность и иррациональность.
Купер утверждает, что может легко понять, обладает ли его собеседник незаурядными логическими способностями. Для этого он спрашивает, куда пойдет человек, поднявшись на борт самолета: в кабину или в салон. Если в ответ он слышит, что человек жаждет обрести контроль над полетом и идет в кабину пилота, значит, перед ним «Ноmo Logicus». Скорее всего это инженер, программист или другой технарь.
Наконец об инструментах!
1. Персонажи
Персонажи — гипотетические архетипы пользователей. Это не тоже самое, что обычные пользователи, это среднестатистическое описание каждой из групп юзеров.
Как утверждает автор, успеха в проектировании можно добиться, лишь сосредоточившись на одном персонаже. Каждый раз, расширяя функционал, для охвата еще одного пользователя, в интерфейсе появляются дополнительные ограничители для остальных.
Допустимое кол-во персонажей: от 3 до 12. Однако всегда стоит выбирать ключевого. Того, для кого в первую очередь будет создан продукт.
Необходимо, например, спроектировать автомобиль для «широких масс». Сразу выделяется минимум три группы пользователей: глава семейства, который будет перевозить на авто, скажем, материалы для ремонта; молодая мама с ребенком, нуждающаяся в безопасном автомобиле; активный студент, ожидающий, что его машина будет обладать модным мотором и откидным верхом. Даже если и удастся создать автомобиль, совмещающий в себе все требуемые качества, его в итоге никто не купит.
Чем конкретнее описан персонаж, тем более эффективным становится этот инструмент. Однако не стоит сравнивать персонажа с реальным человеком. Ведь многие особенности отдельного взятого пользователя не характерны для всей описываемой группы. Но стоит остерегаться и обратного. Слишком усредненные персонажи не дадут никакой пользы в проектировании. Их, как говорит автор, «великая сила» в том, что они точны и конкретны.
Думая о тех или иных функциях, стоит задавать вопрос не «нужна ли пользователю возможность вывода страницы на печать?», «требуется ли Розмари печать документа? А как часто это может понадобиться Джейкобу?».
Автор отмечает две сложности, связанные с персонажами:
Во-первых, не стоит путать персонажей в маркетинге с персонажами в проектировании. Первые описываются на основании демографических данных и планируемых каналов сбыта, а последние — исключительно на основе реальных пользователей.
Во-вторых, важно не сбиться на проектирование для человека, близкого к продукту, возможно, покупающего его, но не использующего (руководитель, менеджер, снабженец).
Выбирая из всех персонажей ключевого, стоит ориентироваться на наименее опытного и продвинутого, Ведь опытные пользователи смогут справиться с любым интерфейсом, будь он простым или сложным. Так, проектируя систему просмотра фильмов на борту самолета, команда Купера ориентировалась не на продвинутого переводчика или проницательную студентку, а на шестидесятилетнего фермера.
2. Цели
Цели неотделимы от персонажа. Очень важно не путать их с задачами, ведь те преходящи, а цели постоянны. Они могут личными, корпоративными и практическими. Первые всегда важнее.
3. Сценарии
Сценарий в UX-проектировании — ёмкое описание использование интерфейса для достижения цели персонажа. Важно детализировать более частые сценарии, нежели описывать какие-либо исключительные случаи.
изнь эти пресловутые IT. Если инфо-система неэффективно внедрена в бизнес, компания будет нести колоссальные убытки. Такова суровая реальность.
Когда проектировщик готовит сценарий для персонажа, он должен забыть о своем опыте, образовании и навыках. Ему, подобно хорошему актеру, необходимо вжиться в образ выбранного героя.
Повседневные сценарии описывают часто выполняемые простые действия. Чаще всего это один (максимум три) сценария. И они нуждаются в самой качественной проработке взаимодействия. Обязательные сценарии выполняются редко, но неукоснительно. Их проработка не менее важна.
Не следует зацикливаться на третьем типе — сценариях исключительных ситуаций. Редко используемый и невостребованный функционал не обязательно урезать, однако тратить кучу сил и времени на доведение его до совершенства не стоит.
Важные уточнения
Адаптирующийся интерфейс. Продукт может предоставлять широкий набор функций, но единичному пользователю для выполнения конкретной задачи стоит предоставлять только требуемые ему опции.
Разумная внимательность. Клиентов (ваших непосредственных заказчиков) стоит внимательно выслушивать, но не нужно слепо следовать всем их требованиям. Важно понять: продукт делается для конечного пользователя, а не для заказчика.
Важность детализации. Все выводы и предложения необходимо тщательно документировать, иллюстрировать, отображать в прототипах настолько детально, чтобы разработчики могли использовать полученные данные в качестве полноценной инструкции.
Словарь разработчика. Иногда у каждого из участников команды разработки может сформироваться своя субъективная трактовка терминов. Чтобы этого не случилось, следует прописывать наиболее спорные термины в импровизированный словарь.
Инструмент «представь себе!». Иногда ограничения настолько привычны, что перекрывают дорогу к правильным решениям. Чтобы избежать этого, можно применить простое «упражнение» от автора книги и попытаться проиграть сценарий взаимодействия на воображаемом супер-компьютере, не имеющем ни одного ограничения.
Юзабилити-тестирование
Тестирование готового продукта безусловно полезно. Но гораздо более информативными являются исследования юзабилити до начала его разработки. Кликабельные прототипы в помощь!
При подобном тестировании следует с большой осторожностью относиться к фокус-группам. Например, все на самом деле удобные нововведения могут быть отвергнуты ими из-за банальной непривычности.
Как говорит Купер, методы исследования очень похожи на наждачку. Она поможет сделать стол или стул более гладкими, но, как бы усердно мастер не занимался шлифовкой, он не сможет с ее помощью превратить стол в стул.
Дочитали до конца? Можете быть уверены, что этими семью минутами заменили прочтение почти сотни страниц (:
целых 360 страниц (:
