Главная страница
Навигация по странице:

  • Проектируйте для одного персонажа

  • Чемодан на колесиках и клейкие бумажки

  • Гуттаперчевый пользователь

  • Персонаж должен быть конкретным

  • Персонаж должен быть воображаемым

  • Описание должно быть подробным, а не идеальным

  • Архитектура встраиваемых систем. Работа с таймерами МК. Отчет по лабораторной работе. Алан Купер Психбольница в руках пациентов


    Скачать 7.24 Mb.
    НазваниеАлан Купер Психбольница в руках пациентов
    АнкорАрхитектура встраиваемых систем. Работа с таймерами МК. Отчет по лабораторной работе
    Дата11.04.2023
    Размер7.24 Mb.
    Формат файлаpdf
    Имя файлаpsikhbolnitsa_v_rukakh_patsientov_kuper.pdf
    ТипДокументы
    #1053896
    страница12 из 21
    1   ...   8   9   10   11   12   13   14   15   ...   21
    Глава 9. Проектирование для удовольствия
    Альберт Эйнштейн сказал, что нельзя решить проблему, находясь внутри системы, которая ее породила. Я уделил уже достаточно времени тому, чтобы идентифицировать старый образ мышления и показать, почему он неработоспособен. Теперь настало время поговорить о новом методе, который работает. Начиная с 1992 года я занимался разработкой такого метода, получившего название целеориентированного проектирования(Goal-Directed Design), и проектировщики в моей консультационной компании применяют его во всех проектах. В основе метода лежат нетрадиционные подходы к проблемам, ряд мощных руководящих аксиом, а также некоторые поразительно эффективные мыслительные инструменты. В следующих трех главах я представлю обзор трех наиболее мощных инструментов, а также примеры их применения и результаты, которых можно ожидать.
    Персонажи
    Принципы действия самых мощных инструментов всегда просты, однако применение таких инструментов весьма нетривиально. Это, несомненно, верно и для инструментов проектирования взаимодействия. Наш самый эффективный инструмент исключительно прост: это точное описание пользователя продукта и его целей.
    Сложность здесь в том, чтобы создать и применить такое точное описание.
    Наиболее очевидный подход состоит в том, чтобы найти реального пользователя и расспросить его, но этот подход неэффективен по ряду причин, и основная из них такова, что жертва определенной проблемы не наделяется автоматически силой, позволяющей эту проблему решить. Реальный пользователь - источник, конечно же, ценный, и мы уделяем большое внимание, но никогда не позволяем напрямую влиять на принимаемое решение.
    Работоспособный подход кажется примитивным, но обладает невероятноймощью и эффективен во всех случаях. Мы выдумываем несуществующих пользователей и проектируем для них. Мы называем таких несуществующих пользователей персонажами

    163
    (personas
    1
    ), и они представляют собой необходимую базу качественного проектирования взаимодействия.
    Персонажи
    2
    - не реальные люди, но они представляют реальных людей в процессе проектирования. Это гипотетические архетипы реальных пользователей. Будучи воображаемыми, они, тем не менее, определяются достаточно жестко и точно. На практике мы не столько «выдумываем» персонажи, сколько обнаруживаем их в качестве побочного продукта процесса расследования. Но мы действительно выдумываем их имена и личные сведения.
    Персонажи определяются своими целями. Цели же, разумеется, определяются персонажами. Похоже на тавтологию, но это не так. Свойства персонажей 'выявляются в процессе изучения и анализа так же, как серия тектонических событий выявляется геологами по слоям осадочных пород: присутствие окаменелостей указывает на геологический пласт, а сам геологический пласт указывает на наличие окаменелостей. В следующей главе я много скажу о целях, сейчас же замечу, что мы выявляем их так же, как выявляем персонажи. Мы определяем, какие персонажи имеют отношение к делу, а также их цели в процессе итеративного совершенствования в рамках начального исследования предметной области.
    Как правило, мы начинаем с разумного приближения и быстро сосредотачиваемся на правдоподобном наборе персонажей. Данный итеративный процесс похож на итеративный процесс, применяемый разработчиками программного обеспечения при создании продуктов, но имеет одно фундаментальное отличие. Циклическое совершенствование дизайна проекта и его предпосылок происходит быстро и легко, так как мы работаем на бумаге, работаем с текстом. Но циклическое совершенствование реализованного продукта медленнее и сложнее, поскольку здесь необходимо кодирование.
    1
    Всем печатникам и любителям латыни, читающим книгу, будет небезынтересно узнать, что в Cooper Interaction Design нешуточные битвы между сторонниками «personas» и «personæ» кипят ежедневно. Первые говорят, что произношение слова
    «personas» более однозначно, мы избавляемся от неуместных лигатур, а нашим клиентам это слово кажется более привычным и не таким страшным. Защитники «personæ» возражают, что произношение нетрудно освоить, а лигатуры – как манна с небес – ничего не стоят, не говоря уже о том, что наши клиенты достаточно образованны, чтобы спокойно применять загадочную и устаревшую лексику. На мой взгляд, все это похоже на споры программистов об алгоритмах, и в этой книге я решил придерживаться написания «personas».
    2
    Из двух вариантов перевода «персона» и «персонаж» был выбран второй. Краткая справка: «персонаж» (франц. personnage, от лат. persona – личность, лицо) – действующее лицо пьесы (спектакля), сценария (кинофильма), романа и других художественных произведений. Второй термин ближе к функциональной смысловой нагрузке понятия и легче понимается неподготовленными лицами (программистами и руководителями). – Примеч. науч. ред.

    164
    Проектируйте для одного персонажа
    Чтобы создать продукт, удовлетворяющий широкую аудиторию пользователей, как подсказывает логика, необходимо возможно больше расширить его функциональность, охватив, таким образом, как можно больше людей. Это ошибочная логика. Вы добьетесь гораздо большего успеха, проектируя для единственного человека.
    Представьте, что проектируете автомобиль, удовлетворяющий вкусам широких масс. Можно с легкостью выделить по меньшей мере три подгруппы пользователей: мать с малолетним ребенком, плотник, младший руководящий работник. Мамочке нужна безопасная, надежная машина, просторная, с большими дверями, для перевозки детей, собак, пакетов с покупками и т. д. Плотнику Джо нужен крепкий полноприводный пикап, достаточно большой, чтобы в него поместились лестницы, материалы, мешки с цементом и ящики с инструментами. Младший руководящий работник Сет видит себя в машине спортивного типа с мощным двигателем, жесткой подвеской, откидным верхом и - места в машине должно хватать только на двоих.
    Решение задачи показано на рисунке. Такой автомобиль сочетает пожелания каждого водителя: минивэн с откидным верхом, пространством для детей и пиломатериалов. Что за дурацкая, невозможная машина! Даже если ее создать, ее никто не купит. Правильное решение: создать минивэн для Мамочки, пикап для Джо, спортивную машину для Сета.
    Создать три различных программных продукта проще, чем создать три автомобиля, потому что единственный продукт, как правило, всегда можно настроить таким образом, чтобы получить три различных варианта поведения (заметим, что работу по настройке нельзя взваливать на пользователя).
    Всякий раз, расширяя функциональность, чтобы охватить еще одного пользователя,

    165 вы ставите искусственные ограничители в виде лишних возможностей и органов управления программой на пути всех прочих пользователей. Выясняется, что механизмы, приятные одним пользователям, мешают другим получать удовольствие и удовлетворение. Попытка угодить слишком многим может убить продукт, хороший в других отношениях. Однако если спроектировать интерфейс с учетом одного персонажа, ничто не сможет встать между этим персонажем и абсолютным счастьем.
    Роберт Лутц (Robert Lutz), руководитель компании Chrysler, говорит, что 80% участников фокус-группы возненавидели новый пикап Dodge Ram. Но после выхода на рынок машина стала бестселлером, потому что остальные 20% в нее влюбились. Любовь людей к продукту, пусть даже этих людей не очень много, - вот ключ к успеху.
    Чем больше размер мишени, тем меньше вероятность попадания «в яблочко». Если вы желаете достичь уровня удовлетворенности продуктом в 50%, это невозможно сделать, осчастливив 50% широкой аудитории, Единственный способ достичь цели состоит в том; чтобы выявить эти 50% и стремиться осчастливить их на 100% . И это еще не все. Еще большего успеха можно добиться, если выделить 10% рыночной аудитории и направить свои усилия на то, чтобы вызвать у них стопроцентный восторг. На первый взгляд - противоречие, однако проектирование для единственного пользователя - самый эффективный способ удовлетворить широкую аудиторию.
    Чемодан на колесиках и клейкие бумажки
    Чемодан на колесиках - хороший пример эффективности проектирования для одного человека. Этот небольшой чемодан со встроенными колесами и убирающейся ручкой произвел целую революцию в области багажа, а проектировался при этом совсем не для широкой аудитории. Изначально чемодан задумывался для экипажей самолетов, то есть для очень узкой аудитории пользователей. Чистота дизайна продукта принесла этой группе пользователей полное удовлетворение. Остальные путешественники вскоре осознали, что такой чемодан решает и их проблемы тоже. Его легко перевозить по переполненным людьми аэропортам, маневрировать между рядами кресел в самолете и завозить на борт.
    После успеха чемоданов на колесиках в целевом сегменте продукт выпустили и на другие рынки. Сегодня в продаже есть большие чемоданы на колесах, чемоданы на колесиках «haute couture», бронированные чемоданы на колесиках, детские чемоданы на

    166 колесиках. Сегодня уже непросто купить багажный чемодан без встроенных колес и убирающейся ручки.
    Вот другой пример. Арт Фрай (Art Fry), инженер отдела клейких материалов компании 3М, решая свои личные, сугубо специфические задачи, создал, можно сказать, самый распространенный и полезный из офисных аксессуаров. Арт Фрай пел в церковном хоре и постоянно сбивался, потому что бумажные закладки выпадали из псалтыря. Не желая портить церковную собственность скотчем, он принялся за поиски лучшего решения. Он вспомнил о клейком материале, над которым работал за несколько лет до описываемых событий. Материал не пошел в производство, поскольку имел низкий коэффициент сцепления. Арт нанес этот неудавшийся материал на небольшие квадратики желтой бумаги и получил удобные закладки. Вот так родились клейкие бумажки Post-It Note компании 3М.
    Счастливые пользователи - невероятно эффективное и ценное приобретение. Сужая фокус, можно получить фанатично преданных клиентов целевого рынка. Как видно из главы 5 «Нелояльность клиентов», преданность покупателей становится хорошей поддержкой в трудные времена. Преданные пользователи не просто готовы покорять горы И вброд преодолевать реки, они также представляют собой самый мощный из известных инструментов маркетинга: Преданные пользователи лично рекомендуют вас друзьям. Добившись шумихи вокруг своего продукта, вы сможете завоевать и соседние сегменты рынка.
    Гуттаперчевый пользователь
    Наша цель состоит в том, чтобы удовлетворить пользователя, но термин
    «пользователь» является источником трудностей. Из-за своей нечеткости этот термин бесполезен, как циркулярная пила бесполезна для удаления аппендикса. Нам нужен более точный инструмент проектирования.
    Те, кто говорит «пользователь», обычно подразумевают эдакое «гуттаперчевое» создание, которому приходится изгибаться, растягиваться и адаптироваться к потребностям момента. Наша же цель состоит в проектировании программ, которые будут изгибаться, растягиваться и адаптироваться к потребностям пользователя.
    Программисты писали и пишут бессчетные множества программ для этого мифологического гуттаперчевого потребителя. Когда программист находит удобным

    167 познакомить пользователя с файловой системой Windows для поиска нужной информации, то определяет гуттаперчевого пользователя как пользователя, способного адаптироваться, продвинутого, образованного в области компьютеров в других случаях, когда программист находит удобным: провести пользователя через сложный процесс посредством бестолкового мастера, то определяет гуттаперчевого пользователя как покладистого наивного новичка. Проектирование для гуттаперчевых пользователей дает разработчику разрешение писать код как угодно, лицемерно презирая «юзера». Реальные пользователи не эластичны.
    Программисты создали выразительную систему, описывающую конструирование программного обеспечения. Хорошие программисты не бросаются глупыми обобщениями на тему различных компьютеров и систем. Программист никогда не скажет: «Это будет хорошо работать на компьютере». На каком компьютере? На какой модели? Под управлением какой операционной системы? С какими периферийными устройствами? Точно так же проектировщику никогда не следует расплывчато говорить о программах, будто они «спроектированы для пользователя» или «дружелюбны к пользователю». Такие слова обычно призваны оправдать навязывание собственных интересов.
    В нашем процессе проектирования нет места «пользователю продукта» мы говорим о совершенно конкретном человеке - о персонаже.
    Персонаж должен быть конкретным
    Чем более конкретными мы делаем персонажи, тем более эффективными инструментами проектирования они становятся. Происходит это потому, что по мере конкретизации персонажи теряют эластичность. К примеру, мы не можем просто сказать,

    168 что Эмили пользуется офисными приложениями. Мы говорим, что Эмили пишет письма бабушке при помощи WordPerfect версии 5.1. Мы не позволяем Эмили просто поехать на работу. Мы снабжаем ее темно-синей Toyota Camry выпуска 1991 г., с серым пластиковым детским сиденьем и отвратной царапиной на заднем бампере. Мы не позволяем Эмили просто пойти на работу. Мы назначаем ее клерком по заведению счетов в бежевом отсеке компании Global Airways в Мемфисе, штат Теннесси. Такая характерная детализация - очень мощный инструмент проектирования и коммуникации.
    Как следствие, все наши персонажи описываются с тщательным вниманием к деталям.
    По мере обрастания Эмили конкретными отличительными чертами происходит замечательная вещь: она становится в представлении разработчиков реальным человеком. Ее можно называть по имени, как реального человека. Она приобретает осязаемое воплощение, которое позволяет в процессе проектирования видеть все предположения с ее точки зрения. По мере того как Эмили утрачивает гуттаперчевость, мы начинаем видеть, каковы ее умения, какова ее мотивация, чего она желает достичь.
    Вооруженные этим знанием, мы способны изучить ее в свете предметной области программы и понять, является ли она в действительности архетипом пользователя.
    Проектировщик, обладающий некоторым опытом, обычно способен синтезировать подходящий персонаж с первой попытки.
    Одним из самых важных шагов в успешном определении персонажа является выбор имени. Персонаж без имени просто не имеет смысла. Никто не сможет представить себе такой персонаж как конкретного человека.
    В стремлении к равенству я не избегаю людей различных рас, полов, национальностей, но стараюсь не выбирать типичных представителей аудитории, поскольку это всех запутает. Шаблонный персонаж более эффективен, если шаблонность придает ему достоверность. Моя цель не в том, Чтобы соблюсти политкорректность, но в том, чтобы всех убедить в реальности моих персонажей. Если персонаж - медсестра, то я скорее сделаю ее женщиной, а не мужчиной, и не потому, что медбратьев не бывает, а потому, что подавляющее большинство составляют все-таки медсестры. Если пользователь - компьютерный техник, то персонажем станет «Ник», прыщавый двадцатитрехлетний молодой человек, бывший член школьного клуба Аудио и Видео, а не «Хелен», отлично сложенная красавица ростом 175 сантиметров, посещавшая школу в
    Беверли Хиллз. Я стремлюсь к правдоподобию, а не к разнообразию.

    169
    Чтобы сделать каждый персонаж более реальным для участников проекта, я люблю дополнять имена портретами, прикреплять к каждому персонажу изображение. Как правило, я покупаю изображения в ceтевых фотобиблиотеках, но мне случалось работать и с быстрыми набросками. Можете вырезать изображения из журналов, если угодно.
    Четко обозначенный, полностью развитый персонаж становится мощным инструментом. До тех пор, пока пользователь не имеет четкого определения, программист может воображать, будто пользователем является он сам. Четко определенный персонаж - это ключ к подавлению склонности разработчика искажать характеристики пользователей. Задолго до написания первой строки кода качественно определенный персонаж становится невероятно эффективным средством для проектирования взаимодействия.
    Персонаж должен быть воображаемым
    Важно не путать точное определение пользователя с реальным человеком. Реальные люди представляют огромный интерес как база для исследований, однако для самого процесса проектирования они обычно бесполезны, а часто и пагубны. Здесь уместна аналогия с вином: тонкий букет хорошего вина отлично подойдет к ужину, а необработанные грозди винограда Каберне Совиньон - с крохотными, жесткими ягодами
    - способны его испортить. Многие ученые, испытывая глубокое почтение к эмпирическим данным, путают реальных пользователей с воображаемыми, более ценными проектировочными персонажами.
    Вторая серьезная проблема, связанная с реальными пользователями, состоит в том, что им, как всем настоящим людям, присущи забавные причуды и аномалии поведения, мешающие процессу проектирования. Такие особенности отдельного индивидуума не характерны для группы. Неприятие одним пользователем непосредственного манипулирования объектами на экране не означает, что его точку зрения разделяют все пользователи или хотя бы большинство пользователей. Обратное также верно. Наш реальный пользователь может замечательно справиться с какой-нибудь проблемой в понимании сложного взаимодействия, тогда как большинство пользователей этого сделать не смогут. Соблазн приписать такую способность всем пользователям лишь потому, что ими обладает реальный человек, очень силен, но этого соблазна следует избегать.

    170
    В частности, мы наблюдаем, как поддаются такому соблазну президенты компаний.
    Один президент, с которым нам довелось работать, ненавидит клавиатурный набор и желает выполнять всю работу без помощи клавиатуры. Он ввел в действие инструкцию, по которой все программы, создаваемые компанией, должны управляться только мышью. Разумно стремиться к управлению программами лишь при помощи мыши, однако не разумно списывать со счетов всех тех пользователей, которым удобнее работать как раз с клавиатурой. Этот президент - не слишком типичный персонаж.
    Описание должно быть подробным, а не идеальным
    Если говорить о средствах проектирования, то важнее детальность персонажа, а не идеальность ее описания. То есть важнее определить персонаж насколько возможно подробно и конкретно, чем создать абсолютно правильный персонаж. Это удивительная истина, поскольку она противоречит цели проектирования взаимодействия, где правильность всегда важнее точности. Конечная цель состоит в том, чтобы получить программу, которая делает то, что нужно, и мы готовы допустить некоторые трудности в работе с системой, чтобы этой цели достичь.
    В подвижных узлах механических устройств не должно быть люфта. Так, поршень должен двигаться в цилиндре с минимальным зазором. Любой люфт приведет к быстрому разрушению поршня. В данном случае длина поршня не имеет такого значения, как притирка. То же верно и для персонажей. Персонаж должен иметь определение достаточно четкое, чтобы сохранять устойчивость под давлением разработки, и это важнее, чем создать правильный персонаж.
    К примеру, проектируя чемодан на колесиках, в качестве персонажа мы могли бы взять Герда, командира рейса Боинга-747 из Ванкувера во Франкфурт.
    С одной стороны, мы не можем расширением персонажа охватить всех пилотов коммерческих рейсов. Скажем, Соня посещает занятия в Университете аэронавтики
    Эмбри-Риддл и собирается стать профессиональным пилотом после выпуска. Она летает ежедневно, но только на маленьких одномоторных самолетах, и никогда не ночует вне дома. Если говорить о багаже, то Соня - крайний случай. Если определение Герда распространить на Соню, то персонаж из точного превращается в размытый. Начинаются бесконечные и бесцельные дискуссии о том, является ли Соня пилотом авиалиний, и о том, какие требования предъявляет она к своему багажу.

    171
    С другой стороны, проектируя чемодан на колесиках, мы можем в качестве прототипа рассматривать Франсин, стюардессу компании на Reno Air. Она трижды в день преодолевает немалые расстояния, раздавая напитки и пакетики с арахисом. Герд и
    Франсин совершенно разные личности, но их цели и потребности в области багажа эквивалентны.
    Программисты живут исключительными ситуациями, и под этим влиянием выбирают персонажи. Они будут спорить, что Соня законно претендует на роль персонажа, поскольку занимает место пилота. В этом разница - программирование определяется краевыми случаями предметной области, а проектирование - центральными. Если есть хоть какое-то сочинение в центральном расположении персонажа, этот персонаж следует исключить из рассмотрения.
    В интересах точного определения персонажей необходимо определить средние показатели. Средний пользователь никогда не бывает математически средним. У среднего человека в моем населенном пункте 2,3 ребенка, но ни у одного жителя города не может быть такого количества Детей. Более полезным представителем мог быть стать
    Сэмюэл, отец двоих детей, или Уэллс, у которого трое детей. Сэмюэл полезен, потому что он личность. Да, гипотетическая, но обладающая точными характеристиками.
    Родитель, имеющий 2,3 ребенка, не может существовать, как раз из-за этого невозможного среднего показателя.
    Усредненные персонажи уничтожают преимущества конкретности точных. Великая сила персонажей именно в их точности и конкретике. Обобщенные данные сводят эту силу на нет.
    Персонажи - самый мощный из имеющихся в нашем распоряжении инструментов проектирования. Они являются основой целеориентированного проектирования.
    Персонажи позволяют нам видеть масштаб и природу проблемы проектирования.
    Позволяют точно понять и определить цели пользователя и таким образом определить, что должен делать продукт и чего он может совершенно спокойно не делать. Точно определенный персонаж дает нам определенность относительно уровня владения пользователя компьютером, поэтому мы перестаем терзаться загадкой, для кого проектировать: для дилетанта или специалиста.
    Изобретенные персонажи уникальны для каждого проекта. Время от времени мы обращаемся к персонажам из прошлых проектов, но требование точности делает

    172 практически невозможным существование двух идентичных персонажей.
    1   ...   8   9   10   11   12   13   14   15   ...   21


    написать администратору сайта