В теме 48 ответов, и 12 участников, последнее обновление сделано пользователем 
Герман Шестеров 12 г, 7 мес. назад.
-
Сообщения
-
По роду своей деятельности мне часто приходится сталкиваться с вопросами обеспечения юзабилити. С одной стороны, я аналитик и занимаюсь проектированием информационных систем. С другой – мне доводилось оценивать готовые системы и прототипы и разрабатывать рекомендации по их улучшению. Пришло время поделиться знаниями.
Далееотличная статья!Присоединяюсь к предыдущему оратору!!!1) Правильная мысль — юзабилити не сводится к "удобству использования"2) Спорный тезис, что за юзабилити должен отвечать аналитик. ИМХО, юзабилити — это епархия пользователя. Идеально, когда пользователь имеет возможность сам улучшать юзабилити. Что, собственно, обеспечивается во многих информационных системах с настраиваемыми интерфейсами. Пожалуй, что аналитик должен побеспокоиться об обеспечении разумной настраиваемости.
3) С чего начать? С пользователей! О, это очень новая мысль! С чего начать проект? Хм, тоже с пользователей… С чего начать сбор исходных данных? Ух ты! С пользователей! Неужели? Так мы ж продукт делаем для пользователей! Конечно, начать нужно с пользователей! А еще лучше начинать нужно с вежливых слов, например: Здравствуйте!
Начинать нужно с процессов, по которым работают пользователи. Хорошее понимание процесса позволит также понять, who is пользователи.
2) Спорный тезис, что за юзабилити должен отвечать аналитик. ИМХО, юзабилити — это епархия пользователя. Идеально, когда пользователь имеет возможность сам улучшать юзабилити. Что, собственно, обеспечивается во многих информационных системах с настраиваемыми интерфейсами. Пожалуй, что аналитик должен побеспокоиться об обеспечении разумной настраиваемости.
Здравствуйте, AndrewK
В идеальном мире за юзабилити отвечает специально обученный человек — его роль может называться "проектировщик интерфейсов", "проектировщик взаимодействия", "юзабилити-инженер" и т.п. Лично я таких специалистов в нашей стране практически не встречала (за редчайшим исключением). Даже аналитики — роль (как ни странно) относительно редкая, по сравнению, например, с тестировщиками/ разработчиками. Что уж тут говорить о ролях более экзотических.
Поэтому я и пишу, что заниматься обеспечением юзабилити может аналитик: именно этот человек собирает требования и продумывает взаимодействие человек-система; он_уже_и_так_это_делает.
С тезисом "юзабилити — это епархия пользователя" не согласна категорически. Если почитать о компонентах, из которых это самое юзабилити состоит (для этого можно обратиться к товарищу Якобу Нильсену), то можно увидеть, что состоит оно из следующих компонентов:
- Learnability
- Satisfaction
- Efficiency
- Memorability
- Error Management
Могу пояснить каждый, если это требуется, правда, думаю вопросы отпадут сами собой. Как, интересно, пользователь сам будет настраивать интерфейс так, чтобы повысить легкость его освоения? Или чтобы предупредить свои же ошибки? В конце концов такую вещь, как Accessibility тоже никто не отменял, хотя порой ее выносят за рамки юзабилити и рассматривают отдельно. Но тем не менее, это что, тоже "епархия пользователя" ?3) С чего начать? С пользователей! О, это очень новая мысль! С чего начать проект? Хм, тоже с пользователей… С чего начать сбор исходных данных? Ух ты! С пользователей! Неужели? Так мы ж продукт делаем для пользователей! Конечно, начать нужно с пользователей! А еще лучше начинать нужно с вежливых слов, например: Здравствуйте!
Начинать нужно с процессов, по которым работают пользователи. Хорошее понимание процесса позволит также понять, who is пользователи.Не претендую на новизну мысли в этом вопросе. Из личного опыта: огромное количество проектов начинаются с заказчиков и делаются для заказчиков (а это далеко не всегда пользователь). Заказчик выступает посредником, и в общем-то все процессы описываются с его слов и по его представлению (а оно может быть ложным), в этом-то и проблема.
Здравствуйте, AndrewK
Можете ведь! :-)
В идеальном мире за юзабилити отвечает специально обученный человек — его роль может называться "проектировщик интерфейсов", "проектировщик взаимодействия", "юзабилити-инженер" и т.п. Лично я таких специалистов в нашей стране практически не встречала (за редчайшим исключением). Даже аналитики — роль (как ни странно) относительно редкая, по сравнению, например, с тестировщиками/ разработчиками. Что уж тут говорить о ролях более экзотических.
Поэтому я и пишу, что заниматься обеспечением юзабилити [i]может[/i] аналитик: именно этот человек собирает требования и продумывает взаимодействие человек-система; он_уже_и_так_это_делает.Такой старый перец, как я, еще может помнить, как в советские времена гремела на всю страну модная наука эргономика, которая занималась изучением взаимодействия человека с техническими системами. И были такие специально обученные инженеры по эргономике… в общем, они сами не знали, чем они должны заниматься. Спец по юзабилити уж очень похож на инженера по эргономике.
С тезисом "юзабилити — это епархия пользователя" не согласна категорически. Если почитать о компонентах, из которых это самое юзабилити состоит (для этого можно обратиться к товарищу [url=http://www.useit.com/alertbox/20030825.html]Якобу Нильсену[/url]), то можно увидеть, что состоит оно из следующих компонентов:
- Learnability
- Satisfaction
- Efficiency
- Memorability
- Error Management
Могу пояснить каждый, если это требуется, правда, думаю вопросы отпадут сами собой. Как, интересно, пользователь сам будет настраивать интерфейс так, чтобы повысить легкость его освоения? Или чтобы предупредить свои же ошибки? В конце концов такую вещь, как Accessibility тоже никто не отменял, хотя порой ее выносят за рамки юзабилити и рассматривают отдельно. Но тем не менее, это что, тоже "епархия пользователя" ?Сила, брат, в правде! Информационная система должна помогать делать пользователю работу. В ней должно быть то, что нужно, и не должно быть того, чего не нужно. ИМХО, все остальное — это bla-bla-bility, bla-bla-action и bla-bla-ment.
[quote="AndrewK"]
3) С чего начать? С пользователей! О, это очень новая мысль! С чего начать проект? Хм, тоже с пользователей… С чего начать сбор исходных данных? Ух ты! С пользователей! Неужели? Так мы ж продукт делаем для пользователей! Конечно, начать нужно с пользователей! А еще лучше начинать нужно с вежливых слов, например: Здравствуйте!
Начинать нужно с процессов, по которым работают пользователи. Хорошее понимание процесса позволит также понять, who is пользователи.Не претендую на новизну мысли в этом вопросе. Из личного опыта: огромное количество проектов начинаются с заказчиков и делаются для заказчиков (а это далеко не всегда пользователь). Заказчик выступает посредником, и в общем-то все процессы описываются с его слов и по его представлению (а оно может быть ложным), в этом-то и проблема.[/quote]
Не придирайтесь… Конечно же, речь идет о заинтересованных сторонах. В любом случае, когда мы говорим о юзабилити, то мы имеем ввиду субъекта, который тыкает в клавиши и пялится в экран.
Такой старый перец, как я, еще может помнить, как в советские времена гремела на всю страну модная наука эргономика, которая занималась изучением взаимодействия человека с техническими системами. И были такие специально обученные инженеры по эргономике… в общем, они сами не знали, чем они должны заниматься. Спец по юзабилити уж очень похож на инженера по эргономике.
Я, конечно, не могу назвать себя старым перцем, но, поверьте, о модной науке эргономике знаю не понаслышке
. Да, не все было идеально в этом плане в СССР, однако говорить, что эргономисты не знали, чем заниматься, не стоит. Благодаря им, в частности, с появлением Т-34 бойцы перестали себе отрубать пальцы крышкой люка (с его предшественником, увы, были прецеденты). Благодаря им уменьшилось число авиакатастроф по вине пилотов, которые в критический момент путались в приборах. Понятное дело, что работа на таких масштабных проектах происходит в огромных командах, поэтому говорить, что все заслуги принадлежат эргономистам, было бы поспешно. Однако и пренебрегать ими не следует.
В Microsoft функционирует 25+ юзабилити-лабораторий. Подозреваю, что спецы по юзабилити не только знают, чем должны заниматься, но и успешно этим занимаются.Сила, брат, в правде! Информационная система должна помогать делать пользователю работу. В ней должно быть то, что нужно, и не должно быть того, чего не нужно. ИМХО, все остальное — это bla-bla-bility, bla-bla-action и bla-bla-ment.
Это тоже проблема. Как узнать, что нужно, а что — нет? Часто пользователь просто перечислит список "хочу, хочу, хочу … а еще чтобы это, это и это". Притом хорошо, если треть этих "хотелок" впоследствии будет использоваться.
Более того, если в системе есть все, что нужно, как быть, если пользователь не может найти эти функции? Или не понимает, как с ними работать? Понятное дело, можно создавать всякие справочные системы, проводить тренинги, и т.д. и т.п. Но если у системы есть альтернатива с тем же функционалом, но попроще и понятнее, почему пользователю не перейти на нее? Опять же, что выгоднее: тратиться на создание и поддержку справочной системы и обучение пользователей, либо сразу проектировать систему так, чтобы справка не понадобилась?
В конце концов, пусть все фичи доступны и пользователь даже понял, как с ними работать. Что если интерфейс таков, что не помогает избежать пользователю ошибок, или, еще хуже, способствуют их совершению? Одно дело, если пользователь случайно безвозвратно удалит фото с фейсбука: переживет, хоть и расстроится. А как быть с медицинскими и военными системами, где цена ошибки повыше будет?Я, конечно, не могу назвать себя старым перцем, но, поверьте, о модной науке эргономике знаю не понаслышке
. Да, не все было идеально в этом плане в СССР, однако говорить, что эргономисты не знали, чем заниматься, не стоит. Благодаря им, в частности, с появлением Т-34 бойцы перестали себе отрубать пальцы крышкой люка (с его предшественником, увы, были прецеденты). Благодаря им уменьшилось число авиакатастроф по вине пилотов, которые в критический момент путались в приборах. Понятное дело, что работа на таких масштабных проектах происходит в огромных командах, поэтому говорить, что все заслуги принадлежат эргономистам, было бы поспешно. Однако и пренебрегать ими не следует.
В Microsoft функционирует 25+ юзабилити-лабораторий. Подозреваю, что спецы по юзабилити не только знают, чем должны заниматься, но и успешно этим занимаются.Историю с эргономистами, которые решили проблему с люком в Т-34, я не знал; поделитесь ссылкой, плз. С другой стороны, проблема с люком достаточно очевидна: люк должен закрываться плотно, чтобы обеспечивать герметичность, и должен закрываться неплотно, чтобы не отрубать пальцы; люк должен двигаться быстро, чтобы быстро закрываться, и должен двигаться медленно (в момент касания с корпусом), чтобы не отрубать пальцы. Скорее всего, специальный тормоз (пружина?) и резиновая прокладка решают проблему с люком. Я это к тому, что проблема с люком — это ПРОБЛЕМА, которая должна решаться конструкторами (по-нашему, аналитиками), а не юзабилити-специалистами. Еще важнее, что требование удобства (в случае с люком — сохранности пальцев) вступает в противоречие с другими требованиями (скорость и плотность закрывания люка). А противоречивые требования должны решаться на уровне человека, ответственного за систему в целом.
[quote="AndrewK"]
Сила, брат, в правде! Информационная система должна помогать делать пользователю работу. В ней должно быть то, что нужно, и не должно быть того, чего не нужно. ИМХО, все остальное — это bla-bla-bility, bla-bla-action и bla-bla-ment.Это тоже проблема. Как узнать, что нужно, а что — нет? Часто пользователь просто перечислит список "хочу, хочу, хочу … а еще чтобы это, это и это". Притом хорошо, если треть этих "хотелок" впоследствии будет использоваться.[/quote]
Не понял, как связано извлечение требований и юзабилити системы?
Более того, если в системе есть все, что нужно, как быть, если пользователь не может найти эти функции? Или не понимает, как с ними работать? Понятное дело, можно создавать всякие справочные системы, проводить тренинги, и т.д. и т.п. Но если у системы есть альтернатива с тем же функционалом, но попроще и понятнее, почему пользователю не перейти на нее? Опять же, что выгоднее: тратиться на создание и поддержку справочной системы и обучение пользователей, либо сразу проектировать систему так, чтобы справка не понадобилась?
В конце концов, пусть все фичи доступны и пользователь даже понял, как с ними работать. Что если интерфейс таков, что не помогает избежать пользователю ошибок, или, еще хуже, способствуют их совершению? Одно дело, если пользователь случайно безвозвратно удалит фото с фейсбука: переживет, хоть и расстроится. А как быть с медицинскими и военными системами, где цена ошибки повыше будет?ИМХО,
1) можно вести речь об особом виде требований — требованиях по юзабилити системы;
2) имеет смысл говорить о специфике выделения требований этого вида;
3) возможно, что для этого вида требований следует определить специфические методы оценки их реализованности в системе.4) Методы поиска (создания) решений должны быть общими для всех видов требований, т.е., когда мы ищем решение для системы, мы должны учитывать все виды требований, в т.ч., требования по юзабилити.
5) Методы обнаружения проблем (противоречий между требованиями) тоже должны быть общими. Другими словами, проблемы могут возникать, в том числе, при возникновении противоречий между требованиями по юзабилити и другими, например, функциональными или системными, требованиями. См. пример с люком танка.
6) Методы решения проблем, т.е., поиска (создания) непротиворечивых решений, тоже должны быть общими.Я бы определил еще вот какое противоречие: если требованиями по юзабилити занимается специальный человек, то (+) этот вид требований в проекте будет учтен в полном объеме; (-) поиск (создание) решений в проекте усложнится из-за необходимых коммуникаций между человеком по юзабилити и аналитиками. И наоборот, если специального человека нет, то (-) требования по юзабилити могут неоправданно игнориться, ну а (+) очевиден. Я бы сформулировал проблему следующим образом: как в проекте без специального человека по юзабилити обеспечить учет этих требований в полном объеме?
Зато в "Пантере" было все куда более удобно и эргономично, чем в Т34. Но войну почему то немцы проиграли: в среднем на каждый выпущенный качественно немецкий танк приходилось около трех грубо сделанных советских.
Думаю не стоит забывать о предназначении системы и о приоритетах, иначе в это юзабилити можно зарыться и каждую кнопку с линейкой мерять изучая статистические данные об уровне дальнозоркости и близорукости в данном регионе.Зато в "Пантере" было все куда более удобно и эргономично, чем в Т34. Но войну почему то немцы проиграли: в среднем на каждый выпущенный качественно немецкий танк приходилось около трех грубо сделанных советских.
Думаю не стоит забывать о предназначении системы и о приоритетах, иначе в это юзабилити можно зарыться и каждую кнопку с линейкой мерять изучая статистические данные об уровне дальнозоркости и близорукости в данном регионе.Помоему, Belle Morte не призывала забить болт на все остальное кроме юзабилити? Или это попытка флуда?
Cсылки на пример с танком, к сожалению, под рукой не оказалось. Если вас заинтересовала тема, настоятельно рекомендую обратиться к "отцам" эргономики — В.П.Зинченко и В.М.Мунипову. В их книге Эргономика: человекоориентрованное проектирование техники, программных средств и среды вы найдете описание того, какие задачи решали эргономисты, какими методами они это делали и какой полезный эффект получался на выходе (особенно советую обратить внимание на раздел "Фактографические приложения"). Там хватает примеров получше, чем приведенный мной.
В том-то и особенность, что все проблемы в эргономике, как правило, очевидны уже пост-фактум. Я думаю конструкторы, если бы их спросили, должен ли люк травмировать пальцы, сказали бы "нет". Конструкторы бы сказали, что клавиатуры не должны вызывать кистевой туннельный синдром. А авиадиспетчеры не должны путаться в зеленых точках на экране. Однако почему-то кистевой туннельный синдром возникает, а диспетчеры путаются.
Человек-пользователь — ох какой непростой субъект. Он не делает того, чего от него ожидают. Он устает. Он начинает совершать ошибки в стрессовой ситуации, пропускает важные сигналы при монотонной работе, подвергается эмоциям. Он не может найти, казалось бы, очевидные функции. А когда находит, не знает, что с ними делать. И когда сталкивается с собственным незнанием, переносит отрицательные эмоции на систему, которая заставляет его чувствовать себя дураком. Для того, чтобы с этим мириться, и нужны отдельные специалисты, которые и будут этот фактор — так называемый "человеческий фактор" — учитывать.
Я ни в коем случае не хочу сказать, что все активности по обеспечению юзабилити нужно "повесить" на аналитика и точка. Конечно, специально обученный человек сможет решить задачи лучше и в полном объеме — не просто так появились такие роли как UX Analyst и Usability Analyst. Задачи эти сложные и зачастую требуют специальной квалификации, в частности — знания психологии, в том числе когнитивной и социальной. Однако на мой взгляд хороший аналитик должен видеть немного дальше своей колокольни: иногда нужно знать что-то и о тестировании, и о разработке, и об управлении проектом, и даже о поисковой доступности (бывает и такое), а не только о бизнес-анализе.
Еще одной особенностью этого самого юзабилити является невозможность его локализовать и свести к списку требований а-ля "Время реакции системы в таком-то случае должно составлять не менее, чем столько-то секунд". Список "фич", которые доступны в системе — это уже влияние на юзабилити. Разделение на экраны/формы — влияние на юзабилити. Выделение юз-кейсов и определение их детальных шагов, макеты графического интерфейса, визуальная семантика, информационная архитектура… думаю, догадаетесь. Аналитик, создавая описание системы в любом виде — будь то ТЗ, SRS, прототип или каракули на салфетке — неизбежно проектирует взаимодействие пользователя с системой. Поэтому я и ставлю своей целью описать, как можно аналитику оптимизировать результат своей работы с точки зрения юзабилити, как научиться если не решать проблемы, то хотя бы уметь их вовремя увидеть.Всем привет! Спасибо всем, кто принял участие в обсуждении предыдущей статьи. Сегодня мы поговорим о макетах графического интерфейса пользователя. Сразу хочу предупредить, что мыслей на сей счет у меня набралось так много, что они просто не уложились в одну статью. Так что следующая статья (а может быть даже и не одна) будет продолжением темы.
Читать далееСпасибо за статью — коротко и по существу
.
Я сам с самого начала аналитической деятельности всегда использую макеты. И на самом деле еще не встречал людей, которым было бы проще и интересней читать требования, нежели обсуждать макеты. Обычно я и начинаю с макетов, потом описываю различные требования при взаимодействии. Тут главное, чтобы макет всегда соответствовал требованиям, т.е. если меняются требования, надо обязательно отразить это на макете (не прокатит отговорка, что макет — это лишь набросок), т.к. на практике программисты больше внимания уделяют макетам, а не требованиям, соответственно могут быть ошибки при реализации из-за несоответствия макетов требованиям.
Если честно благодаря статье узнал отличия между wireframes и mokups (раньше как-то об этом не задумывался), так что отдельное спасибо за эту инфу.
Если в разговоре возникает ситуация, когда оппоненты, утверждая противоположное, оба выглядят вполне правыми, это признак того, что оппоненты где-то упустили аспект генерализации. Я имею ввиду дискуссию о роли юзабилити и эргономики и их отношения к бизнес-анализу. Вряд ли где-нибудь существует "законодательно" установленная иерархия данных дисциплин, при том, что разглядеть можно столько ракурсов, сколько авторов касается этих тем, однако, раз уж разговор об этом зашел, то предлагаю такое общее видение, которое не дает повода к разногласиям: есть бизнес-анализ — функция в рамках разработки каких-либо проектов, предназначенная для выявления и формализации (то есть представления в по возможности приличном читабельном виде) целей и проблем предметной задачи, и придумывании (изобретении) оптимальных способов их решений (учитывая и реальные возможности разработчика). Юзабилити (синоним эргономики — нечего усложнять, просто один термин приплыл раньше, другой позже) — это неотъемлемая часть решения проекта, логики решения. Понятно, что аналитика в целом чрезвычайно широкая область, и понятно, что в зависимости от масштабов проектов и ресурсов разработчиков эта область может как угодно декомпозироваться на специализации и роли.
О том, что эргономика в прошлом не играла никакой роли, совершенно неверно — например архитектура и промышленный дизайн (когда еще не существовало PC), — это как минимум наполовину чистая эргономика. Архитектор в применении к строительству — это буквальная аналогия бизнес-аналитика в разработке ПО. Кстати, интересный момент — визуальный дизайн в архитектуре является неоспоримой, и даже главной, по распостраненному стереотипу, ее частью. Думаю, что любой дизайнер с настоящей образовательной школой — потенциальный бизнес-аналитик (другое дело, что личные склонности к визуально-чувственной стороне дисциплины у них (как и у архитекторов) часто преобладают над абстрактно-аналитическими).
Насчет святости пользователей (конечных) я бы поспорил. Их доброое отношение и удобство конечно важно, но не стоит их сакрализировать — их мотивы и понятия чаще всего отнюдь не совпадают с целями бизнеса (объективно!), а мы обязаны руководствоваться прежде всего именно последними. Типовому пользователю сразу никогда не понравится что-нибудь, что отличается от его привычек, а тем более, если цели бизнеса требуют перераспределения должностных обязанностей и поддаваться в таких условиях требованиям юзеров, это, пардон, недобросовестно по отношению к Заказчику. А юзера даже при объективно самых лучших предложенных решениях, смиряться и привыкнут к ним только через пару, другую месяцев использования (а в следующий раз будут также насмерть биться уже за них).
Что касается рисования макетов. Я в основном занимаюсь проектированием офисных приложений. У меня никогда не было специальных графических средств, но я перепробовал все известные обще-графические приложения. И в конце-концов остановился … на VS.NET ;) Не для программирования (я не программист) — только ради скринов (прототипирования). Ужасно удобно и быстро, и выглядит прилично … И сразу mokups получаются Никогда не пользуюсь карандошом и бумагой, хотя рисую профессионально (есть в/о в данной области). Для вэба конечно не подойдет, но для деловых приложений — самое то.Юзабилити (синоним эргономики — нечего усложнять, просто один термин приплыл раньше, другой позже)…
Юзабилити и эргономика — это не синонимы. Строго говоря, в русском языке официально вообще нет слова "юзабилити", но достойного аналога ему так и не придумали. Давайте не будем забывать, что эргономика — это все-таки (с самого высокого уровня абстракции) наука о труде, а юзабилити — свойство системы. И если можно еще с натяжкой сказать, что юзабилити-специалисты, как и эргономисты, стремятся добиться высоких показателей по управляемости, обслуживаемости, освояемости и обитаемости систем, то об учете, к примеру, гигиенических показателей у юзабилистов речь не идет.
С юзабилити-инженерией в некотором роде сближается понятие микроэргономики, в том смысле, что вопросы проектирования программных интерфейсов находятся именно в ее компетенции.
Проще говоря, если изображать понятия "эргономика" и "юзабилити" кругами Эйлера, они будут пересекаться, однако эргономика будет значительно больше, а у юзабилити будет и своя область, не связанная с эргономикой.Насчет святости пользователей (конечных) я бы поспорил. Их доброое отношение и удобство конечно важно, но не стоит их сакрализировать — их мотивы и понятия чаще всего отнюдь не совпадают с целями бизнеса (объективно!), а мы обязаны руководствоваться прежде всего именно последними.
Никто и не говорит о сакрализации пользователей. Просто нужно не забывать о том, что помимо целей бизнеса есть еще и цели пользователей. И если на стратегическом уровне их не учитывать, битву за пользователей можно легко проиграть. Если речь идет о системах, в которых попросту у потенциальных пользователей не будет свободы выбора (в вопросе использовать систему или нет), понять своих пользователей нужно все равно. Даже если оставить в стороне вопросы гуманизма, в интересах заказчика (а значит и в ваших) — чтобы пользователи не испытывали недовольства от использования вашего продукта, не искали "окольных путей" везде, где получится, совершали меньше ошибок из-за неудобства интерфейса и т.п.
Вы правы в том, что всегда найдутся пользователи, которые окажутся недовольны изменениями. Однако если предварительное изучение их потребностей способствует тому, что можно предусмотреть хотя бы некоторые подводные камни заранее, почему бы это не сделать? Не говоря уже и о том, что полученная информация даст более комплексный взгляд на проблему и, возможно, позволит предложить заказчику более удачное решение (ну или хотя бы предостеречь его о возможных рисках).
Вы должны авторизироваться для ответа в этой теме.
