«Как программист, так и пользователь компьютера, я твердо убежден, что компьютеры должны быть проще в использовании, чем они», — говорит Джефф Джонсон.
Хммм … делает компьютеры проще в использовании, а? Звучит как отличная идея. Но удалось ли Джеффу достичь этой цели, которую он поставил перед тем, как искать работу после аспирантуры? SitePoint решил задать Джеффу несколько вопросов, чтобы узнать больше о том, чего именно он достиг. В конце концов, до сих пор он председательствовал только на международных конференциях, работал в некоторых ведущих компаниях мира, являлся автором и автором бесчисленных статей и книг, а теперь является президентом консалтинговой фирмы по удобству использования продуктов, которую он основал в 1996 году.
SitePoint: Привет, Джефф, спасибо, что поговорил с нами. Я хотел бы начать с вопроса о том, как вы впервые столкнулись с проблемами юзабилити. Что заставило вас принять решение попасть в эту область?
В колледже (Йельский университет) и аспирантуре (Стэнфорд) я изучал когнитивную психологию и информатику — эту комбинацию часто называют когнитивной наукой. Тогда я заинтересовался разработкой компьютерных моделей того, как люди рассуждают и решают проблемы.
Но когда я приблизился к окончанию аспирантуры, я понял, что возможности трудоустройства в когнитивной науке были ограничены. Однако были значительные возможности в области взаимодействия человека с компьютером. Это было в конце 1970-х, когда индустрия микрокомпьютеров (также известная как персональные компьютеры) только начинала. Компьютерные и телекоммуникационные компании нанимали людей, которые имели такой же опыт, как и я, чтобы облегчить использование их компьютерных систем.
Как программист и пользователь компьютера, я твердо убежден, что компьютеры должны быть проще в использовании, чем они были. Это чувство в сочетании с широкими возможностями работы заманило меня в область пользовательского интерфейса.
Я пошел работать в 1978 году в небольшую микрокомпьютерную компанию в Силиконовой долине под названием Cromemco. Он был основан несколькими годами ранее двумя студентами-электротехниками Стэнфорда. Им нужен был кто-то, чтобы разрабатывать простые в использовании программные приложения и следить за удобством использования аппаратных компонентов, таких как клавиатуры. Поскольку в Cromemco было очень мало программистов, я должен был быть и дизайнером, и программистом для многих проектов. Я разработал для них текстовое, статистическое и графическое программное обеспечение.
Затем, в середине 1980-х, я покинул Cromemco, чтобы работать в Xerox. Я работал не в их знаменитом исследовательском центре в Пало-Альто, а в отделе офисных систем, который отвечал за превращение технологии PARC в продукты. Я работал над преемниками революционной, но неудачной рабочей станции Star Xerox. Как и в Cromemco, я был дизайнером и разработчиком пользовательского интерфейса.
После нескольких лет работы в «Университете ксерокса» я перешел на исследовательские должности в US West (телефонная компания, теперь называемая Qwest Communications), а затем в Hewlett-Packard Labs. Вскоре после того, как HP Labs распустила свою исследовательскую группу по взаимодействию между человеком и компьютером в 1992 году, я перешел к секретному отделению Sun Microsystems под названием «FirstPerson».
FirstPerson была попыткой Sun расширить свой бизнес за пределы компьютеров в электронную бытовую технику. Основатели FirstPerson разработали новый язык под названием «Oak» (теперь Java). Я был главным юзабилити: я помогал проектировать прототипы и тестировать их на реальных людях. Прототипы были такими вещами, как телевизионные приставки, онлайн-сервисы видео по запросу и тому подобное. Нам даже не разрешили поговорить с другими сотрудниками Sun о том, что мы делаем. Вскоре после того, как FirstPerson стал JavaSoft, я ушел, чтобы создать собственную консалтинговую компанию UI Wizards.
SP: Вы цените знания пользователей о программном обеспечении по сравнению с юзабилити? Увеличивает ли это знание удобство использования продукта с течением времени?
Люди очень легко адаптируются: они могут многому научиться, когда мотивированы. Вопрос в том, когда они мотивированы? Я не думаю, что каждый программный продукт должен быть настолько простым, чтобы все его функции были мгновенно доступны. Скрипки и автомобили серьезно учатся пользоваться. Некоторые люди изучают их; другие борются. Но люди, которые учат их, любят то, что они могут сделать.
Когда люди используют программное обеспечение на рабочем месте, они часто не выбирают его. Им дано использовать, как требование их работы, и поэтому они мотивированы, чтобы научиться использовать его. Если это займет немного времени, чтобы освоить, это, вероятно, хорошо. Но помните: работодатель купил программное обеспечение для повышения производительности труда. Если программное обеспечение учится вечно, подвержено ошибкам или просто утомительно или мучительно в использовании, производительность снижается. Таким образом, у работодателей и сотрудников есть причины хотеть, чтобы программное обеспечение поддерживало, а не мешало реальной работе.
Программное обеспечение для дома — это отдельная история. Здесь почти нет мотивации учиться. Если вы не можете понять что-то быстро, вы довольно быстро от него откажетесь. Пользователи сети еще менее терпимы к услугам, которые трудно использовать. Зачем бороться, когда есть несколько десятков (или нескольких сотен) других сайтов, предлагающих то же самое для меньших хлопот? Мы просто нажмем «Назад» и пойдем куда-нибудь еще.
Что касается знаний, влияющих на удобство использования программного обеспечения, исследования показали, что когда люди говорят, что они «используют» программный продукт, это фактически означает, что они знают, как использовать лишь небольшую часть всей функциональности этого программного обеспечения. Как только большинство людей учатся достаточно для достижения своих целей, они придерживаются этого и редко удосуживаются узнать гораздо больше. Например, почти никто не использует возможности таблиц стилей Microsoft Word. Большинство людей оставляют все абзацы «Обычный» и устанавливают шрифты, поля и другое форматирование напрямую.
SP: Считаете ли вы, что дизайнеры сопротивляются принципам юзабилити? Если так, что можно сделать, чтобы убедить дизайнеров в важности соблюдения принципов юзабилити?
Большинство разработчиков считают, что удобство использования стоит дополнительного времени. Они всегда находятся под напряжением, поэтому все, что стоит дополнительного времени, плохо. Фактически, использование ориентированного на пользователя дизайна с самого начала проекта может сэкономить время. Он помогает вам понять, что действительно нужно пользователям, поэтому вы можете предоставить именно это, а не проектировать и создавать множество функций, которые никто не будет использовать.
Во-первых, никогда не бывает времени сделать это правильно, но всегда есть время сделать это, когда клиенты бросают это вам в глаза. Даже если уделять больше внимания удобству и простоте использования заранее, время выхода на рынок сокращается, но это может сократить время получения прибыли, поскольку более полезный продукт имеет:
- более быстрое принятие на рынок (т.е. более высокие начальные продажи), и
- снизить затраты на поддержку клиентов.
Наконец, когда клиентам действительно нравится продукт, они лояльны. Напротив, когда они едва переносят продукт, они мгновенно переключаются на вашего конкурента. Юзабилити способствует лояльности клиентов.
Разработчики также иногда сопротивляются руководству по пользовательскому интерфейсу из-за проблем управления: они видят, что дизайнеры пользовательского интерфейса отнимают у них контроль. Если бы они думали рационально, а не эмоционально, они бы поняли, что продукты лучше, когда члены команды делятся своими лучшими навыками, и что их навыки в реализации, а не в дизайне пользовательского интерфейса. К счастью, после того, как я провел программистов через процесс разработки, ориентированный на пользователя (иногда пинающий и кричащий), они обычно «видят свет» и даже испытывают облегчение, что кто-то еще выполняет тяжелую работу из своего списка задач.
SP: Ваша книга, GUI Bloopers , иллюстрирует типичные подводные камни в дизайне пользовательского интерфейса. Можете ли вы сказать мне, что является самой распространенной ошибкой дизайнеров? Как они могут избежать этого?
Трудно выбрать наиболее распространенную ошибку, но наиболее сильным кандидатом на это различие является «Speaking Geek». Этот блок возникает, когда сообщения об ошибках, имена команд и инструкции пишутся на языке программиста, а не в терминах, которые имеют смысл для пользователей. Одной из причин этого блока в сообщениях об ошибках является неспособность перевести низкоуровневое межплатформенное взаимодействие в нечто, относящееся к тому, что пользователь пытался сделать. Вот почему мы видим исключения Java, появляющиеся в сообщениях об ошибках.
Основной причиной этого блока является неправильное управление: назначение работы по написанию программного текста программистам, очевидно, не является предпочтительным вариантом. Программисты хороши в написании кода; они, как правило, плохо умеют писать текст. Кто? Технический писатель. Весь текст в программном обеспечении должен быть написан или, по крайней мере, проверен техническими авторами до того, как программное обеспечение выйдет на улицу.
SP: В какой момент дизайнеры и разработчики зашли слишком далеко, пытаясь сделать программу «удобной для пользователя»? Где найти баланс?
Существует множество способов сделать дизайн пользовательского интерфейса «чрезмерным». Один из них — уделять столько времени заботам о графическом виде, что вы не уделяете достаточного внимания более важной части пользовательского интерфейса: взаимодействию и потоку задач. Вот почему командам разработчиков программного обеспечения нужны дизайнеры взаимодействия, а не только графические дизайнеры. Это также причина, по которой я рекомендую начинать дизайн пользовательского интерфейса, сначала разработав концептуальную модель, которая поясняет, что делает программное обеспечение, а не прыгает прямо в эскизы экранов и размещает виджеты.
Другой способ зайти слишком далеко с юзабилити — это провести юзабилити-тестирование, когда вы не собираетесь ничего делать с проблемами, которые обнаруживают тесты. Это просто трата времени и денег. Хотелось бы сказать, что никто не делает эту ошибку, но это довольно часто.
Наконец, дизайнеры пользовательского интерфейса иногда выходят из-под контроля, когда им не удается определить приоритеты проблем, которые они обнаруживают в тестах на удобство использования или обзорах. Некоторые проблемы важнее других. Разработчикам нужны приоритетные списки проблем, чтобы они могли сосредоточиться на важных и оставить другие на потом. Тем не менее, некоторые проблемы с низким приоритетом также легко исправить, например, изменив имя команды меню.
С.П .: Нет сомнений в том, что повышение юзабилити веб-сайта может привести к увеличению числа пользователей и повторному трафику. Однако, как веб-дизайнеры могут убедить своих клиентов, что это так, и что инвестиции в юзабилити-тестирование окупятся?
Есть книга под названием «Экономичность и простота использования», написанная Биасом и Мэйхью. Это предварительный веб-сайт, но экономические аргументы все равно будут применяться к веб-сайтам.
Иногда, однако, единственное, что действительно передает сообщение, — это «школа жестких ударов»: создание плохого, отвратительного веб-сайта и заставление людей держаться подальше от толпы. Это обычно привлекает внимание руководства.
SP: Кто является крупными игроками в юзабилити и какие сайты вы регулярно посещаете по этой теме?
На своем консультационном веб-сайте я перечисляю несколько удобных книг по дизайну пользовательского интерфейса — «крупные игроки» — это, в основном, люди, написавшие эти книги. В моей области большинство людей считают таких исследователей, как Дуг Энгельбарт (SRI в 1960-е годы), Стюарт Кард (Xerox PARC), Джим Фоли (штат Джорджия) и Бен Шнейдерман (штат Мэриленд), источником большей части дисциплины. мудрость. Конечно, есть практикующие, которые стали знаменитыми даже за пределами области пользовательского интерфейса, такие как Якоб Нильсен, Алан Купер и Дон Норман.
Сайты, которые я посещаю регулярно? Ну, есть сайт Якоба Нильсена . Есть Дей Александр, консультант по пользовательскому интерфейсу в Австралии, на сайте которого есть ежедневный веб-блогер . Есть Зал стыда пользовательского интерфейса , которым управляет консультант по пользовательскому интерфейсу Брайан Хейс. Кроме того, замечательный ресурс Кейта Инстоуна, посвященный юзабилити в Интернете Есть сайт с графическим интерфейсом Bloopers , которым руководит издатель моей книги, и, наконец, сайт Винсента Фландерса .
SP: Программное обеспечение, подобное Macromedia Flash, имеет репутацию создателя непригодных для использования веб-сайтов. Будет ли это преодолено или это создаст еще большие проблемы?
Небольшая анимация может быть хороша на веб-сайте, но это легко переоценить. К сожалению, многие сайты, которые используют Flash, делают именно это. Кроме того, многие Flash-сайты не предоставляют альтернативы для посетителей, у которых нет Flash.
Многие дизайнеры думают, что люди получат Flash только для того, чтобы увидеть их замечательный контент, но они совершенно не правы. Большинство людей не знают, как получить Flash, и даже если они знают, они предполагают (вероятно, правильно), что попытка установить его превратится в трудоемкий кошмар, как это делают многие установки программного обеспечения. Таким образом, они не беспокоятся и упускают содержание. Кто проигрывает? Не пользователи.
SP: Исходя из вашего обширного опыта, что бы вы сказали тем, кто хочет работать в области юзабилити?
В общем, лучший способ проникнуть в поле — это тестирование юзабилити. Проведение юзабилити-тестов — отличный способ узнать, что работает, а что нет. Это даст вам опыт, необходимый для редизайна программного обеспечения или разработки с нуля.
Люди также приходят в поле из других смежных областей:
- графический дизайн: они устают рисовать иконки и металлические кнопки и хотят что-то сделать для взаимодействия.
- техническое письмо: они понимают, что программное обеспечение, которое трудно объяснить, вероятно, плохо спроектировано, поэтому они начинают участвовать в разработке.
- программирование: они разочарованы созданием вещей, которые никому не нравятся, и хотят добиться большего.
На нынешнем рынке труда я бы посоветовал не пытаться стать консультантом — даже опытным консультантам сложно найти достаточно работы. Вместо этого ищите работу в компании.
SP: Спасибо за совет, Джефф. Наконец, вы можете сказать нам, что дальше для удобства использования? Можете ли вы предсказать, что будет через два года, через пять лет? Будет ли Интернет усложнять работу юзабилити-экспертов?
Прогнозы легко сделать, но редко верны. Телешоу «The Jetsons» было установлено в 1999 году. Где наши летающие машины, реактивные ранцы и еда в трубе? Имея это в виду, вот некоторые прогнозы:
- Некоторые общие функции в Интернете стабилизируются (например, корзины для покупок) и будут приняты браузерами. Тогда сайтам нужно будет только указать, что они имеют функцию, и браузер будет обрабатывать ее.
- Распознавание речи станет лучше и станет более широко использоваться для взаимодействия с компьютерами. Но люди не будут думать о них как о компьютерах, просто как об услугах.
- Компьютеры начнут исчезать в информационных устройствах специального назначения.
- Сотовые телефоны получат больше функций КПК.
- Различие между программным обеспечением для настольных компьютеров и веб-службами на основе браузера исчезнет, поскольку все большее число приложений станет подключенным к Интернету. Все больше и больше приложений будут общаться с базами данных и другими приложениями через Интернет, незаметно для пользователей.
- Спам будет увеличиваться без ограничений до такой степени, что грозит обрушить интернет.
SitePoint благодарит Джеффа за разговор с нами. Убедитесь, что вы ищете его следующую книгу!