Продолжая начатую в статье Алексея Павленко «Шаровары наших дней» тему, перейдем к рассмотрению самого животрепещущего вопроса, с которым постоянно сталкиваются отечественные разработчики ПО, а именно — вопроса пользовательского интерфейса. Нехватка «юзабилити» — одна из самых острых проблем современных российских программ. Мы уже научились делать качественные, быстрые и надежные продукты, но пока не научились делать их удобными для пользователя. В не меньшей, если не большей мере то же относится и к Web-разработкам. Каковы же основные ошибки, совершаемые разработчиками, и как с ними бороться?

Сергей Scout Кащавцев

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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