Слово «Юзабилити» будоражит умы. Тут и там слышно «неюзабельно», появилось много рекомендаций на тему повышения юзабилити ресурсов, множество адептов культа юзабилити, множество молодых будущих юзабилистов. Слово окутано пеленой таинственности. Мистическое знание о том, как делать юзабилити, хотят получить все больше людей. Возникают вопросы о том, как продавать юзабилити, как внедрять юзабилити, как юзать юзабилити.
У меня возникают другие вопросы. Что такое юзабилити, как его потрогать? В чем мерить юзабилити? Как верифицировать оценочные суждения «юзабельно-неюзабельно» помимо тестирования результатов на респондентах? В какой точке процесса разработки находится этап юзабилити? Почему лучшая из прочитанных мной книг по юзабилити не использует этот термин и называется «Веб дизайн»? Вот на них я и попытаюсь ответить, заодно перевернув все с ног на голову. Или наоборот.
Русский язык богат понятиями. Тем не менее, мы таскаем термины из английского языка, производим кальку, а потом мучаемся с ней. Например, что такое design? Это разработка, проектирование, конструирование, рисование, моделирование и даже разработка плана и образца изделия. Англоговорящее население планеты остается только пожалеть. Но вдвойне жаль тех, кто игнорирует все это множество именований, используя кальку «дизайн» в русском языке. С юзабилити – та же терминологическая ловушка.
В попытках перевести термин на русский язык рожден ряд уродцев, таких как «удобопользование» или «удобство использования». Эти термины хороши тем, что ничего объективного не значат, ни в чем не измеряются и поэтому не затрагивают ореол таинственности вокруг модного термина. В то время как в русском языке давно и прочно существуют такие понятия как «эксплуатационная пригодность» и «эксплуатационные свойства».
Разочарование и негодование будут мне ответом, не сомневаюсь. Где же мистика, где волшебство? Это совсем не о том, не правда ли? Не правда. В отличие от юзабилити, с эксплуатационными свойствами продукта можно работать и количественно, и качественно. И, черт возьми, всем понятно, что это такое. Достаточно сравнить результаты выдачи по запросу «эксплуатационные свойства» и запросу «юзабилити» чтобы понять пропасть конкретики, разделяющую эти материалы.
Самый большой подвох здесь, конечно, коммерческого характера. Мистические знания стоят дорого. Да, здравомыслящее большинство не пользуется услугами экстрасенсов, но их услуги все же востребованы, есть рынок. Значит, таинство юзабилити есть, кому продать. А работы по повышению эксплуатационных свойств должны быть подтверждены результатом. В отличие от услуг экстрасенса, которому позволительно ошибаться, если у заказчика плохая карма. Ни чем здесь не могу помочь, как человек, имеющий отношение к продаже своих услуг, я делаю моральный выбор в пользу технологии, а не шарлатанства.
Итак, что же значит разработка на основе эксплуатационных свойств? Для меня очевидно, что юзабилити в таком понимании – это идеология процесса разработки. Это не этап, который может взять на себя внешний эксперт, также как разработку на основе качества или разработку на основе знаний. На каждом из этапов разработки это даже не методы и практики, это фиксация на определенных целях.
1. На этапе сбора требований это означает, что мы уделяем максимальное внимание ожиданиям пользователей. Функциональная насыщенность приложения нас интересует меньше, чем цели и задачи пользователя, способы их достижения. Любая идея о добавлении функции проходит прокрустово ложе вопросов «для кого» и «зачем». Необходимый и достаточный список функциональности определяется только эксплуатационными характеристиками системы. Мы задвигаем заказчика с его идеями о полезных галочках так далеко, как сумеем, оставив за ним определение целевой аудитории продукта и целевых задач бизнеса.
2. На этапе проектирования системы мы фокусируемся на взаимодействии пользователя с системой. Известно, что хороший инструмент имеет одну кнопку, но идеальный – ни одной. Хороший инструмент не является многофункциональным. Швейцарские ножи плохи в качестве ножей. Но если уж нужен швейцарский нож, давайте озаботимся, чтобы пилочка для ногтей не совмещалась с мачете. Даже если это нереализуемо с точки зрения спроектированной архитектуры приложения – тем хуже для архитектуры.
3. Прорабатывая графический дизайн системы, мы ограничиваем творческий полет художественного вдохновения жесткими рамками эксплуатационных свойств. Очень жесткими рамками. Ни одному дизайнеру внешнего вида автомобилей не придет в голову творить свободно. Наши дизайнеры теперь тоже попали.
4. На этапе разработки мы пресекаем все креативные порывы разработчиков из разряда «эта галочка здесь просилась, а написать было – раз плюнуть». Мы отрываем руки за «это писать было – месяц, я сделал проще за 5 минут, добавив окошко». Но всячески поощряем обсуждение идей из разряда «слушай, мне бы это было неудобно, давай вот тут все переделаем вот так, я быстро, за выходные».
5. На этапе тестирования мы, наряду с функциональными, нагрузочными и прочими тестами проводим тестирование эксплуатационных характеристик. У нас есть метрики, которым система должна соответствовать с точки зрения пользовательского взаимодействия, наши тестовые кейсы основаны на целях пользователя. Ошибки с заключением «это не баг, а фича» остаются ошибками и повышаются в приоритете. Тестировщик получает полное право, и даже обязанность, быть «идиотом, не понимающим, как работает система».
И где здесь место для юзабилиста? Кто он вообще такой, при таком раскладе? Не кажется ли недостаточным для придания продукту необходимых эксплуатационных свойств привлечь эксперта, продуктом работы которого являются вайрфреймы интерфейса? Отказано, каждый в команде должен быть пропитан духом юзабилити, вне зависимости от своей функциональной роли.
Демистификация и десакрализация юзабилити – лишь вопрос времени. Короткого времени. Очень короткого времени. Если вы только собираетесь стать «юзабилистом», лучше не делайте этого. Получите знания о том, как делать конкретную работу ориентированной на эксплуатационные характеристики продукта. Пожалуйста, стремитесь быть хорошим аналитиком, проектировщиком, программистом, тестировщиком или менеджером. Не юзабилистом. Нет такой специальности, есть такой образ мышления и такая идеология работы. Но хороший человек – это не профессия.
У меня возникают другие вопросы. Что такое юзабилити, как его потрогать? В чем мерить юзабилити? Как верифицировать оценочные суждения «юзабельно-неюзабельно» помимо тестирования результатов на респондентах? В какой точке процесса разработки находится этап юзабилити? Почему лучшая из прочитанных мной книг по юзабилити не использует этот термин и называется «Веб дизайн»? Вот на них я и попытаюсь ответить, заодно перевернув все с ног на голову. Или наоборот.
О терминологии
Русский язык богат понятиями. Тем не менее, мы таскаем термины из английского языка, производим кальку, а потом мучаемся с ней. Например, что такое design? Это разработка, проектирование, конструирование, рисование, моделирование и даже разработка плана и образца изделия. Англоговорящее население планеты остается только пожалеть. Но вдвойне жаль тех, кто игнорирует все это множество именований, используя кальку «дизайн» в русском языке. С юзабилити – та же терминологическая ловушка.
В попытках перевести термин на русский язык рожден ряд уродцев, таких как «удобопользование» или «удобство использования». Эти термины хороши тем, что ничего объективного не значат, ни в чем не измеряются и поэтому не затрагивают ореол таинственности вокруг модного термина. В то время как в русском языке давно и прочно существуют такие понятия как «эксплуатационная пригодность» и «эксплуатационные свойства».
Разочарование и негодование будут мне ответом, не сомневаюсь. Где же мистика, где волшебство? Это совсем не о том, не правда ли? Не правда. В отличие от юзабилити, с эксплуатационными свойствами продукта можно работать и количественно, и качественно. И, черт возьми, всем понятно, что это такое. Достаточно сравнить результаты выдачи по запросу «эксплуатационные свойства» и запросу «юзабилити» чтобы понять пропасть конкретики, разделяющую эти материалы.
Самый большой подвох здесь, конечно, коммерческого характера. Мистические знания стоят дорого. Да, здравомыслящее большинство не пользуется услугами экстрасенсов, но их услуги все же востребованы, есть рынок. Значит, таинство юзабилити есть, кому продать. А работы по повышению эксплуатационных свойств должны быть подтверждены результатом. В отличие от услуг экстрасенса, которому позволительно ошибаться, если у заказчика плохая карма. Ни чем здесь не могу помочь, как человек, имеющий отношение к продаже своих услуг, я делаю моральный выбор в пользу технологии, а не шарлатанства.
Разница в подходах
Итак, что же значит разработка на основе эксплуатационных свойств? Для меня очевидно, что юзабилити в таком понимании – это идеология процесса разработки. Это не этап, который может взять на себя внешний эксперт, также как разработку на основе качества или разработку на основе знаний. На каждом из этапов разработки это даже не методы и практики, это фиксация на определенных целях.
1. На этапе сбора требований это означает, что мы уделяем максимальное внимание ожиданиям пользователей. Функциональная насыщенность приложения нас интересует меньше, чем цели и задачи пользователя, способы их достижения. Любая идея о добавлении функции проходит прокрустово ложе вопросов «для кого» и «зачем». Необходимый и достаточный список функциональности определяется только эксплуатационными характеристиками системы. Мы задвигаем заказчика с его идеями о полезных галочках так далеко, как сумеем, оставив за ним определение целевой аудитории продукта и целевых задач бизнеса.
2. На этапе проектирования системы мы фокусируемся на взаимодействии пользователя с системой. Известно, что хороший инструмент имеет одну кнопку, но идеальный – ни одной. Хороший инструмент не является многофункциональным. Швейцарские ножи плохи в качестве ножей. Но если уж нужен швейцарский нож, давайте озаботимся, чтобы пилочка для ногтей не совмещалась с мачете. Даже если это нереализуемо с точки зрения спроектированной архитектуры приложения – тем хуже для архитектуры.
3. Прорабатывая графический дизайн системы, мы ограничиваем творческий полет художественного вдохновения жесткими рамками эксплуатационных свойств. Очень жесткими рамками. Ни одному дизайнеру внешнего вида автомобилей не придет в голову творить свободно. Наши дизайнеры теперь тоже попали.
4. На этапе разработки мы пресекаем все креативные порывы разработчиков из разряда «эта галочка здесь просилась, а написать было – раз плюнуть». Мы отрываем руки за «это писать было – месяц, я сделал проще за 5 минут, добавив окошко». Но всячески поощряем обсуждение идей из разряда «слушай, мне бы это было неудобно, давай вот тут все переделаем вот так, я быстро, за выходные».
5. На этапе тестирования мы, наряду с функциональными, нагрузочными и прочими тестами проводим тестирование эксплуатационных характеристик. У нас есть метрики, которым система должна соответствовать с точки зрения пользовательского взаимодействия, наши тестовые кейсы основаны на целях пользователя. Ошибки с заключением «это не баг, а фича» остаются ошибками и повышаются в приоритете. Тестировщик получает полное право, и даже обязанность, быть «идиотом, не понимающим, как работает система».
И где здесь место для юзабилиста? Кто он вообще такой, при таком раскладе? Не кажется ли недостаточным для придания продукту необходимых эксплуатационных свойств привлечь эксперта, продуктом работы которого являются вайрфреймы интерфейса? Отказано, каждый в команде должен быть пропитан духом юзабилити, вне зависимости от своей функциональной роли.
Немного выводов
Демистификация и десакрализация юзабилити – лишь вопрос времени. Короткого времени. Очень короткого времени. Если вы только собираетесь стать «юзабилистом», лучше не делайте этого. Получите знания о том, как делать конкретную работу ориентированной на эксплуатационные характеристики продукта. Пожалуйста, стремитесь быть хорошим аналитиком, проектировщиком, программистом, тестировщиком или менеджером. Не юзабилистом. Нет такой специальности, есть такой образ мышления и такая идеология работы. Но хороший человек – это не профессия.
