Четырежды не адекватен

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

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

1. Интерфейс не адекватен особенностям пользователей.

2. Интерфейс не адекватен среде использования системы.

3. Интерфейс не адекватен содержательной деятельности пользователей.

4. Интерфейс неадекватно отображает объекты системы и связи между ними.

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

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

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

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

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

1. Навыки работы с компьютером. Хорошим критерием здесь является стаж работы с компьютером.

2. Знание предметной области. Как правило, это наиболее трудная часть, поскольку пользователи у любой системы различны. Кроме того, на этапе проектирования системы разработчики зачастую сами не обладают знанием предметной области. Этот пункт списка должен содержать, к примеру, следующие ответы: каков у пользователя опыт работы с подобными системами, каково знание терминологии, какова способность обучаться и так далее.

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

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

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

Помимо адекватности особенностям пользователей, интерфейс должен быть адекватным среде, в которой используется система. Основные составляющие этой среды таковы:

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

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

3. Разрешение мониторов. На работу оказывает влияние не только разрешение экрана в пикселях, но и его физический размер: если физическое разрешение велико, элементы управления становятся слишком маленькими и неразборчивыми. И если система разрабатывается без учета этого фактора, велика вероятность появления так называемой «проблемы режима Large Fonts» (рис. 1).

   Рис. 1. Если интерфейс программы не был разработан в расчете на возможное включение режима Large Fonts, все элементы управления «поплывут». Хорошо еще, если ни один элемент не исчезнет, будучи закрыт другим.

4. Скорость работы самой системы. К сожалению, разработчики слишком часто рассматривают скорость работы как второстепенный фактор. Безусловно, во многих случаях быстродействие может быть принесено в жертву ради другой характеристики системы, но в некоторых ситуациях именно оно является наиболее важным фактором. Например, если пользователи ожидают высокой скорости работы (к счастью, они ожидают ее нечасто), медленная система станет источником значительного субъективного неудовлетворения. Другой пример: нередко в автоматических системах есть операции, выполняемые пользователем во время разговора по телефону (таковы многие операции у брокеров, операторов складов и др.). Если подобная операция будет занимать долгое время, проблем разработчику не избежать.

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

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

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

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

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

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

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

1. Взаимное расположение объектов на экране не соответствует их логической связи и/или их важности.

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

2. В интерфейсе много избыточности. Если заранее неизвестно, как именно пользователи будут работать с системой (а узнать это невозможно без тестирования прототипа интерфейса), у разработчиков возникает искушение многократно дублировать средства вызова объектов (например, дать возможность перейти к одному и тому же экрану несколькими разными способами) в расчете на то, что обилие этих средств поможет пользователю найти хотя бы одно. Это приводит к тому, что пользователь, найдя какой-либо метод, вынужден впоследствии отфильтровывать все остальные - вследствие чего в интерфейсе возникает шум. В некоторых случаях проявляется и другая проблема: пользователь фиксируется на первом найденном методе и игнорирует все остальные, даже если они более эффективны. Таким образом, избыточность, как правило, снижает эффективность интерфейса.

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

4. Интерфейс разрабатывается без учета сложившихся стандартов (частный случай предыдущей проблемы).

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

Выводы

Приведенная выше типология проблем, частично совпадая с другими подобными типологиями (например, из стандартов ISO), значительно от них отличается: мы не ставили перед собой задачи охватить весь возможный круг проблем, но лишь обозначили самые типичные из них, характерные для программных продуктов, разрабатываемых в России. Таким образом, предложенная типология носит сугубо практический характер: используя ее, разработчики смогут заранее диагностировать и исправлять возможные (и вероятные) проблемы при проектировании пользовательского интерфейса систем.