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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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