Название
страница4/31
Дата публикации22.06.2013
Размер5.84 Mb.
ТипДокументы
100-bal.ru > Информатика > Документы
1   2   3   4   5   6   7   8   9   ...   31
Глава 1. Проектирование, ориентированное на цели

Глава 2. Модели реализации и ментальные модели

Глава 3. Новички, эксперты и середняки

Глава 4. Как понять пользователей: качественные исследования

Глава 5. Модели пользователей: персонажи и цели

Глава 6. Основы проектирования: сценарии и требования

Глава 7. От требований к пользовательскому интерфейсу: общая инфраструктура и детализация
1

Проектирование, ориентированное на цели

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

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

Цифровым продуктам необходимы

более качественные методы проектирования

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

Проектирование, по мнению промышленного дизайнера Виктора Па-панека (Victor Papanek), есть сознательные и интуитивные усилия

2 3ак. 1494
34 Глава 1. Проектирование, ориентированное на цели

по созданию значимого порядка.1 Мы предлагаем несколько более подробное определение проектирования, ориентированного на людей:

  • понимание желаний, потребностей, мотивации пользователей и кон
    текста, в котором эти пользователи находятся;

  • понимание возможностей, требований и ограничений бизнеса, тех
    нологии и предметной области;

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

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

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

Современное проектирование цифровых продуктов

Цифровые продукты рождаются в результате перетягивания каната двумя нередко враждующими силами - разработчиками и маркетологами. Маркетологи, конечно же, хорошо замечают и оценивают возможности по выходу на рынок, способны представить и позиционировать продукт, однако их вклад в процесс проектирования продукта часто ограничивается списком требований, который передается разработчикам. Эти требования зачастую далеки от реальных потребностей и желаний пользователей и имеют гораздо большее отношение к борьбе с конкурентами, к управлению ИТ-ресурсами посредством перечня задач и к предположениям, которые построены на основе исследований рынка, представляющих информацию о том, что люди обещают покупать. (Вопреки интуитивному мнению, мало кто способен четко выразить свои потребности. Столкнувшись с прямыми вопросами относительно используемых продуктов, большинство людей сосредотачиваются на незначительных задачах или способах борьбы с изъянами продуктов.) К сожалению, перечень из сотен функций, к которому сводится интерактивный продукт, слабо пригоден для создания той

В. Папанек «Дизайн для реального мира». - Пер. с англ. - М.. Л. Aронов


2008.
Цифровым продуктам необходимы более качеавенные методы проектирования

35


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

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

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

Имеется в виду английская пословица You can put lipstick on a pig, but it's still a pig (Свинья есть свинья, сколько ее ни крась). - Примеч. перев.


36

Глава 1. Проектирование, ориентированное на цели




Рис. 1.1. Эволюция процесса разработки программного обеспечения. На первой диаграмме отражены ранние дни индустрии программного обеспечения, когда умные программисты вынашивали идею продукта, а затем создавали и самостоятельно тестировали его. Разумеется, на каком-то этапе в процесс встроились профессиональные управленцы, которые помогали переводить благоприятные рыночные возможности на язык требований к продукту. Как видно из третьей диаграммы, индустрия повзрослела, и тестирование превратилось в самостоятельную дисциплину, а с распространением графических пользовательских интерфейсов (graphical user interface, GUI) к процессу подключились графические дизайнеры, которые создавали пиктограммы и прочие визуальные элементы. На последней диаграмме отражен целеориентированный подход к разработке программного обеспечения, когда решения о возможностях продукта, его форме и поведении принимаются до начала дорогостоящей и сложной фазы создания продукта

данных, они будут продолжать создавать цифровые продукты, вызывающие у нас презрение. Вот некоторые симптомы этого недуга.

Цифровые продукты грубы

Программы часто обвиняют пользователя в ошибках, в которых нет (или не должно быть) его вины. Сообщения об ошибках вроде приведенного на рис. 1.2 выскакивают, словно черт из табакерки, чтобы еще и еще раз возвестить пользователю о его промахе. Вдобавок эти сообщения требуют, чтобы пользователь непременно согласился со своим провалом, щелкнув по кнопке ОК.


Цифровым продуктам необходимы более качественные методы проектирования 37






Внимание! Не удалось уведомить библиотеку.


Рис. 1.2. Замечательно, спасибо за откровенность. Почему программа не уведомила библиотеку? О чем она хотела уведомить эту библиотеку? Почему она говорит об этом нам? С чем мы вообще соглашаемся? С какой стати сбой в программе - это «ОК»?

Программы часто допрашивают пользователя, засыпая его маловразумительными вопросами, на которые пользователь не готов или не склонен отвечать: «Куда ты подевал этот файл?» Снисходительные вопросы, вроде «Вы уверены?» и «Вы действительно хотите удалить этот файл или нажали на клавишу Delete по другой причине?», равно унизительны и неприятны.

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

Цифровые продукты навязывают людям компьютерный стиль мышления

Цифровые продукты сплошь и рядом подразумевают, что пользователь технически грамотен. К примеру, пользователь Microsoft Word, желающий переименовать текущий документ, должен знать, что потребуется либо закрыть файл, либо воспользоваться командой меню Сохранить как... (не забыв при этом удалить файл с прежним именем). Такое поведение не согласуется с тем, как обычный человек представляет себе переименование чего бы то ни было; напротив, подразумевается, что человек должен начать мыслить в логике, соответствующей принципам работы компьютера.

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


38 Глава 1. Проектирование, ориентированное на цели

вателей («Сколько стоповых битов?»), а иногда и для специалистов («Пожалуйста, укажите IRQ»).

Цифровые продукты ведут себя неподобающим образом

Если бы десятилетний ребенок вел себя так же, как некоторые программы или устройства, его бы заперли в детской и оставили без ужина. Программы забывают закрывать за собой дверь холодильника, оставляют ботинки на ковре посреди комнаты и не способны вспомнить то, что вы говорили им каких-то пять минут назад. К примеру, если вы сохраните документ Microsoft Word, распечатаете его, а затем попытаетесь закрыть, программа снова спросит, желаете ли вы сохранить документ! Очевидно, печать документа заставила программу думать, что документ изменился, хотя этого не произошло. «Не, мам, я тебя не слышал!»

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

Цифровые продукты заставляют человека делать рутинную работу

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

Почему эти продукты столь плохи?

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

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

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

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

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

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

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

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

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

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

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

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

41


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

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

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

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

Сознательное включение проектирования в процесс создания продуктов возвестило о восхождении современной триады задач разработки, озвученных Ларри Кили (Larry Keeley) из Дублинской группы: осуществимость, жизнеспособность, желанность (рис. 1.3). Если один из этих трех столпов значительно слабее двух других, продукт вряд ли выдержит испытание временем.

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


42

1   2   3   4   5   6   7   8   9   ...   31



Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
100-bal.ru
Поиск