ISO 9241-110 — Принципы организации диалога
В настоящее время я получаю второе высшее образование по программе MSc Usability Engineering в Райн-Ваальском Университете Прикладных Наук (Германия).
Данная программа является единственной в Германии, полностью посвященной Usability и HCD. Кроме того, в качестве преподавателей как правило выступают Usability-эксперты, работающие на такие компании, как Samsung, Siemens, Wargaming, Porsche и другие. Более того, некоторые из преподавателей входят в рабочие группы по разработке стандартов ISO для Usability.
В этой и последующих статьях я планирую поделиться частью тех знаний, что получаю в рамках обучения.
Использования стандартов дает несколько существенных преимуществ: Экономия ресурсов — нет необходимости изобретать велосипед; Предсказуемый результат — концепции, используемые в стандартах, уже были множество раз опробованы на практике; Упрощение коммуникации — у всей команды есть единое видение и, самое важное, единый словарь терминов; Концептуальный взгляд — большинство стандартов не дают ответа на вопрос «Как делать?», вместо этого они фокусируются на «Почему?» и «Что принять во внимание?»; Совместимость — предполагается что стандарты ISO разных серий совместимы между собой; Простота «продажи» — вам будет проще донести свои идеи до руководства, если вы опираетесь на международные стандарты; Сертификация — актуально для таких стандартов как, ISO 9001. Все это звучит довольно банально. Пока не выясняется что большинство терминов и подходов в Usabillty не являются устоявшимися. То, что одни называют «affordances», другие зовут «signifiers». Многие методы имеют несколько названий. Многие концепции (например, концепция персоны) используются как придется. Таким образом, стандарты позволяют хоть как-то навести порядок в индустрии. Если говорить о стандарте ISO 9241–110 (принципы организации диалога), то он является частью стандарта ISO 9241 (Эргономика и взаимодействие человека с компьютером). Основными задачами стандарта ISO 9241–110 являются предоставление рекомендаций для анализа, разработки и оценки (тестирования) диалогов.При этом стандарт нацелен на предотвращение таких типичных ошибок в диалогах, как:
Дополнительные, ненужные шаги, не требующиеся для решения текущей задачи — пользователь регистрируется на бесплатном сайте и его просят ввести номер карты; Противоречивая информация в диалогах — пользователь уже час медитирует на надпись «осталась одна минута»; Недостаток информации в диалогах — GPS-навигатор не показывает ориентировочное время прибытия; Непредвиденный ответ интерактивной системы — как-то раз видел на сайте Microsoft «press log-out to log-in»; Неэффективное восстановление после ошибок — представьте MS Word без кнопки отмены последнего действия; Ограничения в навигации — пользователь собирается забронировать отель, он уже на этапе оплаты и тут он понимает, что хочет поменять даты. Пользователь хочет вернуться назад, но кнопки «назад» нет. Пользователь идет на другой сайт; Для решения задач стандарт предлагает использовать 7 принципов. Я буду использовать английские названия с указанием в скобках перевода из ГОСТа: Suitability for the task (применимость диалога для выполнения производственного задания); Conformity with user expectastions (соответствие ожиданиям пользователей); Self-descriptiveness (информативность); Suitability for learning (пригодность для обучения); Controllability (контролируемость); Error tollerance (устойчивость к ошибкам); Suitability for individualization (адаптируемость к индивидуальным особенностям пользователя). Наиболее важный принцип. Если вы сделали крутое приложение, но оно не решает задачи пользователя, то вы потеряли время.Согласно стандарту, диалог подходит для решения задачи, если позволяет пользователю успешно решить задачу с минимальными усилиями. Как узнать, в чем заключается задача пользователя — это тема отдельной статьи. Здесь мы считаем, что вы уже знаете, какие цели преследует ваш пользователь.
Рекомендации: Делайте типичные значения доступными по-умолчанию — если пользователь покупает билет на ж/д станции, будет разумно указать эту в качестве точки отправления; Только необходимые шаги и информация — вы разработали систему для умного дома. Каждый раз, когда кто-то забыл закрыть кран в доме, она шлет пользователю напоминание. Пользователь не хочет напоминание, просто закройте кран автоматически; Обеспечьте совместимость с физическими документами — если ваше приложение предполагает ввод некой информации из бумажного документа, седлайте так, чтобы поля в вашем продукте соответствовали по расположению и смыслу полям исходного документа. Согласно стандарту, ваше приложение должно соответствовать «контекстуальным нуждам пользователей и общепринятым соглашениям».Чтобы лучше понять смысл данной фразы, необходимо разобраться, что такое контекст. Согласно ISO 9241–11, контекст использования — это совокупность характеристик пользователей и их задач, а также организационной, технической и физической среды.
Очевидно, что ожидания пользователя-студента, который не спеша едет на пары, и ожидания сотрудника скорой помощи во время экстренного вызова, могут существенно различаться. Даже если они используют один и тот же планшетный компьютер. Соответственно, эти различия необходимо учитывать в дизайне.
Рекомендации:
Учитывайте опыт, знания и навыки пользователей — например, пожилые люди могут ожидать больший размер кнопок и текста в приложении; Используйте знакомые термины — у каждой отрасли есть свой сленг, учитывайте это при разработке; Сделайте ваш продукт целостным — если кнопка «ОК» зеленая, пусть она будет зеленой на всех экранах вашего приложения; Если вы собираетесь сделать что-то неожиданное для пользователя, заранее предупредите его об этом («после выполнения этого действия, следующая загрузка системы может занять около 1 часа»). Вытекает непосредственно из второго принципа. Пользователю всегда должно быть понятно, где он находится, почему он находится именно здесь, и что ему делать дальше.Рекомендации:
Предоставляйте информацию о текущем статусе — в большинстве компьютерных игр игрок всегда знает, когда он умер и не удивляется, что он не может прыгать или бегать; Предоставляйте обратную связь — если пользователь нажал кнопку, дайте ему понять, что ваша программа увидела это нажатие (при этом можно использовать различные виды обратной связи: звук, изменение формы и т.д.); Пользователи не читают мануалы — тестируйте ваш дизайн на реальных пользователях. Убедитесь, что пользователи понимают, что им делать; Поясняйте ваши ожидания — зачастую вы ожидаете от пользователя, чтобы он ввел ту или иную информацию в определенном формате (например, день-месяц-год). В этом случае рекомендуется явным образом дать подсказку о требуемом формате. Диалог должен поддерживать пользователя и облегчать обучение.Особенно важный принцип, если вы «изобретаете будущее» и ваш продукт не соответствует ожиданиям пользователей и не является информативным.
Рекомендации:
Объясняйте «правила игры» — хорошим примером является Kickstarter. Зная, что их продукт является новым, они постарались сделать все возможное, чтобы пользователь понял, что такое краудфандинг и как его осуществлять в рамках Kickstarter’а; Предоставляйте подходящую поддержку — думайте о том, в какой ситуации находится ваш пользователь, что он делает, что пытается достичь и какую помощь ожидает от диалога; Помните, что ваше пользователи не одинаковые — ваши пользователи могут обучаться с различной скорость, кому-то может быть ближе текст, кому-то картинки. Пользователь должен иметь возможность инициировать взаимодействие, а так же управлять взаимодействием.Рекомендации:
Предполагайте возможность прерывания — что если пользователь захотел прервать диалог? что если диалог был прерван внезапной перезагрузкой? Разрешите отмену действий — это касается как ctrl+z, так и возможности нажать кнопку назад, чтобы вернуться на предыдущий экран диалога; Думайте об устройствах ввода — что если пользователь использует клавиатуру и мышь? Если только клавиатуру? Если он управляет голосом? Если он использует профессиональный графический планшет? Пользователь должен иметь возможность достигнуть цель без (или с минимальным числом) корректировок.Рекомендации:
Помогите пользователю обнаруживать и избегать ошибки — например, подсвечивать красным поля с некорректным вводом; Предотвращайте «неожиданные» состояния системы — в идеале действия пользователя не должны приводить к нештатным состояниям системы или ее поломкам; Предоставляйте активную поддержку — в случае, если выявлена ошибка, сообщите пользователю о ней и опишите возможные пути решения. Очень спорный принцип, поэтому я его поставил последним.Классические рассуждения: мы сделали полностью настраиваемый интерфейс, поэтому нам не надо волноваться о Usability — пользователь сам знает, как ему удобнее. Звучит красиво, но есть два момента. По-первых, пользователь не знает ваш продукт так же хорошо, как вы. Во-вторых, ваш пользователь не является специалистом по эргономике и дизайну. Поэтому это именно ваша работа сделать удобный интерфейс.
Рекомендации:
Думайте о пользователях с физическими ограничениями — индивидуализация такого рода как правило идет диалогам на пользу; Позвольте пользователю выбрать язык — так же безопасная кастомизация. В заключение хочу сказать несколько слов об использовании стандарта.Во-первых, стандарт носит рекомендательный характер и его можно рассматривать как список чек-пойнтов для размышления. Например, если вы делаете интерфейс для МЧС, то, согласно стандарту, обдумайте возможность кастомизации интерфейса. Скорее всего, вы примите решение о нецелесообразности кастомизации ПО для экстренных ситуаций. Тем не менее, рекомендуется явно отразить это решение в рабочей документации.
Во-вторых, стандарт может использоваться не только при разработке новых решений, но и для проверки старых на соответствие.
Надеюсь, что данная статья показалась вам интересной и стоила потраченного времени. Напоследок короткий опрос.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
