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