Мифы про юзабилити и его тестирование

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

    Миф 1: Юзабилити – это GUI

    В восприятии многих тестировщиков есть 2 взаимоисключающих вида тестирования:
    • функциональное (работает или нет заявленная функциональность)
    • тестирование GUI (как расположены кнопочки, какого они размера и цвета)

    Функциональное тестирование при таком делении кажется более важным, а тестирование GUI – дополнительной опцией, простой и не очень важной. И именно её многие называют тестированием юзабилити…

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

    Юзабилити продукта определяется целым комплексом факторов:
    • Наличие требуемой пользователю функциональности и её работоспособность
    • Простота использования продукта и скорость обучения
    • Количество ошибок, которые совершают пользователи из-за непонимания.

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

    Миф 2: Тестирование юзабилити – это просто

    Как бы не так! Именно те, кто считают тестирование юзабилити простым, и проводят его без применения требуемых техник, дискредитируют понятие тестирования юзабилити как такового.

    Для полезного и успешного проведения тестирования юзабилити, требуется достаточно большое количество знаний и навыков:
    • Понимание принципов юзабилити и проектирования интерфейсов
    • Большой опыт использования продуктов на схожих платформах
    • Понимание бизнес-составляющей продукта: зачем он нужен? Какие задачи решает?
    • Знакомство с пользователем: кто он? В каких условиях работает с продуктом? Как он это делает?

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

    Миф 3: Любой человек может оценивать юзабилити продукта

    Представьте, что ваш ребёнок попросил в подарок на день рожденья 5 килограмм конфет, и вы согласились с этим. Но какие конфеты он любит?

    У вас есть 2 варианта, как их выбрать:
    • Дать попробовать разные конфеты ребёнку, чтобы он выбрал сам
    • Попробовать самостоятельно, выбрать самые вкусные на ваш взгляд, и купить 5 кг таких конфет.

    Конечно, во втором случае есть шанс, что вы угадаете, но он катастрофически маленький!
    То же самое в тестировании юзабилити: вы каждый день тестируете продукт, вы разбираетесь значительно лучше в технологиях и программах, у вас значительно выше компьютерная грамотность, чем у среднестатистического пользователя (если вы только не пишете софт для других айтишников). Внимание, вопрос: как вы можете оценить, что удобно бухгалтеру, впервые запустившему вашу программу, если вы не бухгалтер, и запускали её для тестирования примерно 632 тысячи раз?

    Хорошо понимая принципы юзабилити, вы можете получить полезную информацию от стороннего пользователя продукта, но сами её сгенерировать – нет!

    Миф 4: Юзабилити для всех одно

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

    Бухгалтеры бывают опытными и начинающими, графические редакторы используют дети и дизайнеры, антивирусы устанавливают администраторы крупных организаций и домохозяйки. Если вы попробуете удовлетворить взаимоисключающие потребности разных типов пользователей, вы не удовлетворите никого! Именно поэтому, есть MS Paint с простыми фигурками и кистями, и есть Photoshop с безграничным набором возможностей. Корпоративные антивирусы устанавливаются через доменные политики и имеют централизованный сервер управления, а домашние антивирусы имеют одну большую кнопку «защити меня». И, конечно, многие продукты имеют «расширенные настройки» для опытных пользователей, чтобы не пугать новичков.

    А вы знаете все свои типы пользователей? Вы предоставляете им разные варианты продукта?

    Миф 5: Заказчик знает, как сделать ему хорошо

    Если продукт заказной, то многие расслабляются: я могу просто спросить клиента, как ему лучше что-то сделать, и так и будет.
    Всё бы хорошо, если бы не парочка «но»:
    • Клиент ничего не знает о проектировании интерфейсов и зачастую предлагает абсолютно нелогичные идеи!
    • Клиент не всегда хорошо понимает, какие есть варианты реализации, и придумывает что-то слишком сложное.
    • Запрос за запросом, выполненные в соответствии с пожеланиями клиента, превращают ваш продукт в стёганое одеяло, потерявшее свою консистентность и общий уникальный стиль.

    Знакомиться с пользователями, исследовать их сценарии, выяснять и анализировать проблемы – важно! Но профессионалами по проектированию интерфейсов всё-таки должны быть мы с вами, а не пользователи.

    Миф 6: Юзабилити не очень важно, важнее функциональность

    Об этом я слышу особенно часто, но… Но как всегда, есть несколько «но»:
    • Юзабилити – это и функционал в том числе. И зачастую при проведении детальных юзабилити-тестов мы приходили к необходимости убрать какой-то функционал, разработать другой и т.д. И в этих случаях это расширение функциональности несло добро в этот мир и удовлетворяло потребностям пользователей, а не просто было придумано аналитиками потому что «хорошо бы добавить».
    • Если клиент не будет пользоваться продуктом (не поймёт, как; не захочет и т.д.), то до функционала он просто не дойдёт.

    Любой современный продукт, добавляя новые фичи, в 99% случаев только повышает юзабилити! Это заметно не сразу, но присмотритесь: всё, что вы разрабатывали прошедшие релизы, можно было сделать и без нововведений. Но без них это было бы сложнее. Например, почтовый клиент научился сортировать письма по папкам в соответствии с правилами – раньше это можно было делать вручную. В банковскую программу добавили новый отчёт – раньше его заполняли в текстовом редакторе. В графическом редакторе новый фильтр – раньше можно было руками провести аналогичную ретушь. Почти всё, что делают ваши продукты, можно делать и без их использования, и вообще без использования ПО. Но с продуктами это становится УДОБНЕЕ, удобство выполнения пользовательских задач и есть главная цель любого продукта!

    Выводы

    Юзабилити – активно развивающаяся область в разработке ПО. И только развеяв перечисленные выше (и прочие, их ещё немало!) мифы, непрерывно совершенствуя себя и уделяя удобству использования должное внимание, вы сможете выпускать достойные продукты.

    Узнать больше о тестировании юзабилити вы можете по нижеследующим ссылкам:
    Поделиться публикацией
    Комментарии 25
      0
      Миф 4: Юзабилити для всех одно

      В книге «Психбольница в руках пациентов» при разработке массового программного продукта предлагается придумать конкретного пользователя (там он называется «персонажем») и проектировать продукт именно для него. При таком подходе, вероятно, наш «миф 4» станет рельностью.
        +2
        Об этом-то и речь в записи. Если мы делаем систему управления реферральными отношениями, то у нее свой, сугубо-специфичный пользователь и мы ориентируемся на этого среднего «персонажа». И нам нужно ориентироваться именно на него. Если мы делаем систему для дизайнеров, то там тоже свои фичи у дизайнеров. От сочетаний клавиш, до положения кнопок. Именно потому линукс так непривычен для обычных людей — он заточен под специфичных пользователей, под эти конкретные «персонажи»
          0
          «Линукс» разный бывает. Конечно, если посадить неподготовленного пользователя за голую консоль, то он вряд ли что сможет сделать. А той же убунтой и бабушка пользоваться может.
          +1
          Если я правильно понял, автор как раз и пыталась донести мысль о том, что проектировать надо не для «универсального усредненного пользователя компьютера», а для определенного подмножества целевой аудитории. А для описания этого подмножества как раз «персонаж» и подойдет в качестве инструмента.
            0
            Спасибо тем, кто уже ответил за меня :) Действительно, я допускаю, что есть продукты, у которых только один персонаж. А вот если их несколько — надо либо делить продукт, либо предоставлять разным персонажам возможность настраивать продукт под себя.
            +1
            К слову сказать, удобство GUI и функциональность системы порой идут в противоречие
            И иногда трудно соблюсти компромисс. Т.е пример из личного опыта
            Делался сайт. Пользователи просили добавьте кнопочек сюда, добавьте функциональность туда
            Ну т.е обычный рабочий процесс.
            Однако в какой то момент сталкиваешься с ситуацией, что кнопочка, которая нужна одному человеку очень сильно мешает другому
            Ищеться компромисс, кнопочка уменьшаеться и т.д, пытаешься вместить как можно больше функционала в ограниченный размер
            В результате все превращаеться в кашу. Пишуться настройки юзабилити, чтобы человек сам решал включать ему тот или иной пункт меню
            Вроде все идеально, но теперь приходишь к ситуации, что пользователи начинают путаться уже в настройках интерфейса…
            Т.е какая то патовая ситуация. И вроде хочеться, чтобы было удобно и понятно, но всем не получаеться угодить никогда
            В общем конкретно для меня юзабилити (его построение) — открытая тема, спс за статью, немного подчерпнул
            P.S А по сайту, о котором выше писал.
            В результате 70% функционала и настроек, что так долго писалось, были в результате убраны…
              0
              Как раз в вашем примеры смешались пункты 4 и 5:
              * нельзя, нельзя, нельзя слушаться пользователя! Столько раз я на эти грабли наступала :( Надо выяснять его истинные потребности, а не какие кнопочки он хочет
              * как только мы видим противоречие в потребностях разных пользователей — надо выделять разные версии продукта, и проектировать под разных персонажей
                0
                удобство GUI и функциональность системы порой идут в противоречие

                Не порой, а всегда. ;] Идеальный интерфейс стремится к нулю. Идеальная функциональность — к бесконечности. Задача дизайнера как раз в нахождении баланса, удовлетворяющего заказчика (а не пользователя, представьте себе).
                  0
                  Удовлетворять заказчика — задача маркетологов, а не дизайнера :)
                    +1
                    В корне не согласен. Маркетолог вам заказчика нашел и в сторонку отошел. Не будете же вы решать задачу пользователя, если проблема заказчика ей не решается.
                      +1
                      Ну так проблему заказчика обычно можно решить сотней вариантов, и заказчику абсолютно всё равно, каким способом она будет решена. А дизайн всё-таки беспокоит конкретных пользователей продукта.
                        +1
                        А разве задачу пользователя нельзя решить сотней вариантов? ;] И при этом доля «беспокойных» пользователей будет почти неизменна в каждом варианте. ;]
                          +1
                          Ну, у меня есть ванильный опыт, когда заказчик менял подрядчика по разработке софта из-за жалоб пользователей, и после серьёзных изменений пользователи на нас молились, и заказчик тоже был счастлив. Доля «беспокойных» пользователей никогда не будет неизменной, если всерьёз браться за улучшения и не искать отмазки типа «да они всё равно будут на что-то жаловаться!».
                            +1
                            Не понимаю. Из этого:

                            проблему заказчика обычно можно решить сотней вариантов, и заказчику абсолютно всё равно, каким способом она будет решена

                            я делаю вывод, что эти сто вариантов одинаково хорошо решают задачу заказчика.

                            Вы не допускаете, что задача пользователя может быть решена сотней одинаково качественных вариантов (где соотношение довольных и недовольных будет одинаковым)? Вы считаете, что есть один идеальный вариант, а остальные хуже?
                              +1
                              Что-то мне кажется, что разговор не клеится :))) Попробую объяснить с примером:

                              Заказчик — розничная сеть продуктов питания. Задачи заказчика: товар не теряется, остатки наглядно видны, кассиры могут пользоваться продуктом. Эту задачу, действительно, можно решить сотней путей.

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

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

                              Заказчику нужны очень высокоуровневые задачи, и юзабилити пользовательских операций в b2b софте очень редко действительно беспокоит заказчика. Поэтому, когда мы говорим про юзабилити, мы чаще всего говорим про пользователя, а функционал — про заказчика.
                                0
                                По-моему, очень даже клеится. ;]

                                В вашем сценарии неудобство пользователя-кассира вызывает прямой убыток заказчику. То есть, «неюзабельный» способ ему в конце концов меньше понравится и ему будет не все равно.

                                Но я не об этом. Я о том, что «пробить 10 товаров сразу» можно не одним способом. А как раз «сотней». И кассиры будут одинаково довольны любым из «ста» вариантов пробивания десяти товаров сразу.
                                  +1
                                  1. Продаж меньше не станет, прямой убыток никто не заметит. Просто поверьте, я уже объясняла заказчику выгоды от автоматизации процедуры, которая занимает 10 минут в день каждым из 4 тысяч сотрудников компании, и показывала в цифрах окупаемость доработки меньше чем за месяц. Это не всегда работает, далеко не с любым заказчиком :)

                                  2. Как-то не хочется голословного обсуждения. По разным решениям реализации мы обычно засекаем скорость выполнения, скорость обучения, % ошибок, затраты методами Хика и Фитса. Пока что я не сталкивалась с равноценными вариантами реализации, но и утверждать, что это невозможно, тоже не буду.
                                    0
                                    1. Верю.

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

                  0_o WTF?
                  Почему этого не узнали аналитики?

                  Как они потом сказали, «ну клиент попросил, вот мы и придумали, как это сделать»… А оказалось, не нужно никакой конвертации — изначально нужен другой формат, и всё.
                    0
                    «Ну, тут систему менять надо...» ;]
                    0
                    Группам пользователей и требуемой функциональности назначаются приоритеты. От приоритета уже и нужно отталкиваться.
                    0
                    Для полезного и успешного проведения тестирования юзабилити, требуется достаточно большое количество знаний и навыков:
                    — Понимание принципов юзабилити и проектирования интерфейсов
                    — Большой опыт использования продуктов на схожих платформах
                    — Понимание бизнес-составляющей продукта: зачем он нужен? Какие задачи решает?
                    — Знакомство с пользователем: кто он? В каких условиях работает с продуктом? Как он это делает?

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

                    Тогда не возникает таких проблем:
                    Юзабилити – это и функционал в том числе. И зачастую при проведении детальных юзабилити-тестов мы приходили к необходимости убрать какой-то функционал, разработать другой и т.д.


                    тестирование GUI и тестирование юзабилити – совсем разные вещи.

                    тут в основном все делают ПО. Для него интерфейс взаимодействия с пользователем — это GUI. Так что тестируется удобство использования (юзабилити) GUI.

                    Википедия:
                    Юзаби́лити, удобство использования (англ. usability — дословно «возможность использования», «способность быть использованным», «полезность») — понятие в микроэргономике, эргономическая характеристика степени удобности предмета для применения пользователями при достижении определённых целей в некотором контексте.


                    Статью при чтении стоит «фильтровать».
                      +1
                      Юзаби́лити, удобство использования (англ. usability — дословно «возможность использования», «способность быть использованным», «полезность»). тут в основном все делают ПО. Для него интерфейс взаимодействия с пользователем — это GUI. Так что тестируется удобство использования (юзабилити) GUI.

                      ОК. Я разрабатываю новый текстовый редактор. Дизайна понятнее и нагляднее свет не видел! Но это редактор не поддерживает форматы doc, docx, rtf. Как вы думаете, у этого продукта высокое юзабилити? :)
                        +1
                        Вообще-то самое главное — это знание и понимание целей пользователя, которые он преследует, используя продукт, и бизнеса, который разработкой продукта хочет достигнуть своих целей.

                        Да, конечно!!! Именно поэтому владелец магазина и по совместительству главбух и гендир всегда сможет разработать CRM, бух.программу и кассовое приложение значительно «юзабельнее» всяких там проектировщиков!

                        Видела я результаты такого народного творчества. Так же можно сказать, что у вас «самое главное» — сердце, так что забейте на почки с печенью.
                        0
                        тестировали интерфейсы с помощью — www.fabuza.ru. Сильно помогло. Была CRM.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое