Comments 25
Миф 4: Юзабилити для всех одно
В книге «Психбольница в руках пациентов» при разработке массового программного продукта предлагается придумать конкретного пользователя (там он называется «персонажем») и проектировать продукт именно для него. При таком подходе, вероятно, наш «миф 4» станет рельностью.
Об этом-то и речь в записи. Если мы делаем систему управления реферральными отношениями, то у нее свой, сугубо-специфичный пользователь и мы ориентируемся на этого среднего «персонажа». И нам нужно ориентироваться именно на него. Если мы делаем систему для дизайнеров, то там тоже свои фичи у дизайнеров. От сочетаний клавиш, до положения кнопок. Именно потому линукс так непривычен для обычных людей — он заточен под специфичных пользователей, под эти конкретные «персонажи»
Если я правильно понял, автор как раз и пыталась донести мысль о том, что проектировать надо не для «универсального усредненного пользователя компьютера», а для определенного подмножества целевой аудитории. А для описания этого подмножества как раз «персонаж» и подойдет в качестве инструмента.
Спасибо тем, кто уже ответил за меня :) Действительно, я допускаю, что есть продукты, у которых только один персонаж. А вот если их несколько — надо либо делить продукт, либо предоставлять разным персонажам возможность настраивать продукт под себя.
К слову сказать, удобство GUI и функциональность системы порой идут в противоречие
И иногда трудно соблюсти компромисс. Т.е пример из личного опыта
Делался сайт. Пользователи просили добавьте кнопочек сюда, добавьте функциональность туда
Ну т.е обычный рабочий процесс.
Однако в какой то момент сталкиваешься с ситуацией, что кнопочка, которая нужна одному человеку очень сильно мешает другому
Ищеться компромисс, кнопочка уменьшаеться и т.д, пытаешься вместить как можно больше функционала в ограниченный размер
В результате все превращаеться в кашу. Пишуться настройки юзабилити, чтобы человек сам решал включать ему тот или иной пункт меню
Вроде все идеально, но теперь приходишь к ситуации, что пользователи начинают путаться уже в настройках интерфейса…
Т.е какая то патовая ситуация. И вроде хочеться, чтобы было удобно и понятно, но всем не получаеться угодить никогда
В общем конкретно для меня юзабилити (его построение) — открытая тема, спс за статью, немного подчерпнул
P.S А по сайту, о котором выше писал.
В результате 70% функционала и настроек, что так долго писалось, были в результате убраны…
И иногда трудно соблюсти компромисс. Т.е пример из личного опыта
Делался сайт. Пользователи просили добавьте кнопочек сюда, добавьте функциональность туда
Ну т.е обычный рабочий процесс.
Однако в какой то момент сталкиваешься с ситуацией, что кнопочка, которая нужна одному человеку очень сильно мешает другому
Ищеться компромисс, кнопочка уменьшаеться и т.д, пытаешься вместить как можно больше функционала в ограниченный размер
В результате все превращаеться в кашу. Пишуться настройки юзабилити, чтобы человек сам решал включать ему тот или иной пункт меню
Вроде все идеально, но теперь приходишь к ситуации, что пользователи начинают путаться уже в настройках интерфейса…
Т.е какая то патовая ситуация. И вроде хочеться, чтобы было удобно и понятно, но всем не получаеться угодить никогда
В общем конкретно для меня юзабилити (его построение) — открытая тема, спс за статью, немного подчерпнул
P.S А по сайту, о котором выше писал.
В результате 70% функционала и настроек, что так долго писалось, были в результате убраны…
Как раз в вашем примеры смешались пункты 4 и 5:
* нельзя, нельзя, нельзя слушаться пользователя! Столько раз я на эти грабли наступала :( Надо выяснять его истинные потребности, а не какие кнопочки он хочет
* как только мы видим противоречие в потребностях разных пользователей — надо выделять разные версии продукта, и проектировать под разных персонажей
* нельзя, нельзя, нельзя слушаться пользователя! Столько раз я на эти грабли наступала :( Надо выяснять его истинные потребности, а не какие кнопочки он хочет
* как только мы видим противоречие в потребностях разных пользователей — надо выделять разные версии продукта, и проектировать под разных персонажей
удобство GUI и функциональность системы порой идут в противоречие
Не порой, а всегда. ;] Идеальный интерфейс стремится к нулю. Идеальная функциональность — к бесконечности. Задача дизайнера как раз в нахождении баланса, удовлетворяющего заказчика (а не пользователя, представьте себе).
Удовлетворять заказчика — задача маркетологов, а не дизайнера :)
В корне не согласен. Маркетолог вам заказчика нашел и в сторонку отошел. Не будете же вы решать задачу пользователя, если проблема заказчика ей не решается.
Ну так проблему заказчика обычно можно решить сотней вариантов, и заказчику абсолютно всё равно, каким способом она будет решена. А дизайн всё-таки беспокоит конкретных пользователей продукта.
А разве задачу пользователя нельзя решить сотней вариантов? ;] И при этом доля «беспокойных» пользователей будет почти неизменна в каждом варианте. ;]
Ну, у меня есть ванильный опыт, когда заказчик менял подрядчика по разработке софта из-за жалоб пользователей, и после серьёзных изменений пользователи на нас молились, и заказчик тоже был счастлив. Доля «беспокойных» пользователей никогда не будет неизменной, если всерьёз браться за улучшения и не искать отмазки типа «да они всё равно будут на что-то жаловаться!».
Не понимаю. Из этого:
я делаю вывод, что эти сто вариантов одинаково хорошо решают задачу заказчика.
Вы не допускаете, что задача пользователя может быть решена сотней одинаково качественных вариантов (где соотношение довольных и недовольных будет одинаковым)? Вы считаете, что есть один идеальный вариант, а остальные хуже?
проблему заказчика обычно можно решить сотней вариантов, и заказчику абсолютно всё равно, каким способом она будет решена
я делаю вывод, что эти сто вариантов одинаково хорошо решают задачу заказчика.
Вы не допускаете, что задача пользователя может быть решена сотней одинаково качественных вариантов (где соотношение довольных и недовольных будет одинаковым)? Вы считаете, что есть один идеальный вариант, а остальные хуже?
Что-то мне кажется, что разговор не клеится :))) Попробую объяснить с примером:
Заказчик — розничная сеть продуктов питания. Задачи заказчика: товар не теряется, остатки наглядно видны, кассиры могут пользоваться продуктом. Эту задачу, действительно, можно решить сотней путей.
Но теперь давайте посмотрим глазами пользователей, а не заказчиков. Кассиры чаще всего не очень квалифицированный персонал, и им сложно изучать новое ПО. Если артикулы написаны слишком мелко, они их могут не видеть и придётся делать дополнительные телодвижения. Если нельзя удобно пробить 10 одинаковых товаров сразу, они будут тратить время на сканикорвание каждого. Если нельзя просто отменить неподходящую покупку, им будет неловко перед застрявшим в очереди покупателем.
С высоты полёта заказчика эти секунды ничего не стоят, ошибки кассиров скорее всего спишут на квалификацию кассиров, а умножить лишние затраты на реальное количество покупок в день большинство даже не додумается. А вот со стороны пользователя будет либо удовлетворение продуктом, либо недовольство.
Заказчику нужны очень высокоуровневые задачи, и юзабилити пользовательских операций в b2b софте очень редко действительно беспокоит заказчика. Поэтому, когда мы говорим про юзабилити, мы чаще всего говорим про пользователя, а функционал — про заказчика.
Заказчик — розничная сеть продуктов питания. Задачи заказчика: товар не теряется, остатки наглядно видны, кассиры могут пользоваться продуктом. Эту задачу, действительно, можно решить сотней путей.
Но теперь давайте посмотрим глазами пользователей, а не заказчиков. Кассиры чаще всего не очень квалифицированный персонал, и им сложно изучать новое ПО. Если артикулы написаны слишком мелко, они их могут не видеть и придётся делать дополнительные телодвижения. Если нельзя удобно пробить 10 одинаковых товаров сразу, они будут тратить время на сканикорвание каждого. Если нельзя просто отменить неподходящую покупку, им будет неловко перед застрявшим в очереди покупателем.
С высоты полёта заказчика эти секунды ничего не стоят, ошибки кассиров скорее всего спишут на квалификацию кассиров, а умножить лишние затраты на реальное количество покупок в день большинство даже не додумается. А вот со стороны пользователя будет либо удовлетворение продуктом, либо недовольство.
Заказчику нужны очень высокоуровневые задачи, и юзабилити пользовательских операций в b2b софте очень редко действительно беспокоит заказчика. Поэтому, когда мы говорим про юзабилити, мы чаще всего говорим про пользователя, а функционал — про заказчика.
По-моему, очень даже клеится. ;]
В вашем сценарии неудобство пользователя-кассира вызывает прямой убыток заказчику. То есть, «неюзабельный» способ ему в конце концов меньше понравится и ему будет не все равно.
Но я не об этом. Я о том, что «пробить 10 товаров сразу» можно не одним способом. А как раз «сотней». И кассиры будут одинаково довольны любым из «ста» вариантов пробивания десяти товаров сразу.
В вашем сценарии неудобство пользователя-кассира вызывает прямой убыток заказчику. То есть, «неюзабельный» способ ему в конце концов меньше понравится и ему будет не все равно.
Но я не об этом. Я о том, что «пробить 10 товаров сразу» можно не одним способом. А как раз «сотней». И кассиры будут одинаково довольны любым из «ста» вариантов пробивания десяти товаров сразу.
1. Продаж меньше не станет, прямой убыток никто не заметит. Просто поверьте, я уже объясняла заказчику выгоды от автоматизации процедуры, которая занимает 10 минут в день каждым из 4 тысяч сотрудников компании, и показывала в цифрах окупаемость доработки меньше чем за месяц. Это не всегда работает, далеко не с любым заказчиком :)
2. Как-то не хочется голословного обсуждения. По разным решениям реализации мы обычно засекаем скорость выполнения, скорость обучения, % ошибок, затраты методами Хика и Фитса. Пока что я не сталкивалась с равноценными вариантами реализации, но и утверждать, что это невозможно, тоже не буду.
2. Как-то не хочется голословного обсуждения. По разным решениям реализации мы обычно засекаем скорость выполнения, скорость обучения, % ошибок, затраты методами Хика и Фитса. Пока что я не сталкивалась с равноценными вариантами реализации, но и утверждать, что это невозможно, тоже не буду.
А вообще, у меня был вот такой реальный случай:
Крупный банковский софт, огромный отдел аналитиков и дизайнеров, я тестирую. Приходит новая фича (с детальным описанием требований, макапами, уже почти разработанная) — конвертация отчётов из одного формата в другой. Мне показалось очень неудобным, как всё это настраивалось, и я решила узнать подробнее, как это будет использоваться — может, проще сразу делать 2 разных формата? Прихожу к пользователям, а они говорят: «да нам вообще текущий формат не нужен, вот мы и попросили возможность конвертировать».
0_o WTF?
Почему этого не узнали аналитики?
Как они потом сказали, «ну клиент попросил, вот мы и придумали, как это сделать»… А оказалось, не нужно никакой конвертации — изначально нужен другой формат, и всё.
Крупный банковский софт, огромный отдел аналитиков и дизайнеров, я тестирую. Приходит новая фича (с детальным описанием требований, макапами, уже почти разработанная) — конвертация отчётов из одного формата в другой. Мне показалось очень неудобным, как всё это настраивалось, и я решила узнать подробнее, как это будет использоваться — может, проще сразу делать 2 разных формата? Прихожу к пользователям, а они говорят: «да нам вообще текущий формат не нужен, вот мы и попросили возможность конвертировать».
0_o WTF?
Почему этого не узнали аналитики?
Как они потом сказали, «ну клиент попросил, вот мы и придумали, как это сделать»… А оказалось, не нужно никакой конвертации — изначально нужен другой формат, и всё.
Группам пользователей и требуемой функциональности назначаются приоритеты. От приоритета уже и нужно отталкиваться.
Для полезного и успешного проведения тестирования юзабилити, требуется достаточно большое количество знаний и навыков:
— Понимание принципов юзабилити и проектирования интерфейсов
— Большой опыт использования продуктов на схожих платформах
— Понимание бизнес-составляющей продукта: зачем он нужен? Какие задачи решает?
— Знакомство с пользователем: кто он? В каких условиях работает с продуктом? Как он это делает?
Вообще-то самое главное — это знание и понимание целей пользователя, которые он преследует, используя продукт, и бизнеса, который разработкой продукта хочет достигнуть своих целей.
Тогда не возникает таких проблем:
Юзабилити – это и функционал в том числе. И зачастую при проведении детальных юзабилити-тестов мы приходили к необходимости убрать какой-то функционал, разработать другой и т.д.
тестирование GUI и тестирование юзабилити – совсем разные вещи.
тут в основном все делают ПО. Для него интерфейс взаимодействия с пользователем — это GUI. Так что тестируется удобство использования (юзабилити) GUI.
Википедия:
Юзаби́лити, удобство использования (англ. usability — дословно «возможность использования», «способность быть использованным», «полезность») — понятие в микроэргономике, эргономическая характеристика степени удобности предмета для применения пользователями при достижении определённых целей в некотором контексте.
Статью при чтении стоит «фильтровать».
Юзаби́лити, удобство использования (англ. usability — дословно «возможность использования», «способность быть использованным», «полезность»). тут в основном все делают ПО. Для него интерфейс взаимодействия с пользователем — это GUI. Так что тестируется удобство использования (юзабилити) GUI.
ОК. Я разрабатываю новый текстовый редактор. Дизайна понятнее и нагляднее свет не видел! Но это редактор не поддерживает форматы doc, docx, rtf. Как вы думаете, у этого продукта высокое юзабилити? :)
Вообще-то самое главное — это знание и понимание целей пользователя, которые он преследует, используя продукт, и бизнеса, который разработкой продукта хочет достигнуть своих целей.
Да, конечно!!! Именно поэтому владелец магазина и по совместительству главбух и гендир всегда сможет разработать CRM, бух.программу и кассовое приложение значительно «юзабельнее» всяких там проектировщиков!
Видела я результаты такого народного творчества. Так же можно сказать, что у вас «самое главное» — сердце, так что забейте на почки с печенью.
тестировали интерфейсы с помощью — www.fabuza.ru. Сильно помогло. Была CRM.
Sign up to leave a comment.
Мифы про юзабилити и его тестирование