Интерфейс отражает внутреннюю структуру реализации и мышление программистов
Зачастую разработчики, в особенности небольшие компании, в которых экономят на таких специалистов как юзабилити-эксперт (а в российских фирмах на них экономят всегда), совершенно не задумываются, что пользоваться программой будут люди не знакомые с ее внутренней структурой. Как следствие с конвейера выходят программы совершенно неудобные в использовании, в структуру которых необходимо долго вникать
Программирование - очень сильно ориентированный на функции процесс, поэтому пользовательский интерфейс часто создается подобным образом. Например, некоторые разработчики считают, что каждую функцию нужно помещать в отдельное диалоговое окно. Для достижения множества целей пользователю необходима целая серия функций. Если в программе используется одно окно для одной функции, экран быстро становится визуально загроможденным.
Опуская тот момент, что меню здесь жутко загромождено во-первых разделителями, а во-вторых - пунктами меню - разделителями (помеченными "======"), следует обратить внимание на структуру программы. Она построена в соответствии со структурой организации, а не в соответствии с порядком использования информации.
Такой элемент управления используется в основном в приложениях, работающих с базами данных, и служит для перемещения по записям. Во-первых, этот элемент понятен только программистам. Большинство пользователей не имеют никакого представления о базе данных, таблице (в понимании таблицы с данными) и записях в таблице. Они не знают, что можно "двигаться по записям", и что есть конец и начало записей. Это терминология программиста. Во-вторых, такой элемент управления заставляет пользователя "блуждать в темноте" - в большинстве программ, где он используется, на экране видна одновременно только вся информация об одной "записи", и никакой информации, что стоит за ней, а что перед ней. Более того, люди редко просматривают информацию в такой последовательности вообще (а в данном случае порядок представления информации еще и задается положением записей в таблице ). Чаще всего люди выбирают информацию из списка на экране по какому-то одному критерию (например, фамилия). Предоставление всей информации, которая есть для ориентации бесполезно - пользователь только теряется. И, наконец, элемент навязывает пользователю, что данные расположены как-то горизонтально, хотя физически у них нет направления.
Выводы
Интерфейс программы необходимо разрабатывать еще на стадии проектирования всего ПП. Важно смоделировать пользовательские роли и сценарии и затем по ним тестировать спроектированный интерфейс. Это поможет избежать глобальных проблем структуры программы.
наверх к оглавлению
От пользователя постоянно требуется дополнительная информация
Нормой в отечественных программах является создание ситуаций, в которых пользователь должен ввести информацию, которую может ввести за него программа. Также повсеместно распространена практика, когда пользователь должен вводить информацию которую он уже когда-то вводил.
Зачастую вопросы, которые задает система, могут просто поставить пользователя в тупик и надолго заморозить его работу, из-за того, что пользователь просто не обладает той информацией, что запрашивает система, либо чтобы найти эту информацию нужно время
Это сообщение возникает при удалении справочника в программе АРМ Секретарь. Мало того, что программа пугает пользователя непонятными для него терминами (база данных), она еще и спрашивает у него самого, что ей с этим делать.
Подобное окно появляется в переводчике Promt при попытке открыть файл с целью перевести его. В нем предлагается выбрать формат открываемого файла. Совершенно не понятно, почему программ сама не может определить формат открываемого файла, перекладывая эту задачу на пользователя, тем самым, провоцируя к созданию ошибочной ситуации.
Такой тирадой сообщений засыпает пользователя программа 1С. Ни о какой комфортной работе при таком количестве сообщений не может быть и речи.
Выводы
Прежде всего, необходимо так проектировать систему, чтобы она, основываясь на информации, которая у нее уже есть, принимала решение сама. Если система не обладает 100% достоверной информацией, она должна принимать решения, основываясь на самом высоковероятном, либо сразу предоставлять пользователю выбор из наиболее вероятных действий.
наверх к оглавлению
Отсутствует единый стиль
Целостность - одно из важных свойств интерфейса. Целостность облегчает обучение новых пользователей и повышает производительность опытных.
Например, регулярное расположение кнопок (и других элементов интерфейса) оправдывает ожидания пользователя - ему не приходится тратить усилия на поиск и распознавание кнопок. Кроме того, существуют правила оптимизации перемещений курсора мыши, которым рекомендуется следовать при размещении элементов управления пользовательского интерфейса.
Явный пример отсутствия целостности
Примеры управляющих кнопок, собранные со всей программы. Много говорить здесь не надо - о какой целостности интерфейса может вообще идти речь?
Выводы
Необходимо соблюдать хотя бы элементарные требования к целостности: кнопки в диалоговых окнах должны располагаться на одном и том же месте в одном и том же порядке, подписи к полям должны быть сделаны одним шрифтом, одна и та же функция встречающаяся в разных местах программы должна называться одинаково и т.д.
наверх к оглавлению
Пиктограммы используются некорректно
Несколько непонятный заголовок этого раздела объясняется тем, что проблем у пиктограмм много и проблемы совершенно противоположны друг другу. В одних случаях применяются излишне детализованные пиктограммы, в других случаях сюжет настолько прост, что может обозначать что угодно. В одних случаях пиктограмм слишком много, в других слишком мало.
Вообще, если обобщить, то анализируя российское программное обеспечение (да и не российское тоже) создается впечатление, что используют пиктограммы только с одной целью: "чтоб красивее было". Тем не менее грамотное и самое главное умеренное использование пиктограмм, продуманность из сюжета может положительно сказаться на таких критериях как: высокая скорость обучения пользователя, субъективная удовлетворенность и производительность.
Пример избыточной детализации пиктограмм. Например, зачем нужен зеленый значок на папке с документами? Или к чему рисовать содержимое корзины, когда метафора самой корзины и так легко узнаваема?
Пример пиктограмм выдержанных в единой стилистике. Во второй строчке оригинальные пиктограммы программы, в первой строчке стандартные Windows пиктограммы (открыть, сохранить, поместить в буфер и т.д.), адаптированные под стилистику программы. Плюсы - хорошо для брэндинга, минусы - уменьшается скорость распознавания - уж слишком пиктограммы похожи друг на друга.
Для запуска проверки на вирусы в Dr.WEB неудачно использована метафора светофора. Красная она потому, что в данный момент пользователь не выбрал ни один элемент для сканирования. Но как пользователь догадается, что нужно сделать, чтобы она стала зеленой? Список доступных дисков для сканирования не подает никакого сигнала о том, что эти диски можно выбрать. А красный цвет на кнопке "отпугивает" пользователя от ее нажатия. Некорректное использование метафоры заключается в том, что здесь индикатор совмещен с элементом управления (кнопкой). Тогда как в реальной жизни светофор сам меняет свое состояние.
Пример не очень качественных и не очень понятных пиктограмм (пиктограммы не подбирались, а взяты скопом из одной панели). Одинаковая форма, незначительные различия в расцветке и полное отсутствие аналогии с предметами реального мира делают задачу запоминания этих пиктограмм практически невозможным.
Выводы
Рекомендации тут банальны. Прежде всего, пиктограмм не должно быть очень много как в панели инструментов, так и в меню. Второй момент, сюжет пиктограмм должен быть простым, легко узнаваем и самое главное однозначно ассоциирован. Чтобы пиктограммы хорошо смотрелись их лучше делать в одной стилистике, но при этом стараться чтобы они отличались друг от друга (либо цветом, либо формой элементов, либо еще каким-нибудь внешними характеристиками).
Программа имеет многодокументный интерфейс
Практически все отечественные ПП, в которых обрабатываются какие-нибудь текстовые или табличные данные, используют многодокументный (MDI) интерфейс: много документов - одно окно, в то время как в мире уже признали его неэффективность и возвращаются к однодокументному интерфейсу (SDI): один документ - одно окно.
Сам по себе этот стиль интерфейса может оказаться полезным только в исключительных случаях, так как он по своей природе заставляет пользователя манипулировать окнами, вместо того, чтобы позволять ему делать свое дело. Пользователю приходится ворочать массу бессистемно открытых и неупорядоченных окон, что явно скажется на эффективности его работы не в лучшую сторону. Такой бессистемный подход может запросто привести к ситуации, когда очередное открытое окно будет просто "потеряно" или надолго оставлено без внимания в мешанине открытых окон.
Выводы
Для программ, которые работают с разными типами документов решение этой проблемы - разработка набора так называемых рабочих областей (workspaces), то есть экранов, в каждом из которых сосредоточены необходимые функции для решения той или иной задачи пользователя (простейший пример такого приложения - Outlook Express). Для этого необходим тщательный анализ деятельности пользователей программы, включения всего комплекса эргономических работ в процесс проектирования ПО.
наверх к оглавлению
Программа не готова к немедленной работе и требуют настройки
Это проблема особенно характерно для бухгалтерских программ. Зачастую оказывается, что покупка собственно софта и установка его на рабочие места - лишь малая часть всех затрат по работам, связанным с автоматизацией бухгалтерского учёта, это всего лишь вершина айсберга. Оказывается, в придачу к коробке с программой фирме ещё надо покупать специально обученного программиста. Многие пользователи не подозревают об этом, приобретая и устанавливая ПО.
Недостатки использования такого решения следующие:
Фирма-разработчик перенесла часть своих затрат на приведение своего продукта в готовый вид на своих клиентов. Теперь они несут дополнительные, и часто значительные затраты на начальную настройку и сопровождение с помощью дополнительных людских ресурсов - "настройщиков". Вследствие практически полной настраиваемости внешнего вида программы, конечный интерфейс для пользователя очень сильно зависит от тех самых "настройщиков", которые уж точно не являются специалистами по интерфейсам. Таким образом, пользовательский интерфейс, который должен быть спроектирован специалистами, "настраивается и конфигурируется" пользователями или "настройщиками". В результате неадекватно "настроенного" интерфейса страдают как сами пользователи, так и эффективность их работы.
Выводы
Вероятнее всего, решение этой проблемы лежит где-то в области разработки более конкретных настроек. Например такую программу как 1С:Предприятие можно спроектировать для специфических организаций ("Завод", "Школа", "Магазин", "Торговая фирма" и т.д), что сведет настройки к минимуму. Что касается интерфейса, то здесь следует, по крайней мере, постоянно работать над качеством в готовых настройках, дабы конечные "настройщики" использовали его в качестве образца. Высшим пилотажем было бы задание типовых интерфейсных стилей или шаблонов
наверх к оглавлению
Программа перегружена элементами управления
Эту проблему без преувеличения можно назвать наиболее типичной для российского программного обеспечения. Суть проблемы заключается в том, что структура пользовательского интерфейса приведена в соответствие с информационными потоками (структурой объектов) внутри самой системы, а не в соответствие со структурой реальной деятельности пользователей.
Как следствие, интерфейс "зашумлен" информацией, релевантной объекту, с которым работает пользователь, но либо не нужной ему сейчас, либо не нужной ему вообще, поскольку разным сотрудникам нужна разная информация
Так при оптимизации интерфейса большой системы был проведен анализ одного из диалогов запроса данных. В общей сложности, в этом окне было 15 полей ввода и 6 чекбоксов. Как показал анализ интервью пользователей, в работе постоянно нужны только два поля ввода и два чекбокса, ещё одно поле ввода нужно изредка. Таким образом, экран содержал пятнадцать ненужных элементов управления, при этом основные элементы даже не были расположены в первых рядах, на них не позиционировался курсор, они никак не были выделены. Более того, большинство пользователей не могло ответить на вопрос, что означают некоторые из имеющихся полей.
Примера перегруженного интерфейса программа для агентств недвижимости Flat. Разработчикам следовало бы разбить это окно как минимум на два. В первом разместить параметры, которые в первую очередь влияют на выбор квартиры. Вторую сделать как окно с дополнительными (второстепенными) параметрами, которые можно просмотреть в том случае если жилье заинтересовало и необходимо сделать выбор между несколькими вариантами.
Также примером перегруженного интерфейса можно назвать интерфейс 1С.Ни в одной другой программе вы не найдете такого количества интерфейсных элементов как в 1С Предприятие. Опрос пользователей этой программы выявил следующие факты:
Считают программу сложной абсолютно все.
Никто из опрошенных не получает никакого удовольствия от работы с этой программой. Опять же из-за ее сложного интерфейса. Большая часть пользуется "необходимым минимуму" и даже не пытается расширять свои знания, считая изучение программы без помощи посторонних практически невозможным делом Многие считают что выполнили бы работу быстрее без программы.
Выводы
Проектируя систему, прежде всего, необходимо приводить структуру пользовательского интерфейса в соответствие со структурой реальной деятельности пользователей. Спроектированную систему необходимо тестировать, тогда будет точно ясно какая информация первостепенна для пользователей, а какую можно скрыть. Если от большого количества интерфейсных элементов никуда не уйти, необходимо группировать их, причем исходя их логики пользователя, которые будут пользоваться этим ПП. Часто используемые элементы и функции необходимо помещать на самые видные места, помещая на них фокус ввода или каким-нибудь образом отделяя их от второстепенных функций.
наверх к оглавлению
Программа перегружена окнами сообщений
Привычка при каждой неоднозначной ситуации выводить на экран диалоговое окно, наверное, еще долго будет влиять на создание интерфейсов отечественного ПО. В некоторых программах при закрытии окна документа пользователь может увидеть до 4-х сообщений, на каждое из которых ему придется ответить.
В программе Зарплата 2000 встречается пример неудачного использования диалоговых окон. Для расчета зарплаты запись о работнике нужно добавлять в расчетную ведомость. Если же запись об этом работнике уже есть, программа выдает 2 (!) сообщение подряд. Мало того что сообщение здесь излишне - программу можно реализовать так, что ситуация с внесением работника повторно может никогда не произойти, так еще оно разбито на два. А если у вас 100 сотрудников и пользователь нажмет кнопку Добавить всех (которая, кстати, присутствует в этой программе)? В результате ему придется 200 раз нажимать на кнопку Ok! Будете ли он делать это? Скорее всего просто закроет эту программу.
Пример бесполезного сообщения, которое появляется при некорректном открытия файла. Система сама предоставляет пользователю выбрать формат и сама же удивляется, если пользователь допускает ошибку. Тем более что вне зависимости от того, какую из кнопок нажмет пользователь, программа не производит никаких действий.
Еще одно бесполезное сообщение. Вместо того чтобы предложить пользователю варианты решения проблемы или самой догадаться о способе решения, система ограничивается бесполезным, а зачастую просто раздражающим сообщением.
Выводы
Прежде всего, систему необходимо проектировать таким образом, чтобы в ней отсутствовали такие ситуации, в которых пользователь может совершить какую-нибудь ошибку. Например, для ввода данным можно использовать интерфейсные элементы с жестко заданным диапазоном значений. Следующее что можно сделать это считать всю информацию, которую пользователь вводит в программу, верной по определению. Все сообщения должны быть протестированы на предмет их целесообразности. Большинство из сообщений о завершении какой-либо операции или сообщении о изменении состояния могут быть безболезненно убраны, остальные преобразованы в другие формы подачи сообщения: пузыри, индикаторы, подсветка и т.д.
наверх к оглавлению
Терминология не адекватна знаниям пользователя о системе
Так как программы пишут программисты, они часто забывают, что пользоваться ими будут обычные люди, которые не знакомы с их терминологией. Большинство людей в действительности толком не представляют себе что такое, например "база данных" или понятие "записи". Файлы и манипуляции с ними тоже сложны для пользователей.
Такая терминология пугает пользователей, в результате чего снижается эффективность их работы. Практически всегда в подобных случаях можно назвать вещи более понятными именами. Программа должна говорить с пользователями на их языке.
Прежде всего, это касается ПО для интернета, антивирусных и мультимедиа программ. Аудитория пользователей этих программ чрезвычайно широка, причем основную массу составляют как раз неопытные пользователи.
Окно популярной почтовой программы Bat.Для того чтобы начать получать/отправлять почту пользователю необходимо пройти через обязательную процедуру определения параметров получения и отправки почты. Начинающие пользователи в массе свое прибегают в этом случае к помощи более опытных знакомых ("спецов"). Хотя процедура не казалось бы такой сложной, если бы не профессиональная терминология, использованная при обозначении параметров. Прежде всего трудности возникают с серверами. Во-первых, большинство пользователей вообще смутно представляют себе что такое сервер, не говоря уже о том что они просто не знают что такое POP и SMTP. Все было бы проще, если бы поля ввода просто обозначались бы как "Адрес". В купе с помощью размещенной на самих почтовых серверах, это помогало бы пользователю заполнять эти поля "ритуально", без построения ментальной модели. Во-вторых, параметр Connection (не говоря уже о том, что он почему-то написан по-английски), можно убрать во вкладку "Дополнительные параметры", в которую должна быть переименована вкладка "Аутентификация" (еще один не понятный термин). Туда же необходимо поместить и значения портов. Как грамотно организовать вкладку "Дополнительные параметры" это уже отдельный разговор. Тем более, можно предположить, что уже в ней будут залезать, только "продвинутые" пользователи.
Выводы
Еще на начальной стадии проектирования системы необходимо составлять глоссарий используемых в системе терминов. Этот глоссарий должен отдаваться на рассмотрение потенциальным пользователям, которые должны указать, какие термины им непонятны и должны быть исправлены. После тестирования глоссария, необходимо тестировать саму систему на предмет понятности терминов в контексте программы.
наверх к оглавлению
Типичные интерфейсные ошибки отечественного ПО
Серьёзная эргономическая экспертиза программного продукта (usability testing) - дело нетривиальное и дорогое, проводится по специальным методикам и позволяет получить как качественные, так и количественные оценки эргономичности как программного продукта в целом, так и таких его важных компонент, как пользовательский интерфейс и пользовательская документация.
Не имея такой возможности - проводить серьёзное исследование, я попытаюсь лишь предоставить примеры эргономических проблем, возникающих при производстве программных продуктов. Таким образом, предлагаемый обзор является довольно поверхностным, так как используется эвристический метод оценки пользовательского интерфейса и эргономичности программ.
Итак, проблемы, как правило, бывают трёх типов:
Глобальные эргономические противоречия Неадекватное применение интерфейсной парадигмы Ошибки проектирования элементов пользовательского интерфейса (как целых форм, так и аспектов применения конкретных элементов управления).
Оказывается, что практически в любом мало-мальски сложном отечественном программном продукте эргономические проблемы всех трёх типов присутствуют в изобилии. Разберем их подробнее.
Программа перегружена элементами управления Терминология не адекватна знаниям пользователя о системе От пользователя постоянно требуется дополнительная информация Программа не готова к немедленной работе и требуют настройки
Программа имеет многодокументный интерфейс
Отсутствует единый стиль
Программа перегружена окнами сообщений Интерфейс отражает внутреннюю структуру реализации и мышление программистов Взаимное размещение объектов на экране не совпадает с их логической связью и/или с их важностью
Пиктограммы используются некорректно наверх к оглавлению
Взаимное размещение объектов на экране не совпадает с их логической связью и/или с их важностью
К сожалению, нормой является ситуация, при которой наиболее важные объекты (и, соответственно, наиболее важные действия) либо заслоняются от пользователя менее важными, либо находятся там, где пользователь не ожидает их найти. Например, типичный случай, когда программа, выполняющая только одну функцию, при этом вызвать эту функцию можно только из меню или с помощью пиктограммы на панели инструментов (при этом нужная пиктограмма не снабжена подписью и теряется на фоне других пиктограмм панели). Если бы кнопка для вызова этой функции была размещена ближе к центру окна программы, была сразу заметна и снабжена однозначной подписью, простота вызова функции увеличилась бы на порядок
Программа должна активно помогать организовывать эффективную работу пользователя. В большинстве случаев программа сама может вычислить объём работ и приоритетность выполнения заданий пользователем, и предложить список работ пользователю в виде меню, списка актуальных задач (task framework), требующих пользовательского труда.
Меню и панель инструментов переводчика PROMT. Упуская вопросы количества и понятности пиктограмм, следует отметить, что кнопка основной функции программы - перевода - никаким образом не доминирует над всем этим многообразием элементов управления.
Меню и панель инструментов программы распознавания текста FineReader. Не говоря уже о том, что количество пиктограмм на порядок меньше, а понятность их на порядок выше, триада основных функций программы - отсканировать, распознать, проверить - сразу бросается в глаза. Кнопки расположены именно там где пользователь и ожидает их найти. А расположение и обозначение кнопок в виде неделимой последовательности действий, сокращает время обучения практически до 0. Отличный интерфейс.
Еще один характерный пример. Цель этой программы одна - проигрывать видео. Так почему же кнопка Play одного размера и цвета с, к примеру, настройками видео. Первое, что видит пользователь открыв программу - полтора десятка невыразительных кнопок, а должен видеть только две - открыть и проиграть.
Выводы
В дизайне интерфейсов, как и в любом дизайне, необходимо уделять внимание "расстановке акцентов". Пользователь должен загружать программу и сразу понимать, что ему нужно сделать в первую очередь. Существует множество способов достижения этой цели и как правило хороший эффект достигается от применения всего комплекса мер по улучшения понятности интерфейса. Это и группировка элементов методом карточной сортировки, и умеренность в пиктограммах, и качество их прорисовки, и построение структуры программы в соответствии с представлениями пользователя, и многое-многое другое.
Для правильного построения пользовательского интерфейса, отражающего адекватный алгоритм деятельности пользователя, необходимы usability-исследования с привлечением конечных пользователей и экспертов. Такие сложные работы обычно принято проводить параллельно процессу проектирования ПО, начиная с ранних стадий проектирования.
наверх к оглавлению
