Многопрофильные команды разработки

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

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

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

Программисты-проектировщики

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

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

В случае если вы занимаетесь программированием на профессиональном уровне, вы остаетесь программистом вне зависимости от того, каковы ваши способности в обучении, тестировании или проектировании. Как нельзя быть чуть-чуть беременной, так нельзя быть и чуть-чуть программистом.

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

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

Откуда вам это известно?

Многим юзабилити-специалистам свойственно полагать, что все удобство программы оценить невозможно, пока не будут проведены соответствующие тесты. Оттого они постоянно задают вопрос: «Откуда вам это известно?» Но тут я заметил одну очень любопытную вещь: задавая этот вопрос, они не стремятся изобразить адвоката дьявола, а спрашивают лишь потому, что не в состоянии отличить, является ли данное взаимодействие спроектированным качественно.

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

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

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

Если просто ответить «Не знаю», такой вариант могут принять, а вот попытки угадать будут обречены на провал. Хуже того, стоит вам начать гадать, глядя в сторону, программисты – те, кто кровно заинтересован в процессе, – спишут вас со счетов, как шарлатана, не удостоив и словом.

Руководства по стилю

В 1980-е годы дизайнер Шелли Ивенсон и ученый Джон Райнфран плотно сотрудничали на базе исследовательского центра компании Xerox в Пало-Альто, и это взаимодействие положило начало некоторым важным идеям из области визуальных коммуникаций. Результатом стало создание совместимого визуального словаря, который получил название «язык визуального дизайна» и применялся для всех фотокопировальных устройств Xerox: зеленым цветом на аппаратах обозначалась область для загрузки оригиналов документов, синим – область загрузки чистой бумаги, красным – область выдачи копий документов и обслуживания устройств. Аналогичные нетекстовые подсказки оказываются достаточно полезными в интерфейсах с высоким уровнем когнитивного сопротивления и описываются в документах, называемых «руководствами по стилю», которые представляют собой сборники с примерами и предложениями по использованию того или иного стилевого оформления.

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

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

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

Если бы Билл Гейтс публично потребовал от всех компаний, кроме Microsoft, прекратить внедрять проектирование взаимодействия, все они просто освистали бы его и выгнали со сцены. Тем не менее руководство по стилю интерфейсов Microsoft (Microsoft UI Style Guide) делает именно это, и притом является одним из самых сильных конкурентных преимуществ Microsoft в индустрии.

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

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

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

Между тем самим разработчикам платформенных решений позволено проводить эксперименты, развиваться и внедрять инновации, сколько им будет угодно. Собственными руководствами по стилям они вольны пренебрегать. Конечно же, никто столь часто и таким возмутительным образом не нарушает предписания в этих руководствах, как те же Microsoft и Apple.

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

Фокус-группы

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

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

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

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

Визуальное проектирование

В книге «Алан Купер об интерфейсе. Основы проектирования взаимодействия» я продемонстрировал, что графический пользовательский интерфейс (Graphical User Interface, GUI) стал преобладающим способом взаимодействия с компьютером далеко не из-за своей графической природы. Новые графические интерфейсы возобладали над предшествовавшими им зелеными экранами скорее благодаря жестко ограниченному набору возможных взаимодействий, на основе которого они и были созданы. Хорошее визуальное проектирование, безусловно, может значительно повлиять на качество любого интерфейса, но многие специалисты индустрии по-прежнему наделяют его той ценностью, которой оно на самом деле не обладает.

Как-то мне довелось быть в составе жюри в конкурсе по проектированию и конструированию прикладных программ для внутреннего пользования в компаниях^[37]. Одним из победителей стала программа для управления продажей билетов, созданная для ежегодного съезда авиалюбителей в Висконсине. Сердцем этой системы был кассовый терминал – устройство, намеренно лишенное графического интерфейса. В нем был лишь текстовый дисплей, обладавший особой прочностью, простотой и легкостью в восприятии информации для пользователя. Тем не менее программа совершенно справедливо оказалась в числе лидеров, потому что в процессе проектирования разработчики тщательно исследовали специфические потребности группы добровольцев, задействованных в продаже билетов на съезде. Работа этих добровольцев была критически важной, но вместе с тем простой, ее требовалось выполнять очень быстро и с минимумом подготовки. Графические интерфейсы невероятно хороши в тех случаях, когда руководители хотят видеть полную картину положения дел в компании, но операторы кассовых терминалов не нуждаются в этом, потому что каждый следующий покупатель в очереди не имеет ничего общего с другими покупателями. Так что отображение всей картины в целом не входило в задачи программы. Установки простейшего текстового дисплея было вполне достаточно, чтобы продукт мог стать обладателем награды. Однако многие практикующие специалисты упускают этот урок из виду.

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

Программа на изображении ниже по сути своей представляет собой бесполезную мишуру с приятным глазу интерфейсом, выдаваемую вместе с новыми компьютерами совершенно бесплатно, что, в общем-то, и определяет ее ценность. Кажется, она нужна для телефонной связи, а может, для запуска CD-ROM – я точно не знаю. Ее интерфейс, бесспорно, может показаться вам красивым, в особенности если вы технофил с любовью ко всяческим гаджетам, однако совершенно невозможно постичь, как им пользоваться. Такие примеры мы называем «приукрасить мертвеца». Разработчики взяли интерфейс, которым невозможно пользоваться из-за глубинных изъянов поведенческого проектирования, и облачили его в обольстительные одежды.

 

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

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