♦ За словом «удобный», по моему глубокому убеждению, чаще всего скрывается «не требующий совершать большое количество непроизводительных действий», т. е. неудобный — это трудоёмкий.[33] Похоже, что слово «трудоемкость» просто отсутствует в активном словарном запасе большинства людей, так что выражать своё мнение им приходится через слово «неудобный». Это мнение я составил на основе большого количества интервью с пользователями на протяжении ряда лет. В подавляющем большинстве случаев, когда потребители оценивали интерфейс как неудобный, глубокое интервью позволяло детектировать раздражение, вызванное большим количеством действий, не направленных напрямую на достижение результата (например, пользователи должны были снова и снова открывать один и тот же документ). В этом смысле очень важна проверка получившегося интерфейса на лишние или непродуктивные операции.
Проверяйте на оправданность все интерфейсные операции, удаляйте необязательные и исправляйте слишком уж трудоемкие.
Реклама, как известно, двигатель торговли. Насколько бы не был хорош продукт, его, по всей видимости, всё равно будут рекламировать, не дожидаясь того времени, когда потребители сами поймут его достоинства. В этом смысле интерфейс становится лучше, если делать его, в том числе, и в расчёте на будущую рекламу. Существуют как минимум два способа сделать продукт более «рекламировабильным»:
♦ «Формулировабельность» улучшений. Маркетингу требуются улучшения, которые можно легко объяснить несколькими словами. Поэтому не стоит заниматься работой по улучшению, которую вы сами не можете кратко охарактеризовать. Особая трудность, если делается новый продукт, который придется сравнивать не с прежней версией, а с конкурентами — некоторые вещи говорить о конкурентах неэтично (например, нельзя написать в рекламе, что «все остальные продукты — говно полное, а наш продукт — неполное»). Соответственно, чисто практически, перед началом всякой новой работы (например, закончив оптимизацию меню и переходя к оптимизации горячих клавиш) надо просто тратить четверть часа на то, чтобы написать, чем интерфейс станет от этой работы лучше. Если описание такого улучшения получилось больше пятнадцати слов или есть подозрение, что оно будет понятно только другим разработчикам, работу лучше отложить, а вместо неё заняться чем-либо другим, что описывается лучше. Полезно также спросить маркетинг (если он есть), поможет ли им это улучшение. Если нет — грош цена такой работе. Буквально.
♦ Картинка для прессы. Это не так важно для сайтов, но очень важно для ПО: значительная часть продаж обусловлена публикациями в прессе, редакторы же постоянно мучаются поиском изобразительного материала. На практике, программа, у которой есть несколько красивых скриншотов, получает благодаря этому значительную фору — именно её скриншоты будут использованы в обзорах и других публикациях. К сожалению, привлекательность скриншотов имеет мало общего с красотой интерфейса — пользователи видят интерфейс в реальном размере и в динамике, а читатели прессы — в статике и в придачу в уменьшенном виде. Например, можно вбухать прорву времени в красивейшие тенюшечки и волшебнейшую анимацию — но ни то ни другое на скриншоте увидеть будет невозможно. Соответственно, работая над интерфейсом, нужно просто выделить некоторое время на то, чтобы сделать несколько экранов, выгодно смотрящихся на скриншотах.[34]
Многие продукты продаются не своим будущим пользователям. Например, веб-интерфейс для почты выбирает администратор, а пользуются ей все. Можно сделать интерфейс для всех, но нет никакой гарантии, что он автоматически понравится администратору. Непродуктивно и обратное — интерфейс, любезный сердцу администратора, вряд ли будет приятен пользователям. В таких ситуациях всегда есть (во многом этическая) дилемма — для кого делать продукт. Общего решения этой дилеммы нет, но надо постоянно помнить о том, что, потратив время на оптимизацию для всех, нужно выделить время и на оптимизацию для администратора — и обратно. Слишком уж часто я видел (часто на самом себе), как при планировании работы забывали о том, что интерфейс в таких случаях имеет две стороны, и в результате успевали улучшить только что-то одно.
Есть ещё одна причина считать, что коммерческий успех является самой важной характеристикой качества интерфейса. Работа на коммерческий успех, по-видимому, наиболее этична для дизайнера. Если продукт с разработанным дизайнером интерфейсом будет плохо (читай — недостаточно хорошо) продаваться по вине дизайнера, это проблема для всех. Для заказчика — потому что он заплатил дизайнеру денег в расчёте заработать на этой инвестиции. Для пользователей, поскольку если продукт будет неуспешен:
♦ Не появится шанса сделать продукт лучше в следующей версии. Или ещё лучше.
♦ Не появится шанса, что продукт улучшит чью-то жизнь. Например, неважно, насколько хорошо лечит вполне лечащее лекарство, если вы его не купили. У вас его попросту нет.
♦ Количество продуктов вообще сократится, т. е. сократится и выбор потребителей. Это может показаться очень сомнительным утверждением — но надо помнить, что большинство новых продуктов создаются предпринимателями, которые уже вывели в свет какой-то продукт, а теперь инвестируют заработанные деньги и своё освободившееся время в новый бизнес. Чтобы это произошло, предыдущий продукт должен быть удачным, т. е. продаваться. Т. е. провалившийся продукт не позволяет появиться на свет другим продуктам.
Я много раз встречался с утверждением, что дизайнер интерфейсов это, дескать, «защитник пользователей», что дизайнер интерфейсов должен любить пользователей больше, чем себя, и защищать их от гнусных поползновений заказчиков. На мой взгляд, это очень сомнительная установка. Улучшать жизнь потребителей — это, прежде всего, дело самого предпринимателя. Именно за это он берет с потребителей деньги. Дизайнер же берет деньги не с потребителей, а с предпринимателя; соответственно, работать он должен именно что на предпринимателя. Кроме того, работающий по найму дизайнер рискует значительно меньшим, чем предприниматель, соответственно, он заведомо меньше вовлечен в процесс.
Кроме того, результаты установки на то, что «я делаю хороший интерфейс» несколько отличаются от результатов установки «я собираюсь осчастливить заказчика, разработав для него хороший интерфейс». В первом случае в проекте происходит слишком много трения. Из школьных уроков физики мы можем вспомнить, что трение замедляет движение и вызывает повышение температуры. Нужно оно вам?
Вы делаете довольным заказчика, для чего вам нужно сделать хороший интерфейс для пользователей.
Как использовать все эти знания?
Наконец, самое главное. Теперь вы знаете, что такое хороший интерфейс — осталось научиться применять это знание на практике. Это не так уж трудно. Всего-то нужно:
♦ Перед началом разработки в явной форме записать, какие эргономические характеристики важны для этого конкретного интерфейса. А в конце разработки проверить, выполнена ли поставленная задача; если нет — продолжать работу, если да — переходить к чему-то другому.
♦ Методически задавать себе заранее заготовленные вопросы в определенной последовательности.
Вопросы эти приходят из перечисленных мной ранее концепций качества интерфейсов. Например, из концепции показателей Шнейдермана приходят первые три:
1 Можно ли ускорить взаимодействие пользователя с этим интерфейсом?
2 Где в этом интерфейсе места, которые могут продуцировать человеческие ошибки? Можно ли изменить эти фрагменты?
3 Что в этом интерфейсе не способствует обучению? Что пользователю нужно знать, чтобы успешно взаимодействовать с этим интерфейсом? Есть лив этом перечне что-то, чего сам интерфейс не сообщает пользователю?
Эти три вопроса нужно задавать себе по очереди. Если после ответов видно, что интерфейс надо менять, остальные вопросы нужно задать себе снова после переделки. Если на все три вопроса удалось дать отрицательный ответ, переходим к следующей порции вопросов из остальных концепций качества:
4 Известно ли мне о пользователях что-нибудь, что делает этот интерфейс плохим?
5 Удовлетворяет ли этот интерфейс все известные мне мотивы пользователей?
б Совместим ли этот интерфейс со средой, в которой работают пользователи?
7 Если и по этим вопросам всё хорошо, переходим к проверке, как выполняются в интерфейсе задачи пользователей. Соответственно, этот вопрос звучит как «Есть ли задачи, которые неэффективно отрабатываются интерфейсом?». Как правило, достаточно проговорить вслух (а ещё лучше написать), как в этом интерфейсе пользователь выполняет все свои задачи (лучше всего писать о себе, а не о абстрактном пользователе, например «Из меню Документ я открываю окно настроек зета-преобразования, ввожу значение 40 в поле Количество человеков, затем открываю…»). Как правило, такая проверка выявляет множество несоответствий или попросту пропущенных кусков.
Если это произошло, возвращаемся к самому первому вопросу. Если нет, задаем себе последний вопрос:
8 Сексуален ли этот интерфейс и можно ли его сделать ещё сексуальнее?
Как видите, вопросов всего восемь и в них нет ничего особо страшного.[35] Есть только одна хитрость: у любого продукта много функций и, соответственно, цельных «кусков» интерфейса.
Например, у обычного Блокнота из Windows — на что уж малюсенькая программулька — пять уникальных функций, не считая стандартной функциональности программ Windows: