Удобство использования продукта, высокие пользовательские качества — важное конкурентное преимущество на рынке, где большинство производителей предлагают приблизительно одинаковую функциональность. В качестве наиболее актуального примера можно привести рынок мобильных телефонов, где сейчас наиболее востребованы и хорошо продаются удобные в использовании телефоны (с этим связан успех iPhone и переход на тач-скрин).
Что следует понимать под юзабилити? Определение юзабилити приведено в стандарте ISO 9241-11 как степень эффективности, продуктивности и удовлетворенности, с которой продукт может использоваться определёнными пользователями для достижения определённых задач в определённом контексте.
С ошибками, отрицательно влияющими на нашу продуктивность и удовлетворённость, мы сталкиваемся в реальной жизни повсеместно. Будь то, обязанность заполнять ненужные поля в формах заявлений и справок; обязательные требование предоставить какие-то документы и справки, в которых объективно нет никакой необходимости, но которых требует процедура; простаивание в очередях и пробках и т.д.
Нет ничего удивительного в том, что подобная практика переносится на все, что создаёт человек, в том числе программное обеспечение и веб-сайты. Надо понимать, что никто не создаёт плохие системы специально. Даже самые опытные специалисты и крупные производители допускают ошибки.
Альберт Эйнштейн сказал, что нельзя решить проблему, находясь внутри системы, которая ее породила. Пока требование высоких пользовательских качеств и использование практик юзабилити не станет неотъемлемой частью процесса производства ПО, на свет будут появляться продукты и сайты, которыми тяжело или даже невозможно пользоваться.
В качестве примера рассмотрим форму, поля которой можно заполнить только в строго заданном формате. В процессе тестирования такая форма может не вызывать подозрения даже у самого чуткого QA. Формально, она проходит тест — при вводе данных не по формату она покажет ошибку, при вводе правильных пропускает дальше.
Но как в дальнейшем придётся тем, кто будет с этой формой работать? Заполнение каждого поля происходит методом проб и ошибок, что становиться настоящим кошмаром для пользователей. Это приводит к неэффективной работе. Такая реализация остальных экранных форм в программе обязательно приведёт к жалобам на неудобства в работе и неприятию автоматизации. А это в свою очередь, может привести к провалу всего проекта по внедрению нового программного обеспечения. Чтобы изменить ситуацию, следует изменить парадигму мышления при разработке: лучше предотвращать появление ошибок, чем ограничиться мерами по их устранению.
Высокие показатели юзабилити продукта достигаются за счёт внедрения в разработку подхода UCD (User Centered Design или дизайн ориентированный на пользователя). Данный подход характеризуется активным вовлечением пользователя в процесс разработки для достижения понимания пользовательских требований и надлежащего распределения функций между пользователями и технологиями, а также итеративным характером подхода и его мультидисциплинарностью (ISO 13407). Практика User Centered Design позволяет сократить расходы на разработку и повышает эффективность продукта, как в бизнес отношении (дополнительная прибыль), так и в удовлетворенности пользователей (повышение лояльности к продукту и компании-разработчику). Такой подход применяется на всём жизненном цикле создания ПО и включает в себя: определение требований, анализ, проектирование, тестирование, оценку и последующую доработку интерфейса. На данный момент крупные компании, как западные (Microsoft, Google), так и российские (Билайн, РТС, 1С) внедряют практики UCD в свои процессы. Такой подход требует от компании определённого уровня зрелости, чётко поставленных процессов и некоторых инвестиций (обучение, организационные расходы, найм персонала и т.д.).
Будучи реалистом, я понимаю, что эти требования пока являются слишком высокими для большинства малых и средних компаний веб-разработчиков и веб-студий России, а тем более Беларуси. Их основные потребности в этой области - оперативно и с малыми затратами определить (задать) требуемый уровень юзабилити для своих проектов и продуктов, сформировать требования и рекомендации, задать критерии (метрики) для последующей оценки и анализа.
Одним из доступных способов улучшить пользовательские качества выпускаемых продуктов и повысить профессиональный уровень сотрудников, является использование usability guidelines («юзабилити гайдлайны», руководство по стилю, спецификация интерфейса, правила и т.д.)
Usability guidelines — документ, описывающий правила применения как общих, так и отдельных, конкретных элементов интерфейса. Формирование и проверка на соответствие usability guidelines — это методика, позволяющая повысить юзабилити сайта или ПО, задачи которого типичны или сводимы к типичным. Гайдлайны также применяют для стандартизации и обеспечения некоторого общего приемлемого уровня качества. В гайдлайне собраны правила — «эвристики», часто выработанные опытным путём — которым следуют при разработке сайта. Эти правила могут касаться как совсем мелких, отдельных элементов интерфейса, так и больших частей взаимодействия.
Как правило, эвристики формулируются так, чтобы по каждому правилу можно было сказать «поддерживается» ли оно в интерфейсе или «нарушается» (чек лист), избегая субъективных оценок.
Метод обладает целым рядом достоинств:
Чтобы быть объективным, стоит упомянуть и некоторых недостатках, которые, правда, недостатками можно назвать условно.
В качестве основы для своего гайдлайна я использовал контрольный список Влада Головача и Research Based Web-design and Usability guidelines, которые я дополнил правилами выведенными из практики веб-разработок компании в которой я работал. В составления своего гайдлайна Вы можете использовать как упомянутые мной списки, так и мой. На текущий момент он содержит правила (эвристики), сгруппированные по следующим элементам:
Список можно дополнять правилами и для целых элементов взаимодействия. Например, я добавил правила для пошаговых действий (мастера) и капчи.
Рассмотрим несколько правил. Например: «1.1 Поля, обязательные для заполнения, обозначены звёздочкой перед своим названием. У формы есть пояснение об обозначении обязательных полей».
Это правило добавлено из-за гипотезы о том, что читая слева на право, пользователь быстрее увидит обязательные для заполнения поля и заполнит их сразу. Но и для правил существуют исключения. Для этого оно состоит в том, что для формы авторизации поля звёздочкой не выделяются. Для форм, где все поля являются обязательными, можно не обозначать каждое, однако необходимо написать о том, что все поля обязательные для заполнения. Лучше всего это сделать сверху формы, над всеми полями.
Или другое правило: «1.2 Названия полей выровнены по правой стороне. Расстояние от названия до поля для всех полей одинаковое». Это правило выведено на основании того, что выравнивание по правому краю позволяет избежать гребня из текста. Также длинные расстояния (если выравнивание было по левой стороне) сильно затрудняют ассоциацию названия поля с самим полем. Не редко приходится проверять правильность заполнения несколько раз.
Ещё одно правило: «3.3 Для полей ввода количественных характеристик (длинна, вес, рост, скорость, расстояние, размер и т.д.) необходимо указывать единицы измерения». Как Вы понимаете, правило позволяет избавиться от путаницы, которая возникла бы, если единицы измерения были бы не подписаны.
Перейдём к очень важному вопросу — внедрение гайдлайнов в рабочий процесс. Первое, что нужно сделать — «заразить» руководство качеством и юзабилити. Без поддержки руководства любая, даже самая хорошая идея, «зависает» и не доводится до конца. Расскажите о позитивном вкладе юзабилити. Например, для разработки ПО это:
Проведите работу по составлению 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» написана с маленькой буквы, хотя для кнопки «ОК» правило соблюдено.
Написать письмо на e-mailicq 415547094 romverinbox.ru© 1997 - 2024 romver.ru
