Четырежды неадекватен. Типичные проблемы интерфейса отечественного ПО и методы их предотвращения

Александр Белышкин, 15.03.2002

Типичные проблемы интерфейса отечественного ПО и методы их предотвращения.

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

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

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

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

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

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

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

  • Навыки использования компьютера. Хорошим критерием здесь является период времени, в течение которого они пользуются компьютером.
  • Знание предметной области. Как правило, это наиболее трудная часть, поскольку пользователи у любой системы различны. Кроме того, на этапе проектирования системы, разработчики зачастую ещё не обладают знаниям предметной области. В список должны входить ответы на такие, например, вопросы: каков предыдущий опыт использования подобных систем пользователями, каково знание пользователями терминологии, какова способность пользователей обучаться и т.п.
  • Ожидания от системы. Если проектируемая система уже не первая для пользователей, поначалу её отличия от конкурентов (например, от предыдущей версии) будут восприняты по большей части негативно, поскольку пользователям не нравится переучиваться (разумеется, это не касается давно ожидавшейся функциональности). Поэтому часто разумно выбрать не самое эффективное решение, но привычное и не требующее переучивания.
  • Физические параметры пользователей. В зависимости от возраста и от некоторых других факторов, физические параметры людей изменяются в довольно широких пределах. Например, интерфейс ПО, рассчитанного на пожилых людей, должен быть более визуально контрастным, чем такой же интерфейс для людей молодых, поскольку с возрастом зрение значительно слабеет.

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

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

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

  • Временные ограничения на выполнение действия. Если заранее известно, что определенная операция должна выполняться быстро и/или не замедлять другие операции, интерфейс этой операции нужно проектировать в первую очередь рассчитывая на ограничения скорости. Если не определить заранее, какая характеристика интерфейса наиболее важна в каждом конкретном случае, вероятность достижения характеристики будет невелика — фактически, удовлетворить требования к скорости можно будет только случайно.
  • Наличие прерываний в деятельности пользователей. Работа со многими системами подразумевает, что пользователи постоянно будут отвлекаться (например, пользователь системы управления проектом не пользуется системой всё время; большую часть времени он работает над самим проектом, обращаясь к системе лишь время от времени). В таких случаях интерфейс должен помогать пользователю вернуться к работе с системой: например, показывать пользователю, что именно изменилось за время его отсутствия.
  • Разрешение мониторов. На работу с системой оказывает влияние не только размер экрана в пикселях, но и физический размер экрана: если физическое разрешение велико, элементы управления становятся слишком малы и неразборчивы. Если система разрабатывается без оглядки на это разрешение, велика вероятность появления так называемой «проблемы режима Large Fonts».
  • Если интерфейс программы не был разработан в расчете на возможное включение режима Large Fonts, все элементы управления «поплывут». Хорошо ещё, если ни один элемент не исчезнет, перекрытый другим.
  • Скорость работы самой системы. Слишком часто, к сожалению, разработчики рассматривают скорость работы системы как фактор, легко терпящий компромиссы. Безусловно, во многих случаях скорость работы может быть принесена в жертву ради другой характеристики системы, но в некоторых ситуациях скорость работы является наиболее важным фактором. Например, если пользователи ожидают высокую скорость работы (к счастью, они ожидают её нечасто), медленно работающая система станет источником значительного субъективного неудовлетворения. Другой пример: во многих системах автоматизации есть операции, выполняемые пользователем во время разговора по телефону (таковы многие операции у брокеров, операторов складов и др.). Если такая операция будет занимать долгое время, проблем разработчику не избежать.

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

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

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

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

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

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

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

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

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

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

  • Взаимное размещение объектов на экране не совпадает с их логической связью и/или с их важностью. К сожалению, нормой является ситуация, при которой наиболее важные объекты (и, соответственно, наиболее важные действия) либо заслоняются от пользователя менее важными, либо находятся там, где пользователь не ожидает их найти. Например, нам известна программа, выполняющая только одну функцию, при этом вызвать эту функцию можно только из меню или с помощью пиктограммы на панели инструментов (при этом нужная пиктограмма не снабжена подписью и теряется на фоне других пиктограмм панели). Если бы кнопка для вызова этой функции была размещена ближе к центру окна программы, была сразу заметна и снабжена однозначной подписью, простота вызова функции увеличилась бы на порядок.
  • В интерфейсе много избыточности. Если заранее неизвестно, как именно пользователи будут работать с системой (а это не может быть известно без тестирования прототипа интерфейса), у разработчиков возникает искушение многократно дублировать средства вызова объектов (например, вызвать один и тот же экран можно несколькими разными способами) в расчете, что если этих средств будет много, пользователь найдет хотя бы одно. Это приводит к тому, что пользователь, найдя какое-либо средство, вынужден впоследствии отфильтровывать все остальные (т.е. в интерфейсе возникает шум). В некоторых случаях возникает ещё и другая проблема: пользователь фиксируется на первом найденном объекте и игнорирует все остальные, даже если они более эффективны. Таким образом, чаще всего избыточность снижает эффективность интерфейса.
  • Разные части системы разрабатываются разными разработчиками без согласования друг с другом. Эта проблема также очень остро стоит в нашей стране. Очень мало команд разработчиков обладает внутренними стандартами на интерфейс, а без таких стандартов организационно невозможно побудить разработчиков придерживаться одинаковых правил при создании интерфейса.
  • Интерфейс разрабатывается без учета сложившихся стандартов (частный случай предыдущей проблемы). Эта проблема не очень остро стоит в традиционном ПО, но очень остро — в интернете, где стандартов почти нет.

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

Выводы

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

Изначально опубликовано в журнале Компьютерра (7/2002).

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.