Использование usability guidelines для повышения качества веб-разработок

Данная статья была создана по мотивам презентации, сделанной на конференции SQA Days. Впервые опубликованна на GUI.ru

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

Что следует понимать под юзабилити? Определение юзабилити приведено в стандарте ISO 9241-11 как степень эффективности, продуктивности и удовлетворенности, с которой продукт может использоваться определёнными пользователями для достижения определённых задач в определённом контексте.

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

Нет ничего удивительного в том, что подобная практика переносится на все, что создаёт человек, в том числе программное обеспечение и веб-сайты. Надо понимать, что никто не создаёт плохие системы специально. Даже самые опытные специалисты и крупные производители допускают ошибки.

Меняя парадигму разработки

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

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

Но как в дальнейшем придётся тем, кто будет с этой формой работать? Заполнение каждого поля происходит методом проб и ошибок, что становиться настоящим кошмаром для пользователей. Это приводит к неэффективной работе. Такая реализация остальных экранных форм в программе обязательно приведёт к жалобам на неудобства в работе и неприятию автоматизации. А это в свою очередь, может привести к провалу всего проекта по внедрению нового программного обеспечения. Чтобы изменить ситуацию, следует изменить парадигму мышления при разработке: лучше предотвращать появление ошибок, чем ограничиться мерами по их устранению.

Высокие показатели юзабилити продукта достигаются за счёт внедрения в разработку подхода UCD (User Centered Design или дизайн ориентированный на пользователя). Данный подход характеризуется активным вовлечением пользователя в процесс разработки для достижения понимания пользовательских требований и надлежащего распределения функций между пользователями и технологиями, а также итеративным характером подхода и его мультидисциплинарностью (ISO 13407). Практика User Centered Design позволяет сократить расходы на разработку и повышает эффективность продукта, как в бизнес отношении (дополнительная прибыль), так и в удовлетворенности пользователей (повышение лояльности к продукту и компании-разработчику). Такой подход применяется на всём жизненном цикле создания ПО и включает в себя: определение требований, анализ, проектирование, тестирование, оценку и последующую доработку интерфейса. На данный момент крупные компании, как западные (Microsoft, Google), так и российские (Билайн, РТС, 1С) внедряют практики UCD в свои процессы. Такой подход требует от компании определённого уровня зрелости, чётко поставленных процессов и некоторых инвестиций (обучение, организационные расходы, найм персонала и т.д.).

Usability guidelines

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

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

Usability guidelines — документ, описывающий правила применения как общих, так и отдельных, конкретных элементов интерфейса. Формирование и проверка на соответствие usability guidelines — это методика, позволяющая повысить юзабилити сайта или ПО, задачи которого типичны или сводимы к типичным. Гайдлайны также применяют для стандартизации и обеспечения некоторого общего приемлемого уровня качества. В гайдлайне собраны правила — «эвристики», часто выработанные опытным путём — которым следуют при разработке сайта. Эти правила могут касаться как совсем мелких, отдельных элементов интерфейса, так и больших частей взаимодействия.

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

Достоинства

Метод обладает целым рядом достоинств:

1. Не требует дополнительных затрат.
   Для внедрения и проведения тестирований с помощью контрольного списка не требуется дополнительных затрат, как при юзабилити-тестировании с привлечением реальных пользователей или других работ по методу UCD.
2. Легко внедрить.
   Применение usability guidelines не требует изменения существующих процессов разработки и больших затрат на обучение и внедрение.
3. Быстро «прививается».
   Уже после нескольких проектов, когда usability guidelines будут приняты в качестве корпоративного стандарта, правила описанные в гайдлайне будут выполняться подсознательно (без заглядывания в документ). Это похоже на то, как программисты после нескольких проектов перестают задумываться над правилами венгерской нотации (соглашение об именовании переменных)
4. Показывает конкретные проблемы интерфейса и даёт описание решений.
   Благодаря гайдлайну вы получаете конкретное описание того, какие проблемы есть в интерфейсе и чёткие инструкции по их устранению.
5. Повышает общую «планку» качества.
   Уменьшается зависимость качества интерфейса и юзабилити продукта от качества работы конкретных сотрудников. Если раньше можно было сказать, что кто-то делает аккуратнее, с меньшим количеством ошибок, а кто-то хуже. То теперь, некоторый приемлемый уровень качества достигается всеми. Кроме того гайдлайн способствует быстрому достижению этого уровня и у новых сотрудников.
6. Не требует специальных знаний для проведения тестирования.
   Для тестирования по контрольному списку никакой специальной подготовки иметь не нужно. Процесс тестирования по списку — это проверка соблюдения.

Недостатки

Чтобы быть объективным, стоит упомянуть и некоторых недостатках, которые, правда, недостатками можно назвать условно.

1. Неполнота содержания.
   У каждого продукта есть свои особенности и часто свои элементы интерфейса. Создать универсальный гайдлайн не получится.
2. Гайдлайн не решает проблем взаимодействия.
   В правилах практически невозможно учесть контекст использования, особенности пользователей и их задач. Эти вопросы решаются в каждом конкретном случае по-своему. Список лишь гарантирует отсутствие грубых ошибок.
3. Для составления контрольных списков потребуется некоторое время и терпение, опыт, изучение лучших практик, ну и некоторые знания в юзабилити, конечно.
   Можно привлечь к такой работе экспертов. Не лишней будет ревизия вашего гайдлайна экспертом.

Содержание

В качестве основы для своего гайдлайна я использовал контрольный список Влада Головача и Research Based Web-design and Usability guidelines, которые я дополнил правилами выведенными из практики веб-разработок компании в которой я работал. В составления своего гайдлайна Вы можете использовать как упомянутые мной списки, так и мой. На текущий момент он содержит правила (эвристики), сгруппированные по следующим элементам:

• Формы
• Кнопки
• Поля ввода
• Списки
• Системные сообщения и обработка ошибок
• Флажки и переключатели
• Текст
• Пошаговые действия (мастер)
• Капча

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

Рассмотрим несколько правил. Например: «1.1 Поля, обязательные для заполнения, обозначены звёздочкой перед своим названием. У формы есть пояснение об обозначении обязательных полей».

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

Или другое правило: «1.2 Названия полей выровнены по правой стороне. Расстояние от названия до поля для всех полей одинаковое». Это правило выведено на основании того, что выравнивание по правому краю позволяет избежать гребня из текста. Также длинные расстояния (если выравнивание было по левой стороне) сильно затрудняют ассоциацию названия поля с самим полем. Не редко приходится проверять правильность заполнения несколько раз.

Ещё одно правило: «3.3 Для полей ввода количественных характеристик (длинна, вес, рост, скорость, расстояние, размер и т.д.) необходимо указывать единицы измерения». Как Вы понимаете, правило позволяет избавиться от путаницы, которая возникла бы, если единицы измерения были бы не подписаны.

Советы по составлению гайдлайна

1. В каждом конкретном случае необходимо разрабатывать свой собственный контрольный список, поскольку он должен учитывать специфику разрабатываемого программного средства и возможности средств разработки.
2. Вносите абсолютные правила. Т. е. правила не должны содержать субъективных требований (таких как «навигация должна быть сделана хорошо»). Абсолютные правила унифицируют интерфейс.
3. Вносите правила устраняющие разногласия и разночтения. Когда существуют два равнозначных варианта интерфейсного решения, сделайте правилом любое из них. Это как минимум гарантирует интерфейсу консистентность.
   По всему миру проводятся юзабилити-тестирования, в результате которых определяются наиболее эргономичные решения. По результатам этих тестирований даются рекомендации для устранения разногласий.В качестве примера можно привести порядок расположения кнопок «Ok» и «Cancel» в различных ОС. Если в диалоговых окнах ОС Windows крайней справа расположена кнопка «Cancel» (отменяющая действие), то в MacOS это наоборот кнопка «Оk» (подтверждающая действие). Перейдя по ссылкам, вы сможете прочесть подробности этих исследований. На мой взгляд, важнее не поиск доказательств того, как следует расположить две кнопки, а гарантия, что в разных местах интерфейса это расположение будет одинаковым.
4. Сохраняйте проверенные временем, лучшие решения как правила.
   В процессе работы вы получаете обратную связь от пользователей или заказчиков, получает тикеты ваша служба поддержки, или, может быть, вы просто изучаете продукты конкурентов – везде вы встречаете удачные интерфейсные решения. Внедряя такие решения, описывайте их в гайдлайне.
   Рекомендую прочитать статью «Размещение кнопок «Вперед» и «Назад» в формах»

Внедрение

Перейдём к очень важному вопросу — внедрение гайдлайнов в рабочий процесс. Первое, что нужно сделать — «заразить» руководство качеством и юзабилити. Без поддержки руководства любая, даже самая хорошая идея, «зависает» и не доводится до конца. Расскажите о позитивном вкладе юзабилити. Например, для разработки ПО это:

• Снижение затрат на разработку
• Сокращение времени на разработку
• Снижение расходов на поддержку продукта
• Сокращение затрат на переделку продукта

Проведите работу по составлению usability guidelines. Воспользовавшись ссылками из презентации, вы получите, возможно, самый большой сборник гайдлайнов. Изучите их. Возьмите то, что подходит для вас.

Обсудите полученный список правил с руководителями отделов и коллегами. Выложите документ в открытый доступ (например, в локальном вики). Пусть у каждого будет возможность ознакомиться, обсудить и поделиться своими мыслями. Дайте гайдлайну «выкристолизоваться». По результатам общения внесите коррективы. Не спешите вносить абсолютно все пожелания и предложенные правила.

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

Создайте категорию «юзабилити» в вашей баг-трекинговой системе. Расскажите коллегам о нововведениях. Объясните, что баги юзабилити также важны, как и все остальные. В компании 1С, например, выходят целые билды после исправления одних лишь багов юзабилити.

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

Гайдлайны лидеров рынка разработки ПО

Среди компаний, создающих и поддерживающих свои usability guidelines, такие известные и крупные компании, как: SAP, Microsoft, Apple, Sun, Oracle, Nokia.

Первую точку зрения на руководства по стилям я почерпнул в книге Алана Купера «Психбольница в руках пациентов» и заключается она в том, что крупные компании принуждают разработчиков использовать их. Microsoft и Apple продвигают руководства по стилям интерфейсов, превозносят их мощь и пользу, и на первый взгляд может показаться, что эти компании являются самым компетентным источником подобной информации. Оба создателя платформ применяют скрытую форму принуждения, пытаясь заставить производителей придерживаться стандарта. Независимый разработчик ПО, не следующий рекомендациям руководства по стилю, не сможет заявить о «совместимости с платформой», лишая свой продукт важного плюса с точки зрения маркетинга. Таким образом, большинство компаний, создающих пользовательские приложения, готовы следовать рекомендациям разработчика платформы. Тем временем сами разработчики платформ вольны экспериментировать и давать ход новшествам, сколько пожелают. Они могут без угрызений совести пренебрегать собственными руководствами по стилям.

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

Следование гайдлайнам производителя делает интерфейс консистентным. Например, компания 1С передаёт своим партнёрам по кастомизации 1C Бухгалтерии гайдлайны на диске.

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

В этом гайдлайне приводится ряд правил и рекомендаций по созданию Ribbon Bar (новая концепция интерфейса программ пакета Office 2007). Например, наиболее частые функции размещаются в середине бара, потом частотность идёт слева на право.

Тестирование

Продемонстрирую тестирование с помощью гайдлайна на живом примере.

В интерфейсе, который Вы видели, один экран и одно окно сообщения. Разберём их, применяя правила гайдлайна.

Видно, что правило для формы: «1.2 Названия полей выровнены по правой стороне. Расстояние от названия до поля для всех полей одинаковое» соблюдается. Как и правило: «2.2 Надписи на кнопках начинаются с большой буквы. Если надпись состоит из нескольких слов, то каждое слово начинается с большой буквы, кроме предлогов». А вот «Подписи к интерфейсным элементам начинаются с прописной буквы и заканчиваются двоеточием» не соблюдается. Подписи «enter password:» и «confirm password:» начинаются со сторчной буквы, а должны с прописной. Пишем баг в вашу багтрэкинговую систему в категорию «юзабилити».

Что не так в этом окне сообщения? Например, правило: «2.8 Кнопка негативного действия «Удалить», «Стереть», «Отменить») всегда самая правая» соблюдается. Чего не скажешь о правиле: «2.2 Надписи на кнопках начинаются с большой буквы. Если надпись состоит из нескольких слов, то каждое слово начинается с большой буквы, кроме предлогов». Кнопка «cancel» написана с маленькой буквы, хотя для кнопки «ОК» правило соблюдено.

Дополнительно

• Книга Мэтью Линдермана, Джейсона Фрайда (из компании 37 сигналов) «Как создать посещаемый сайт и избежать типичных ошибок»
• Книга Jeff Johnson «GUI Bloopers 2.0» (на ozon.ru)
• Юзабилити гайдлайн автора статьи
• Microsoft Ribbons Guidelines
• Apple User experience
• Контрольный список интерфейса (Владислав Головач, Александр Белышкин. Usethics)

Презентация

Видео с конференции SQA Days в Минске