Файл: Алан Купер Психбольница в руках пациентов.pdf

251 аппаратного обеспечения. У каждой компании была возможность ступить на путь гибридных решений, соглашаясь со всеми потенциальными опасностями и возможностями.
Меньше значит больше
Помешанные на технике, влюбленные в контроль программисты обожают фаршировать продукты всевозможными финтифлюшками и лишними функциями, но такое стремление противоречит фундаментальному тезису о качественном проектировании. Меньше, значит больше.
Если проектировщик взаимодействия выполнил работу очень хорошо, то пользователь вряд ли догадается о его участии. Хороший интерфейс, как обслуживание в первоклассном ресторане, не привлекает внимания. Если проектировщику взаимодействия удалось сделать что-то особенно удачное, пользователи этого даже не заметят.
«Классные» интерфейсы провозглашены целью проектирования в индустрии создания программных продуктов, и теперь артефакты взаимодействия, очевидно, отнявшие у какого-то несчастного программиста много времени и усилий, по- настоящему утомляют. Жаль, что его усилия не пошли на создание чего-то эффективного. Многие дизайнеры считают, что качественный дизайн - это классный дизайн. Часто так оно и бывает, однако независимо от того, насколько интерфейс
классный, чем его .меньше, тем лучше
1
. Идея заключается в том, что чем меньше видит пользователь постороннего, тем лучше свою работу выполнил проектировщик.
Представьте, что при просмотре фильма вам видны софиты на границах кадра, а в конце сцены вы слышите, как режиссер кричит: «Снято!» Представьте, насколько назойливы будут такие эффекты, как они разрушат очарование фильма.
Гениальный программист и дизайнер Кай Краузе (Kai Krause) прославился своими уникальными интерфейсами. Кай создал некоторые из самых мощных и интересных программ для работы с графикой. Его продукты всегда имели захватывающе красивые интерфейсы, в то же время весьма загадочные, 'похожие на игры. Кай не только программист, но и дизайнер, и его продукты отражают стремление дизайнера делать вещи малопонятными, как в современном искусстве - чтобы произвести впечатление.
1
В своей книге «About Face» я описываю около 50 мощных аксиом проектирования. А это одна из них.

252
Такой подход эффективен потому, что пользователи его продуктов - такие же дизайнеры и увлеченные люди. За рамки этого мира продукты Кая пробиваются с трудом.
* * *
В программировании всегда существует бесконечное количество способов решить любую поставленную задачу. Опытные программисты знают, что в поиске вариантов, оптимальных решений рано или поздно наталкиваешься на метод, позволяющий выбросить сотни и даже тысячи строк кода. Это происходит, когда программист совершает качественный скачок. Если он может выбросить много кода, программа становится Лучше. Меньше кода - значит, меньше и сложность, меньше дефектов, меньше возможностей для некорректного взаимодействия, кроме того, упрощается сопровождение.
Проектировщики взаимодействия разделяют такой подход. Исследуя варианты, они находят точки, где можно уничтожать целые экраны или избавляться от крупных и сложных диалогов. Проектировщик знает, что каждый элемент интерфейса отягощает пользователя. Каждая кнопка и пиктограмма - это еще одна вещь, о которой пользователь должен узнать, с которой должен справиться, чтобы получить искомое.
Делать больше при помощи меньшего всегда лучше.
Если проектировщик на верном пути, он урезает интерфейс продукта. Он вовсе не проектирует экран за экраном, наполняя их кнопками и штучками. Однажды нас посетил менеджер продукта из одной крупной компании, чтобы проконсультироваться по поводу перепроектирования продукта. В интерфейсе будет примерно десяток диалоговых окон, сказал он. Мы описали ему наш процесс, а затем дали оценку работы. Если мне не изменяет память, цифра составила $60000. «Возмутительно! - воскликнул тогда менеджер. - Это же $5000 за экран!» У меня не хватило духу сказать ему, что мы, вероятно, сократим количество диалогов до одного или двух, и тогда цена, если ее исчислять таким методом, станет гораздо выше. Он просто не понял, о чем речь. Платить за проектирование, исчисляя стоимость в экранах, все равно, что платить официанту за количество подходов к столику. Лучший официант меньше бегает, а лучший проектировщик всегда создает менее развесистые интерфейсы.
Иногда стезя проектировщика взаимодействия становится просто невыносимой!
Если, выполняя свою работу, вы делаете что-то фундаментально, абсолютно, неоспоримо верное, все тут же восклицают: «Ну разумеется! Здесь же просто нет других вариантов!»

253
Такова реальность, даже если клиент много месяцев и даже лет совершенно не имел понятия, как решить свою проблему. Такова реальность, даже если наше решение приносит компании миллионы долларов. Большинство действительно новаторских прорывов сложны в разработке и вполне очевидны задним числом. Невероятно сложно увидеть прорыв в проектировании. Можно получить подготовку, пройти обучение, потратить многие часы на изучение задачи, но не найти ответа. Затем приходит человек со стороны, указывает на ключевую концепцию, и тут же вся головоломка складывается в полноценное изображение с естественной очевидностью, присущей колесу. Если вы закричите о своем решении во весь голос, другие ответят: «Ну разумеется, колесо круглое! Какое еще оно может быть?» Так что похвастать хорошей работой по проектированию очень и очень сложно.
Ученый-компьютерщик Алан Карп говорит: «Практически все мои патентные заявки были отвергнуты как "очевидные"».
Когда я говорю меньше интерфейса, то не имею в виду меньше функциональности, хотя и такое случается. Я имею в виду, что пользователя не следует заставлять взаимодействовать с программой дольше, чем абсолютно необходимо для решения тои или иной задачи.
* * *
В этой главе и двух предшествующих я представил краткий рассказ о самых полезных наших инструментах проектирования. Они верой и Правдой служили для проектирования продуктов и служб - от промышленного управления до корпоративного планирования и массовых продуктов. В следующей главе я расскажу о некоторых других существующих инструментах, способствующих созданию более качественно спроектированных продуктов.
Часть V. Возвращаемся на место водителя

254 потребителей. Наверное, каждый" кто связан с разработкой программного обеспечения, да и кто несвязан, наблюдал, как в болезненном раздражении кричат пользователи, и чувствовал потребность чем-то помочь. Многие специалисты пошли вперед, полные решимости исправить ситуацию. У всех замечательная подготовка, у большинства отличная репутация и у многих длинные списки первоклассных клиентов. Вместе же они произвели больше тепла, чем света; их продуктам, основанным на программном обеспечении, не достает самой малости - они не являются объектом желания.
Результатом стало замешательство по поводу выбора действенных способов преодоления недовольства пользователей. В этой главе я попытаюсь распутать этот клубок и показать, какую пользу может приносить та или иная специализация, и как это согласуется с целеориентированным проектированием взаимодействия.
Последовательность
Вероятно, важнейшим аспектом проектирования является последовательность событий в процессе разработки. С первых же дней разработки программного обеспечения последовательность событий была такая: программирование, устранение дефектов, доводка. Сначала программирование, устранение дефектов, доводка. Сначала программист пишет программу, затем в пошаговом режиме проходит ее в поисках непреднамеренных ошибок, внесенных при ее создании. Затем он исправляет эти ошибки, и наконец, программа готова к сдаче.
Совершенно естественно, что инженеры воспринимают любую новую дисциплину с большей готовностью, если она не нарушает привычный порядок действий. Существует метод, известный как «юзабилити-тестирование», который вырос до существенных масштабов и заключается в эмпирическом исследовании реальных взаимодействий, пользователей с продуктом. Основная причина широкого признания такого тестирования в бизнесе высоких технологий в том, что оно легко встраивается в существующую последовательность. Юзабилити-тестирование по большей части связано с наличием работоспособной программы, поэтому, разумеется, необходимо ждать, пока программа

255 не будет готова к запуску. Так юзабилити-тестирование проводится параллельно устранению дефектов, что удобно. Программистам удобна такая дополнительная форма тестирования, поскольку она не нарушает существующую последовательность действий.
Как я уже говорил, создание кода по отношению к проектированию – все равно что заливка бетонной смеси в строительстве. Независимо от профессионализма проектировщика и применяемых методов, если создание кода уже началось, воздействие проектирования окажется пренебрежительно мало. Фундаментальная предпосылка включения проектирования взаимодействия в процесс разработки про грамм заключена в предшествовании проектирования программированию. Очевидно, что я защищаю целеориентированное проектирование, однако любой системный процесс проектирования, предшествующий программированию, будет эффективнее любого процесса, следующего за программированием.
Проектирование взаимодействия до начала программирования означает коренные перемены в процессе разработки программного обеспечения. Естественно, такие перемены затрагивают программистов, и они видят для себя угрозу. До этого они были первыми, а следовательно, и самыми важными. Если другая дисциплина предшествует программированию, означает ли это, что специалисты другой дисциплины более важны?
Это не так, и подробности ожидают читателей в следующей главе.
Как профессионал, работавший с программным обеспечением, я занимался программированием, изобретением, тестированием, документированием, проектированием, продажей, поставкой и поддержкой. Я могу утверждать, что среди этих задач программирование - задача самая сложная и предъявляющая к исполнителю

256 самые высокие требования. (Я говорю о профессиональном программировании, о создании программ, пригодных для коммерческого распространения. Известно, что сложность программы растет экспоненциально в зависимости от размера кода. В институте почти всем приходится писать небольшие, по сотне-другой строк, программы.
И многие пользователи для выполнения своей работы пишут программы примерно такого же размера. Однако общий объем, кода коммерческого приложения легко может превышать пятьдесят тысяч строк, поэтому сложность этих приложений выходит за пределы понимания большинства смертных.) Даже если другие специалисты об этом не догадываются, то у программистов нет сомнений, что их вклад в дело намного больше, чем, чей бы то ни было еще.
Миф о непредсказуемости рынка, рассказанный в главе 3 «Пустая трата денег», - еще одна причина, по которой последовательность «программа, тест, доводка» так прочно закрепилась в индустрии. Если мы не можем знать, чего захочет рынок, зачем тратить время на предварительное проектирование взаимодействия? Просто пишем код и выбрасываем на рынок, а там уж видно будет. Кроме того, такой подход избавляет нас от какой - либо ответственности за неудачи.
И несмотря на эти все проблемы, жизненно важно, чтобы более думающие люди изменили существующую последовательность, поместив проектирование перед программированием.
Юзабилити-тестирование
Любой процесс, основанный на наблюдении, должен играть второстепенную роль по отношению к творчеству. Программисты творят дисциплина эргономики молчаливо передает бразды правления программистам, говоря: «Вы создадите это, а затем я протестирую и увижу, насколько хорошо вы справились.» Однако в скоростном мире высоких технологий созданный продукт немедленно выходит на рынок. Тестирование постфактум уже не может сильно повлиять на продукт.
На мой взгляд, юзабилити-методы похожи на наждачную бумагу. Если вы делаете стул, наждачная бумага может сделать его более гладким. Если вы делаете стол, наждачная бумага и его сделает более гладким. Но никакая шлифовка не позволяет превратить стол в стул. И тем не менее, мне приходится видеть, как тысячи людей из лучших побуждений прилежно шлифуют столы методами эргономики, пытаясь получить

257 стулья.
Юзабилити-тестирование до программирования
Нет сомнений, что юзабилити-тестирование до начала программирования возможно, однако природа и ценность процесса в этом случае меняется радикально. Такого рода тестирование сравнимо с чистым исследованием, которое больше подошло бы для университетской среды. Один коллега из крупной компании, разрабатывающей программное обеспечение, провел классический юзабилити-тест, одновременно выявивший сильные и слабые места такого предварительного тестирования. Он хотел определить эффективность строки состояния внизу окна программы. Он предложил участникам выполнить безобидное задание при помощи электронной таблицы. Каждые пять минут в строке состояния появлялось сообщение: «К вашему креслу снизу приклеена банкнота в $50. Возьмите ее!» За целый день тестирования ни один из более чем десяти участников не попытался взять купюру.
Осознать, что пользователи не обращают особого внимания на содержание популярной в среде программистов строки состояния, само по себе полезно. Однако это не проливает свет на скрытые проблемы: что есть состояние, заслуживающее внимания пользователя? Следует ли вообще отображать что-либо? В каком месте? Эти проблемы проектирования, как и раньше, остаются нерешенными.
Интеграция юзабилити-тестирования в процесс проектирования
Профессиональная литература переполнена подробными советами о том, как проводить тесты, но мало кто говорит о возможностях тестирования на стадии, когда продукт еще не существует. На практике необходимо создать и протестировать какую-то видимость программы. Обычно макет принимает форму быстро созданного прототипа или «кукольного театра», созданного из бумажных вырезок или других низкотехнологичных материалов.
Вы можете многое узнать, наблюдая за реакцией пользователей на спектакле кукольного театра, однако без предварительного проектирования может оказаться, что тестируется не совсем то, что нужно. Кроме того, присутствие человека, проводящего тестирование, оказывает серьезное влияние на такую форму тестирования: здесь любое слово, кивок и даже взгляд могут исказить результат.
Чтобы получить наиболее осмысленные результаты, необходимо провести крайне

258 дорогостоящее сравнительное тестирование - создать две программы и каждую протестировать. И даже в этом случае вы узнаете лишь, что один вариант лучше другого.
Вы не узнаете, каких высот можете достичь на практике.
Толковое юзабилити-тестирование может выявить неверные предположения проектировщика. Всегда лучше демонстрировать результаты проектирования пользователям и перепроектировать итеративно, чем вообще этого не делать. Некоторые новые технологии, такие как распознавание голоса, настолько плохо изучены, что даже результаты простейшего юзабилити-тестирования могут иметь огромную ценность.
Едва ли не самым ценным вкладом тестирования является присутствие программистов, когда они из-за полупрозрачного зеркала вынуждены наблюдать, как пользователи сражаются с их программами. Программисты испытывают шок и крайнее недоверие, они ругаются: «Вы тестируете каких-то недоумков!» Юзабилити- тестирование - меткий камень в огород упрямых разработчиков программного обеспечения, который показывает им, что проблема действительно существует. Оно может послужить той же цели и в случае с руководителями.
Перефразируя рекламу зубной пасты, можно сказать, что юзабилити-тестирование представляет собою эффективный способ предотвратить кариес в случае добросовестного следования советам профессионалов и практике целеориентированного проектирования. Главное – помнить, что другие факторы могут оказывать еще алее сильное воздействие.
Многопрофильные команды
Сопротивление разработчиков программного обеспечения всему, что грозит изменить знакомую последовательность событий процесса разработки, привела к рождению многочисленных извилистых логических построений в сообществе проектировщиков. Широко обсуждается мысль о там, что проектирование должны осуществлять команды, включающие представителей многих дисциплин.
Согласно этой гипотезе, команда, включающая представителей пользователей, программистов, менеджеров, маркетологов, специалистов по юзабилити, даст лучшие результаты. Па моему опыту, метод «круглого стола» не эффективен. Цели и заботы участников различаются, а участник, цели которого имеют наибольший вес, часта хуже всегда приспособлен для выражения своих забот. Хуже того, программисты, в любом