Дизайн пользовательского интерфейса. Искусство мыть слона

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

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

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

Например, будет невозможно:

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

♦ …понять, когда работа уже закончена и можно заняться чем-то другим. Слона можно мыть вечно, но зачем?

♦ …объяснить другим, что с интерфейсом надо делать то-то и то-то, а не это и это. Например, практика показывает, что нельзя объяснить заказчику, что этот интерфейс уже хорош и без красной кнопочки, если перед этим не договориться с ним о том, чего мы хотим достичь. Если вы моете слона, начальник слонария всегда будет иметь основания утверждать, что слон грязный.

Так что же это такое?!

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

Пока просто перечислю эти концепции (дальше будет более подробно). Интерфейс хорош, если он:

♦ «удобный», «простой» и «юзаб(и)(е)льный»

♦ обладает высокими эргономическими показателями;

♦ оптимизирован под своих пользователей;

♦ оптимизирован под задачи пользователей;

♦ оптимизирован под мотивы пользователей;

♦ обладает высокими показателями юзабилити;

♦ адекватен деятельности пользователей;

♦ коммерчески успешен.

Удобный, простой и «юзаб(и|е)льный»

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

Проблема в том, что никто не знает, что это такое, — уж больно растяжимые это понятия.

У слова «простой» есть ещё и та проблема, что простой интерфейс зачастую в принципе невозможен — у приборной панели пассажирского лайнера интерфейс будет посложнее, чем у мотодельтаплана, но это не делает его автоматически плохим.

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

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

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

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

Эргономические показатели

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

Такого рода систем показателей довольно много, но наиболее распространенными являются т. н. показатели Шнейдермана, согласно которым интерфейсы характеризуются:[20]

♦ скоростью работы пользователя

♦ количеством человеческих ошибок субъективной удовлетворенностью

♦ скоростью обучения навыкам оперирования интерфейсом

♦ степенью сохраняемости этих навыков при неиспользовании продукта.

Эти показатели очень полезны:

♦ Они предметны и точны. Гораздо проще сделать интерфейс, с которым работать быстрее, чем интерфейс, который «удобнее» — мысли не разбегаются, критерии четче. Тем более просто объяснить другим, что интерфейс стал быстрее, чем «удобнее».

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

В то же время у показателей Шнейдермана есть и недостатки:

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

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

♦ Скорость обучения навыкам оперирования сложно оценить и тем более сложно измерить. В результате этот показатель существует только номинально и почти не используется в практической работе. Ещё хуже дела у сохраняемости навыков оперирования. Мало того, что этот показатель практически невозможно проверить, так и его актуальность для многих проектов вообще стремится к нулю. Например, зачем этот показатель интерфейсу почтового клиента, если с соответствующим интерфейсом и так работают каждый день? В результате из пяти показателей остаются четыре.

♦ На практике из четырех показателей Шнейдермана почему-то можно добиться высоких показателей только по любым двум, отбрасывая два оставшихся (например, вытянуть скорость работы и количество операторских ошибок, но потерять в скорости обучения и удовлетворенности). Но из самой концепции непонятно, какие именно два показателя предпочесть в каждом конкретном случае. Например, можно прекрасно оптимизировать скорость работы пользователя, но потом окажется, что важнее была удовлетворенность (у меня однажды именно так и вышло).

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

Но достоинства показателей Шнейдермана всё-таки перевешивают недостатки. Простоту коммуникации с другими участниками проекта переоценить нельзя.

Дизайн, ориентированный на пользователей

Следующим подходом, как по сложности, так и по времени своего появления, является т. н. дизайн, ориентированный на пользователей (User Centered Design, далее ДОП). Его сущность кратко можно охарактеризовать следующим образом — если мы хорошо изучим нашу аудиторию и оптимизируем интерфейс под неё, наш интерфейс будет хорошим.

Отсюда два основных следствия ДОП:

♦ Отношение пользователей к интерфейсу является главным показателем качества интерфейса.

♦ Работа над интерфейсом невозможна без изучения особенностей аудитории, например, уровня начальной подготовки пользователей, их ожиданий, знаний предметной области и физиологических особенностей.[21]

Эти принципы действительно очень полезны:

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

♦ …пользователи могут отличаться и, как правило, действительно отличаются от разработчиков — и ДОП помогает об этом не забывать. Например, интерфейсы продуктов для детей разрабатывают взрослые, при этом очевидно, что интерфейсы для детей разных возрастных групп должны отличаться друг от друга и тем более от интерфейсов для взрослых.[22]

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

Учитывая это, неудивительно, что ДОП ещё недавно был основным подходом к проектированию. О его распространенности можно судить хотя бы по тому факту, что аббревиатура UCD (User Centered Design) до сих пор часто употребляется для обозначения дизайна интерфейсов вообще.

Но у дизайна, ориентированного на пользователей, есть и недостатки:

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

♦ ДОП не учитывает того простого факта, что человек — очень адаптивная система. Пользователи способны к адаптации в очень широких пределах. Например, я ни разу не видел кассира (а я интересовался вопросом), который бы ругал терминал, на котором он работает сейчас. Как правило, оценки варьируются от «намано» до «да хорошо всё». Но тот же кассир во время внедрения новой версии терминала будет верещать до посинения, потому что всё плохо. А через недели две — всё опять «намано». Как учитывать принципы ДОП в таких случаях? Ориентироваться на пользователя текущего, неадаптированного, или на уже адаптированного, но ещё не существующего?

♦ ДОП требует исследований. Эти исследования, по сути, являются этнографическими. В свою очередь, этнографические исследования почему-то всегда дороги и длительны, вдобавок, почему-то всегда более длительны и дороги, чем запланировано (вероятно, потому, что этнографическое исследование применительно к интерфейсу — это всегда «найди то, не знаю что»).[24] Поэтому включать в проектный цикл этнографическое исследование — верная гарантия того, что проект с управленческой точки зрения пойдет насмарку. Кроме того, до конца исследования совершенно непонятно, будет от него польза или нет, что депрессивно действует на всех участников проекта.

Суммируя, можно сказать, что ДОП негласно подразумевает: есть система (в частности — интерфейс) и есть её пользователи, которые и важны. Того, что делают пользователи в системе и ради чего они, собственно, с системой взаимодействуют, ДОП не покрывает. Зато его покрывает…

Дизайн, ориентированный на задачи пользователей

Когда имманентные проблемы ДОП стали несомненны, на смену старой концепции пришла новая. Согласно дизайну, ориентированному на задачи пользователей (Task Centered Design, далее ДОЗ), тот интерфейс хорош, в котором эффективно выполняются задачи пользователей.

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

Этот метод несколько лучше ДОП, просто потому что шире и включает в себя ДОП (правда, в неявной форме): в самом деле, как мы выберем наилучшее решение для пользователей, если мы не знаем всего об этих пользователях? Но ДОЗ обладает и другими достоинствами:

♦ В отличие от ДОП, цели и методы которого не имеют прямого коммерческого выражения, дизайн, ориентированный на задачи пользователей, может быть оценён экономически. Например, если мы делаем интерфейс кассового терминала быстрее, мы можем посчитать, насколько он стал выгоднее владельцу (нужно всего лишь посчитать полную себестоимость работы, которая высвободилась при улучшении).

♦ В отличие от потенциальных особенностей пользователей, число задач конечно и более предсказуемо при планировании. Благодаря этому проекты с ДОЗ значительно более управляемы, что очень приятно менеджменту.

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

Дизайн, ориентированный на мотивы пользователей

Преодолеть лавинообразный рост числа функций помогает другая концепция — дизайн, ориентированный на мотивы пользователей (Goal Centered Design, далее ДОМ; в отечественной практике его часто неправильно называют «дизайном, ориентированным на цели пользователей», переводя слово goal буквально). Согласно ДОМ, пользователи делают что-то для удовлетворения личных потребностей, иначе — мотивов; опознав эти потребности и сравнив их с задачами пользователей, мы получаем возможность лучше понять, что нужно делать.

Например, рассмотрим интерфейс программы-органайзера для секретарши. В настоящий момент она разговаривает по телефону с клиентом, который просит назначить встречу с её начальником на 10 утра пятницы. Что дают рассмотренные ранее концепции дизайнеру интерфейса для этой ситуации?

♦ Дизайн, ориентированный на задачи, в таких ситуациях ограничивается тем, что мы записываем в ТЗ, что «система должна поддерживать создание событий в календаре». Это очень хорошо; но для создания адекватного интерфейса этого явно недостаточно. Каким именно должен быть этот интерфейс? Непонятно.

♦ Показатели Шнейдермана тоже говорят немного. Очевидно, что этот интерфейс должен быть быстрым, продуцировать мало ошибок, быть простым в обучении и приятным. Но таким должен быть любой интерфейс!

♦ Дизайн, ориентированный на пользователей, может (а может и не, если во время исследования мы не обратили на это внимания) помочь, подсказав, что у секретарши такие длинные ногти, что она постоянно опечатывается при вводе с клавиатуры.[25]

♦ А вот дизайн, ориентированный на мотивы пользователей, может сказать очень много. У секретарши основной мотив действий — не получить по голове. Очевидно, что если интерфейс будет не очень быстрый, так что клиенту на телефоне придется подождать лишних пять секунд, по голове секретарша не получит, а если получит — то не сильно. А вот если она вместо 10 часов назначит встречу на 11, один или несколько прицельных ударов ей обеспечены. Таким образом, ДОМ помог опознать важнейшую целевую характеристику нашего интерфейса — безошибочность. Соответственно, результирующее ТЗ на интерфейс должно звучать примерно как «интерфейс должен продуцировать минимум человеческих ошибок и быть по возможности быстрым» (скорость обучения и удовлетворенность здесь, к сожалению, придется выкинуть, поскольку из четырех характеристик интерфейса хороших результатов можно добиться только по двум).

Этот пример показывает основную силу изучения и анализа мотивов пользователей: мотивы объясняют задачи. Благодаря ДОМ список задач из ДОЗ, в лучшем случае отранжированный по частотности, приобретает собственно глубину и конкретику. Именно по этой причине в настоящее время дизайн, ориентированный на мотивы пользователей, является наиболее распространенным подходом к целеполаганию в дизайне интерфейсов (во всяком случае, обсуждается он чаще всего).

Юзабилити

К сожалению, все эти подходы (показатели Шнейдермана, ДОП, ДОЗ и ДОМ) довольно фрагментарны, поскольку концентрируются только на каком-то одном аспекте интерфейса. Общий подход, включающий в себя все эти концепции, очень желателен хотя бы потому, что всегда есть шанс о чём-то забыть или что-то пропустить. Такой целостный подход существует — это юзабилити.

Наиболее часто используемое определение юзабилити (из стандарта ISO 9241-11) гласит, что:

В этой формулировке есть почти всё, что нужно для плодотворной работы дизайнера:

♦ …эффективности, трудоемкости и удовлетворенности… — базовые показатели качества интерфейса (иные, чем у Шнейдермана, впрочем; см. далее).

♦ …определенными пользователями… — внимание к аудитории, характерное для дизайна, ориентированного на пользователей.

♦ …целей/мотивов… — целеполагание из дизайна, ориентированного на задачи, и дизайна, ориентированного на мотивы пользователей (ISO 9241-11 не особо разделяет задачи и мотивы, сваливая их в одну кучу).

Т.е. в юзабилити-подходе есть все достоинства всех описанных мной ранее концепций, причем в придачу есть ещё кое-что, а именно среда (…при определенном контексте использования…).

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

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

♦ Ещё более важна чувствительность продукта к операторским ошибкам, хотя бы потому, что работать и одновременно слушать, что тебе говорят — тяжело, особенно если говорят тихо. То же самое соображение применимо, если известно, что в помещении шумно.

♦ Если известно, что пользователь разговаривает по обычному телефону, без специальной гарнитуры, интерфейс надо проектировать только под ввод одной рукой (либо мышь, либо клавиатура), поскольку другой рукой пользователь будет держать трубку.

Таких средовых особенностей может быть много, например, почти в любом проекте важны:

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

♦ наличие или отсутствие карательной системы в работе пользователя

♦ шумовой фон и другие стрессогенные факторы

♦ внешние требования к скорости работы

♦ частота отвлечений.

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

Таким образом, концепция юзабилити более плодотворна для работы, чем перечисленные ранее концепции — в ней есть всё, что было там, и даже немножко больше. Вдобавок у неё есть и другое достоинство — это международный, вполне официальный стандарт (Россия тоже член ISO, так что скоро стандарт ISO 9241-11 станет и российским тоже).

Есть, увы, и проблема — выбранные ISO базовые характеристики (эффективность, трудоемкость и удовлетворенность), на мой взгляд, просто чудовищны:

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

♦ Понять их невозможно, можно только запомнить. Я провел несколько дней, медитируя над их расшифровкой (в ISO 9241-11, помимо основного определения юзабилити, расшифровываются и все входящие в него понятия), и всё равно не могу сказать, что понимаю, что значит эффективность, а что — трудоемкость. Например, иногда мне кажется, что скорость работы пользователя это показатель эффективности, а иногда — что трудоемкости. У меня есть подозрение, что показатели специально выбраны такими, чтобы при желании в них можно было запихнуть всё что угодно (например, ту же степень утомления оператора при работе). Стандарт, который так легко растягивается, — гондон, а не стандарт.[26]

♦ В любом случае, выбирать названия базовых показателей сходными до неразличимости (в оригинале efficiency и effectiveness) — страшный удар в спину переводчиков. Это я перевожу их на русский как «эффективность и трудоемкость»; распространен также перевод как «эффективность и продуктивность». Если кто-то переведёт efficiency и effectiveness как «эффективность и эффектность» — он тоже будет прав и этот перевод будет ничем не хуже остальных (в том смысле, что он будет так же труден для понимания).

♦ В другом стандарте ISO (и ещё в одном стандарте IEEE) есть иные определения юзабилити. Кому верить, спрашивается?[27]

♦ В расшифровки понятий efficiency и effectiveness в ISO 9241-11 попали не только качества интерфейса, но и одна из особенностей продукта, а именно мощность — вероятно, стараясь интегрировать в понятие юзабилити проблематику дизайна, ориентированного на задачи пользователя, интегрировали и главную проблему ДОЗ, а именно ползучий рост функциональности. Уравняв по важности мощность продукта со скоростью работы пользователя, уравняли неуравнимое. Если скорость работы пользователя это безусловное интерфейсное благо (трудно придумать продукт, для успеха которого пользователи должны работать медленно), то мощность продукта является достоинством относительным. Есть продукты, которые можно и нужно делать маломощными (например, чтобы сохранить их дешевыми или сберечь простой интерфейс). Получается, что ISO 9241-11 постулирует, что мощность повышает юзабилити. Сходу могу придумать как минимум один пример-опровержение — сверхмощный раскладной нож о двадцати лезвиях с отверткой обладает худшим интерфейсом, чем обычный кухонный нож.

Суммируя, я рекомендую вам забыть об efficiency и effectiveness как о страшном сне. Гораздо лучше заменить их соответствующими показателями Шнейдермана, чтобы получилось:

Можно упростить ещё больше. Вместо загадочного «контекста использования» можно писать простое русское «среда»:

Если вам кажется это слишком смелым (как же, моська лает на Международную Организацию по Стандартизации), я вас ободрю. Я такой не единственный. Например, Якоб Нильсен, независимо разработавший точно такую же систему базовых показателей, что и Шнейдерман, вообще утверждает, что именно они и есть юзабилити.[28] Почему бы ему не поверить? В конце концов даже одного взгляда на фотографию Нильсена достаточно, чтобы убедиться, что он знает о юзабилити кое-что и даже больше.

Концепция деятельности

Однако даже такая модифицированная формулировка юзабилити всё равно имеет определенные ограничения.[29]

Во-первых, «Юзабилити — показатель…». Какое, собственно, значение этого показателя является необходимым и достаточным для каждого конкретного продукта? Когда уже можно прекращать мыть слона? Стандарт про это ничего не говорит.

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

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

Эти проблемы отнюдь не праздные. Например, Apple iPod, так, на минуточку, обладает низкой, по сравнению с конкурентами, мощностью и в придачу интерфейсом продуцирует огромное количество человеческих ошибок (из-за сверхчувствительного колеса управления). Но это ведь не мешает ему быть самым популярным плеером всех времен и народов! А его конкуренты, например, Creative, выпускающие мощные плееры с зачастую очень эффективными интерфейсами, плетутся в хвосте. Видно, что что-то не так с определением юзабилити, раз конкуренты, моющие слона правильно, уступают Apple, моющей слона не по теории. В чём тут дело?

В последнее время концепцией, позволяющей решать такие проблемы, всё чаще считают концепцию деятельности, ведущую своё происхождение от работ отечественных психологов Выготского, Рубинштейна и Леонтьева. По многим причинам я намеренно не собираюсь касаться её здесь (слишком уж широкая штука, я бы сузил), однако порекомендовать её я считаю необходимым. Тем более что узнать о ней очень многое вы можете самостоятельно, просто поискав в интернете термины «теория деятельности» или, ещё лучше, «activity theory».

Коммерческий успех

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

Этот изъян, по видимости, заключается в том, что эргономика рассматривает различные характеристики интерфейса как равно важные. Например, в концепции юзабилити показатели приводятся просто списком:

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

Таким образом, хороший интерфейс — это интерфейс, который нравится. Интерфейс, который всем хорош, но, тем не менее, не нравится, интегрально плох.[30]

Например, т. н. дизайнерская мебель славится низким удобством (не говоря уж о низкой практичности). Но её покупают; правда, по причинам, слабо связанным с удобством.

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

Сексуальность интерфейса трудно объяснить и аргументировать, но определить её наличие очень легко. Некоторые интерфейсы сексуальны, некоторые — нет. Даже не понимая, почему одни интерфейсы такие, а некоторые нет, мы легко можем понять, сексуален интерфейс или нет. Достаточно просто спросить себя: «Хочу я иметь этот интерфейс или нет?». Если нет, впереди ещё много работы.

Ранее я уже ругал слова «простой», «интуитивный» и «удобный» как критерии оценки интерфейса. Действительно, они слишком уж широки, растяжимы и субъективны, чтобы использовать их даже для коммуникации. Но с другой стороны — именно по этим двум характеристикам потребители первым делом будут оценивать продукт — и горе продукту, если он будет сочтен сложным и неудобным.[31]

Поэтому во время дизайна очень важно задавать себе два вопроса:

♦ Является ли получившийся интерфейс простым?

♦ Является ли получившийся интерфейс удобным?

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

♦ Есть веские основания считать, что под словом «простой» применительно к интерфейсам надо понимать уже знакомый или напоминающий что-то знакомое. Субъективная простота или сложность имеет мало отношения к объективной сложности; в момент первоначальной оценки пользователь, ещё не знающий интерфейса, может только сравнивать его с другими интерфейсами, которые ему уже знакомы.[32]

♦ За словом «удобный», по моему глубокому убеждению, чаще всего скрывается «не требующий совершать большое количество непроизводительных действий», т. е. неудобный — это трудоёмкий.[33] Похоже, что слово «трудоемкость» просто отсутствует в активном словарном запасе большинства людей, так что выражать своё мнение им приходится через слово «неудобный». Это мнение я составил на основе большого количества интервью с пользователями на протяжении ряда лет. В подавляющем большинстве случаев, когда потребители оценивали интерфейс как неудобный, глубокое интервью позволяло детектировать раздражение, вызванное большим количеством действий, не направленных напрямую на достижение результата (например, пользователи должны были снова и снова открывать один и тот же документ). В этом смысле очень важна проверка получившегося интерфейса на лишние или непродуктивные операции.

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

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

♦ Картинка для прессы. Это не так важно для сайтов, но очень важно для ПО: значительная часть продаж обусловлена публикациями в прессе, редакторы же постоянно мучаются поиском изобразительного материала. На практике, программа, у которой есть несколько красивых скриншотов, получает благодаря этому значительную фору — именно её скриншоты будут использованы в обзорах и других публикациях. К сожалению, привлекательность скриншотов имеет мало общего с красотой интерфейса — пользователи видят интерфейс в реальном размере и в динамике, а читатели прессы — в статике и в придачу в уменьшенном виде. Например, можно вбухать прорву времени в красивейшие тенюшечки и волшебнейшую анимацию — но ни то ни другое на скриншоте увидеть будет невозможно. Соответственно, работая над интерфейсом, нужно просто выделить некоторое время на то, чтобы сделать несколько экранов, выгодно смотрящихся на скриншотах.[34]

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

Есть ещё одна причина считать, что коммерческий успех является самой важной характеристикой качества интерфейса. Работа на коммерческий успех, по-видимому, наиболее этична для дизайнера. Если продукт с разработанным дизайнером интерфейсом будет плохо (читай — недостаточно хорошо) продаваться по вине дизайнера, это проблема для всех. Для заказчика — потому что он заплатил дизайнеру денег в расчёте заработать на этой инвестиции. Для пользователей, поскольку если продукт будет неуспешен:

♦ Не появится шанса сделать продукт лучше в следующей версии. Или ещё лучше.

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

♦ Количество продуктов вообще сократится, т. е. сократится и выбор потребителей. Это может показаться очень сомнительным утверждением — но надо помнить, что большинство новых продуктов создаются предпринимателями, которые уже вывели в свет какой-то продукт, а теперь инвестируют заработанные деньги и своё освободившееся время в новый бизнес. Чтобы это произошло, предыдущий продукт должен быть удачным, т. е. продаваться. Т. е. провалившийся продукт не позволяет появиться на свет другим продуктам.

Я много раз встречался с утверждением, что дизайнер интерфейсов это, дескать, «защитник пользователей», что дизайнер интерфейсов должен любить пользователей больше, чем себя, и защищать их от гнусных поползновений заказчиков. На мой взгляд, это очень сомнительная установка. Улучшать жизнь потребителей — это, прежде всего, дело самого предпринимателя. Именно за это он берет с потребителей деньги. Дизайнер же берет деньги не с потребителей, а с предпринимателя; соответственно, работать он должен именно что на предпринимателя. Кроме того, работающий по найму дизайнер рискует значительно меньшим, чем предприниматель, соответственно, он заведомо меньше вовлечен в процесс.

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

Как использовать все эти знания?

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

♦ Перед началом разработки в явной форме записать, какие эргономические характеристики важны для этого конкретного интерфейса. А в конце разработки проверить, выполнена ли поставленная задача; если нет — продолжать работу, если да — переходить к чему-то другому.

♦ Методически задавать себе заранее заготовленные вопросы в определенной последовательности.

Вопросы эти приходят из перечисленных мной ранее концепций качества интерфейсов. Например, из концепции показателей Шнейдермана приходят первые три:

1 Можно ли ускорить взаимодействие пользователя с этим интерфейсом?

2 Где в этом интерфейсе места, которые могут продуцировать человеческие ошибки? Можно ли изменить эти фрагменты?

3 Что в этом интерфейсе не способствует обучению? Что пользователю нужно знать, чтобы успешно взаимодействовать с этим интерфейсом? Есть лив этом перечне что-то, чего сам интерфейс не сообщает пользователю?

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

4 Известно ли мне о пользователях что-нибудь, что делает этот интерфейс плохим?

5 Удовлетворяет ли этот интерфейс все известные мне мотивы пользователей?

б Совместим ли этот интерфейс со средой, в которой работают пользователи?

7 Если и по этим вопросам всё хорошо, переходим к проверке, как выполняются в интерфейсе задачи пользователей. Соответственно, этот вопрос звучит как «Есть ли задачи, которые неэффективно отрабатываются интерфейсом?». Как правило, достаточно проговорить вслух (а ещё лучше написать), как в этом интерфейсе пользователь выполняет все свои задачи (лучше всего писать о себе, а не о абстрактном пользователе, например «Из меню Документ я открываю окно настроек зета-преобразования, ввожу значение 40 в поле Количество человеков, затем открываю…»). Как правило, такая проверка выявляет множество несоответствий или попросту пропущенных кусков.

Если это произошло, возвращаемся к самому первому вопросу. Если нет, задаем себе последний вопрос:

8 Сексуален ли этот интерфейс и можно ли его сделать ещё сексуальнее?

Как видите, вопросов всего восемь и в них нет ничего особо страшного.[35] Есть только одна хитрость: у любого продукта много функций и, соответственно, цельных «кусков» интерфейса.

Например, у обычного Блокнота из Windows — на что уж малюсенькая программулька — пять уникальных функций, не считая стандартной функциональности программ Windows:

♦ функция — вставка времени и даты

♦ функция — переход на строку по её номеру

♦ настройка — переносить ли слова на новую строку

♦ настройка — показывать или не показывать строку статуса окна

♦ настройки — как показывать текст (выбор шрифта, кегля и т. п.).

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

Проиллюстрирую эту методику на примере другой программы из поставки Windows — Калькулятор (только для обычного режима, разбор инженерного режима только удлинит изложение). Предположим, заказчик принес мне этот интерфейс и я должен его улучшить.

Оставим на совести локализаторов качество названия элемента.

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

Начнем с меню. Его единственным нестандартным элементом является переключатель «Количество цифр в группе». Если его включить, длинные числа будут делиться на части по три цифры. Начинаем задавать вопросы:

1 Можно ли ускорить взаимодействие пользователя с этим меню? — Нет.

2 Где в этом меню места, которые могут продуцировать человеческие ошибки? Можно ли изменить эти фрагменты? — Название пункта «Количество цифр в группе» затруднительно сделать совершенно понятным. Можно, конечно, переименовать его в «Разделять длинные числа на группы», но это очень длинно. Может быть, пункт стоит выкинуть из меню, включив деление по умолчанию?

3 Что в этом меню не способствует обучению? — Если выкинем элемент «Количество цифр в группе» — ничего.

4 Известно ли мне что-нибудь о пользователях, что делает это меню плохим? — Нет.

5 Удовлетворяет ли это меню все известные мне мотивы пользователей? — Да.

б Совместимо ли это меню со средой, в которой работают пользователи? — Да.

7 Проговариваем список всех задач, которые пользователь может решать с помощью меню. Вроде бы ничего проблематичного нет.

8 Сексуально ли это меню? — Нет, не сексуально. Стандартное вообще не может быть сексуальным. Но здесь это и не нужно.

Перейдем к показу вывода результата:

1 Можно ли ускорить взаимодействие пользователя с полем вывода? — Очевидно да, поскольку длинные числа медленно сканируются взглядом. Нужно включить режим разбиения длинных чисел по умолчанию.

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

3 Что в этом поле вывода не способствует обучению? — Вроде ничего.

4 Известно ли мне о пользователях что-нибудь, что делает это поле плохим? — Нет.

5 Удовлетворяет ли это поле вывода все известные мне мотивы пользователей? — Да.

б Совместимо ли это поле со средой, в которой работают пользователи? — На мониторах с большим количеством точек на дюйм (например, на многих современных ноутбуках) цифры могут быть настолько мелкими, что будут трудночитаемы. Стоит увеличить.

7 Проговариваем список всех задач, которые пользователь может решать с помощью блока показа результата. Вроде бы ничего проблематичного нет.

8 Сексуален ли этот интерфейс? — Нет, не сексуален, поскольку стандартен, но это ничего не стоит изменить: например, увеличить кегль у цифр или выбрать шрифт со специфическими цифрами. Или сделать и то и другое.

Закончим анализом панели с цифрами:

1 Можно ли ускорить взаимодействие пользователя с этой панелью? — Маловероятно.

2 Где в этой панели места, которые могут продуцировать человеческие ошибки? Можно ли изменить эти фрагменты? — Разборчивость кнопок умножения и вычитания (пиктограммы * и — ) не очень высока, что может продуцировать ошибки. Увеличить размер пиктограмм в кнопках арифметических операций.

3 Что в этой панели не способствует обучению? — Названия кнопок MC, MR, MS и M+ ничего не говорят пользователю, если он не знает их назначения. Это нормально для инженерной версии калькулятора, но неприемлемо для обычной. Стоит увеличить размер кнопок, чтобы в них влезли лучшие названия (или вообще отказаться от них, поскольку всё равно есть буфер обмена). То же, хоть и в меньшей степени, касается кнопки sqrt. Либо увеличить, либо снабдить пиктограммой квадратного корня. И опять — чем отличается кнопка С от кнопки СЕ? Может быть, эту СЕ можно внедрить в поле вывода результата?

4 Известно ли мне о пользователях что-нибудь, что делает этот интерфейс плохим? — Пользователи явно пользуются этим интерфейсом крайне спорадически (сложные вычисления всё равно придется делать в инженерной версии калькулятора, а для частого счета удобнее настоящий калькулятор с крупными клавишами, дающими тактильную обратную связь). Непотребные термины на кнопках из предыдущего пункта явно не подходят для вечно малоопытных пользователей.

5 Удовлетворяет ли этот интерфейс все известные мне мотивы пользователей? — Да.

6 Совместима ли эта панель со средой, в которой работают пользователи? — Нет; как минимум для новых мониторов с высоким разрешением и небольшим размером экрана он не подходит — слишком мелкие элементы управления (их размер оптимизировался во времена 15-дюймовых экранов на 800х600 пикселей).

7 Проговариваем список всех задач, которые пользователь может решать с помощью панели клавиш. Вроде бы ничего проблематичного нет.[36]

8 Сексуальна ли эта панель? — Нет, не сексуальна. Впрочем, непонятно, как это можно исправить.

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

Итак, в программе Калькулятор стоит, как минимум:

1 Показывать результаты вычислений разбитыми на группы цифр (317543 => 317 543) по умолчанию, убрав соответствующий элемент меню.

2 Увеличить размер цифр в поле результатов.

3 Увеличить разборчивость кнопок математических операций.

4 Прибить кнопки операций с памятью, но зато вставить кнопки для скобок и что-то сделать с кнопкой квадратного корня.

5 В идеале — при запуске спрашивать у ОС разрешение экрана и увеличивать размер всех элементов, если разрешение слишком велико.

б Реализовать показ промежуточных результатов калькуляции.

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

Для первой версии изменений — годится (но сделать можно ещё очень многое).

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

К сожалению, здесь есть интеллектуальная ловушка. То, что вы теперь знаете эти вопросы, ничему не помогает и ничему не способствует. Их знания недостаточно — их нужно задавать. Если вы не будете их себе задавать — вопросы никак вам не помогут. Чтобы это знание заработало, его нужно активно внедрять в свою проектную деятельность (как, собственно говоря, и любое другое знание).

А чтобы вам легче было их задавать, выполните несколько заданий для самопроверки. Самостоятельно пройдите весь цикл анализа для:

♦ Двух любых браузеров, например для IE и Opera.

♦ Двух любых программ просмотра и каталогизации изображений, например для ACDSee и Picasa.

♦ Двух любых информационных сайтов одной направленности, например для Gazeta.ru и Lenta.ru.