Михаил Елфимов об интерфейсах

Алексей Копылов: Результаты экспертной оценки, как и результаты юзабилити-тестирования, состоят из рекомендаций по исправлению интерфейсных ошибок. Заказчик ясно видит недочеты своего продукта. Но при этом он не видит ценных свойств этого же продукта. При самостоятельном исправлении недочетов, он может уничтожить эти ценные свойства, так как он, скорее всего, о них не догадываться. Как этого избежать, то есть как сделать так, чтобы заказчик знал о тех свойствах своего интерфейса, которые обязательно надо сохранить.

Рольф Молик: Это очень серьезный вопрос, о котором я буду говорить на моих курсах. Очень важно, чтобы аналитики не только критиковали интерфейс, но и отмечали его хорошие качества. Ужасно, когда разработчики удаляют функцию, просто потому что никто им не сказал, что пользователям она понравилась. Любой профессионал должен периодически вспоминать песенку Мери Поппинс «Just a spoonful of sugar helps the medicine go down» («Чайная ложка сахара поможет съесть любую таблетку»). При наличии положительных результатов гораздо легче воспринять и отрицательные.

Вопросы Рольфу Молику для издания GUI.RU @gui.ru

Время от времени читатели этого блога пытаются мне помочь, рассказывая какие проблемы есть в интерфейсе блога. Спасибо им за это большое.

Конечно, интерфейс этого блога далеко не идеален. Тут полно ошибок. Я знаю об этих ошибках с самого начала. Но не исправляю их и не собираюсь этого делать.

Дело в том, что этот блог получен путем:

• установки блог-движка WordPress;
• выбора наименее отстойной темы оформления;
• подключения нескольких плагинов;
• импорта записей из Livejournal.

Всё это доступно бесплатно. Всё это я делал своими руками. И этот блог не приносит мне никаких денег. Поэтому я не буду даже пытаться исправить всё что есть неприятного в движке WordPress, бесплатном дизайне и плагинах.

Поэтому, если вы хотите чтобы ваши советы попали в правильные руки, пошлите их автору темы, плагина или движка.

Поймите меня правильно. Я бывший веб-программист (и server-side, и client-side), программист баз данных (SQL, oracle, mysql, postgress и еще несколько), отлично знаю верстку и немного могу рисовать в фотошопе. Я могу написать движок этого сайта вручную, или переписать в движке WordPress всё что мне не нравится.

Но жизнь слишком коротка для этого. Сайт посещают 100 человек в сутки, и никаких миллионов долларов я из-за недостатков сайта не теряю. И адекватность специалиста по юзабилити (в том числе) состоит в том, чтобы решать актуальные проблемы интерфейса.

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

P.S. Все эти рассуждения в корне неприменимы к сайтам дизайн-студий и юзабилити-лабораторий. Для них неприемлемо иметь неудобный сайт с отвратительным дизайном, потому что вот они-то как-раз зарабатывают достаточно денег для того, чтобы иметь приличный сайт.

В каком случае стоит обратиться к юзабилити-консультанту?

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

Такого рода проблемы решает специалист по юзабилити и проектированию интерфейсов.

Что может сделать специалист по юзабилити?

Есть несколько «уровней» работы над интерфейсом.

Уровень 0. На этом уровне работают советы из книг Якоба Нильсена, чек-листы по юзабилити, общие советы по юзабилити. Все ссылки должны быть синего цвета и подчеркнуты, нельзя использовать фреймы, использование flash это плохо, заголовки должны быть большими, и т.д. Это самый начальный уровень, и он может выполняться автоматически, просто на основе чек-листов — списка типичных ошибок в проектировании интерфейса. Не обладает особенной глубиной и имеет ограниченный эффект. Чаще всего изменения носят косметический характер — меняются размеры шрифтов, незначительно меняется расположение элементов страниц, цвета заголовков и текста, и т.д.

Уровень концепции. Все сайты, продукты и услуги создаются для чего-то конкретного. Двери (привет, Дональд Норман) делаются для того, чтобы люди их открывали. Пользователи заходят на сайт и должны с его помощью выполнить определенные задачи, заложенные создателями этого сайта. Программа пишется для того, чтобы решить некоторые проблемы целевой аудитории. Юзабилити-специалист должен понять эти задачи, осознать каким способом их решает продукт сейчас, и предложить лучший способ решения этих задач. Изменения могут включать в себя полное перепроектирование сайта, исключение экранов (страниц) интерфейса, перенос блоков внутри экранов и между экранами.

Уровень экрана (страницы). Проектировщики интерфейсов, как эксперты, оценивают интерфейс по своим профессиональными критериям. Насколько понятно название страницы? Как быстро пользователь найдет на экране нужную функцию? Как должна называться кнопка? Где должны находиться названия полей — сверху, слева, как они должны быть выровнены? Как надо построить меню, где оно должно располагаться? Ответы на все эти вопросы знает проектировщик интерфейсов, ответы зависят от конкретной задачи и не могут быть универсальными. Проектировщик обосновывает каждое решение, которое он принимает, и может объяснить расположение, размер и внешний вид каждого элемента интерфейса.

Что клиент получает в результате работы специалиста по юзабилити?

Клиент получает отчет по юзабилити, в котором перечислены существующие проблемы. Для каждой проблемы объясняется почему это проблема, указываются возможности исправления. Если это возможно, проблемное место перепроектируется так, чтобы уменьшить или исключить проблему.

Примеры экспресс-отчетов (посвященных быстрому нахождению и анализу одной-двух проблем продукта):

• Гостевая книга интернет-провайдера
• Главное меню в Doom, Quake, Half-Life и прочих стрелялках

Чем юзабилити-тестирование отличается от юзабилити-экспертизы?

Юзабилити-тестирование: проводится на пользователях, занимает много времени и ресурсов, стоит бешеных денег. Результаты оказывают сильное влияние на заказчика и разработчиков продукта, потому что показывает что проблемы реально есть, и не у одного человека. Для юзабилити-тестирования пишется сценарий тестирования — то, что надо сказать пользователю чтобы подготовить к тестированию, какие задания выполняет пользователь во время тестирования, и что надо спросить после окончания тестирования. Набираются люди, чаще всего путем заполнения анкеты в интернете, подходящие под целевую аудиторию. Составляется расписание, по которому эти люди приходят в лабораторию, с учетом запасных вариантов: кто-то может не прийти, кто-то может прийти раньше, кто-то опоздать, кто-то приведет друга. Каждого пользователя сажают за компьютер, делают небольшую вводную лекцию и просят выполнить несколько заданий. Процесс может сниматься на камеру, или наблюдаться через полупрозрачное стекло, или наблюдатель просто делает пометки на бумаге по ходу действия. По окончанию пользователю задают вопросы о выполнении заданий и отправляют восвояси. Потом над полученными записями долго работают, чтобы вычленить наиболее общие ошибки и выкинуть второстепенные или незначимые ошибки. Затем составляется отчет.

Что бы там не рассказывали о юзабилити-тестировании «по дешёвке», серьезное тестирование на значительном количестве людей (5-20) занимает уйму времени и нервов, но дает ценные количественные и качественные результаты.

Юзабилити-экспертиза: проводится одним или несколькими экспертами, стоит дешевле тестирования, занимает немного времени, но результат сильно зависит от уровня компетенции экспертов. Не секрет, что большинство узких специалистов неадекватны в более широком смысле. Дизайнер видит в сайте проблемы с использованием цветов и плохой обработкой фотографий. Верстальщик видит проблему в использовании несемантической верстки. Программист считает что библиотека Javascript устарела и сейчас никто так не делает. Даже проектировщики интерфейсов чрезмерно увлекаются и находят в сайте огромное количество мелких проблем, которые не влияют на конечный результат критическим образом. Поэтому основное требование к эксперту — адекватность и умение отделять реальные проблемы от сделанного не лучшим образом.

Экспертиза, выполненная адекватным экспертом (или несколькими экспертами), даёт не менее ценный результат, чем тестирование на людях, но при этом занимает гораздо меньше времени и стоит дешевле.

Есть вопросы? Задавайте в комментариях.

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

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

Что такое юзабилити? Это оптимизация. Специалист смотрит на сайт, продукт, услугу со стороны пользователя. Не глазами пользователя (всё-таки специалист обладает экспертными навыками), но с его стороны. На сайте есть ключевые точки, которые больше всего влияют на конверсию. В продукте есть места, которые могут стать критическими для решения поменять софт. Пользователи могут использовать ваш сайт не совсем так, как вы это себе представляете. Всё это убытки.

Когда, как не во время кризиса оптимизировать своих рабочих лошадок?

Наверное, по аналогии с дизайнерами, люди часто спрашивают у меня портфолио. Однако, поскольку я не дизайнер, то и портфолио у меня никакого нет. И вот почему.

Дело в том, что результат работы по проектированию интерфейса — наброски (эскизы) интерфейса и спецификация интерфейса. Эти вещи отдаются заказчику и как-бы закрытая информация. Т.е. понятно, что по ним потом сделают готовый сайт. Но этот сайт — не результат работы проектировщика.

Во-первых, это уже не совсем то, что нарисовал проектировщик. Над сайтом поработал дизайнер, программисты, менеджер проекта, руководитель фирмы. Даже если проектировщик работает в той же фирме и может в конце указать что сделано не по макету, не факт что всё именно так и сделают. Тем более если проектировщик работает «снаружи» и не имеет возможности повлиять на реализацию своих макетов.

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

Поэтому, мы стоим перед тем фактом, что конечный продукт разработки (сайт или софт) проектировщик не может поместить в портфолио потому, что это не то, что он проектировал, а макеты нельзя показывать, потому что это внутренняя информация заказчика.

То же самое, только в большей степени, относится к отчету о юзабилити. За этот документ люди платят деньги, и выкладывать его в открытый доступ как-то нехорошо. Опять же, показывать результирующий продукт (сайт или софт) тоже не получится — рекомендации это одно, а что из них реализовано — другое.

Поэтому у меня нет портфолио.

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

Это к двум предыдущим постам, и рубрике «Сделаем окружающее лучше».

Может и вы замечаете такие вещи, и тоже поделитесь какими-нибудь решениями?

На сайте местного провайдера Flex есть гостевая книга (сообщения порезаны, чтобы сделать страницу покороче):

Для чего нужна гостевая книга? Люди заходят туда, когда у них не работает интернет, чтобы:

• увидеть, известно ли об этой проблеме от других пользователей и ведется ли работа над проблемой;
• сообщить о проблеме;
• получить ответ от поддержки.

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

Так выглядит форма отправки сообщения:


Что можно изменить?

• Написать, что мыло не будет публиковаться в гостевой книге, и что на него придет ответ поддержки. Сейчас этот адрес отправляет в гостевую книгу и виден всем. Привет, спамеры. Я бы не стал оставлять своё мыло, тем более что непонятно, для чего оно тут — будет ли на него ответ?
• Чтобы люди не забывали указывать номер договора и другие контакты, нужно убрать сверху длинный бесполезный текст и добавить на форму поле «Номер договора».
• Сделать древовидные комментарии, свернутые по умолчанию. Сейчас в сообщениях часто заметен текст типа «To Cluster», когда пользователи пытаются ответить на сообщения поддержки. Было бы удобнее, если бы пользователи могли отвечать на ответ поддержки, чтобы не плодить новые сообщения, непонятные без контекста.

В результате, вот так должна выглядеть гостевая книга:


Предлагаю не обращать внимания на такие мелочи, как использование ссылок различного цвета, использование синего цвета (цвета ссылок) для выделения текста, идиотскую навигацию по страницам и прочее. Понятно, что это тоже надо исправлять.

Игры, в том числе стрелялки от первого лица (они же First Person Shooters), очень сильно изменились за последние 10 лет. Но больше всего изменений пришлось на игровую начинку. Главное меню, с которого начинается знакомство с игрой, все эти годы остается неизменным.

Так выглядело меню «Half-Life» в 1998 году:


Так выглядело меню «Quake 4» в 2005 году:


Так выглядит меню «Half-Life 2 Episode One» в 2007 году:


Как можно сделать лучше это меню?

В целом, есть два сценария использования:

• игра запускается в первый раз, пользователь начинает новую игру
• игра запускается не в первый раз, пользователь загружает сохраненную игру

Отсюда получаем два вида меню. Первое показывается при первом запуске игры, сразу после установки. Второе показывается когда пользователь уже начал играть и появились сохраненные игры.

Первый запуск



Понятно, что при первом запуске сохраненных игр еще нет. Чтобы не заставлять пользователя тыкать лишний раз в меню, показываем выбор уровня сложности сразу.

Следующий запуск



При следующем запуске игрок скорее всего захочет загрузить одну из сохраненных игр. Поэтому кнопку для начала новой игры делаем второстепенной. Сразу показываем список сохранений, подсвечиваем последний по времени или сделанных вручную игроком (если есть ручные и автосейвы).

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

Пожалуйста, покажите это кому-нибудь в Id Software (Doom, Quake), Valve Corporation (Half-Life) или Infinity Ward (Call of Duty), чтобы мы наконец уже увидели человеческое меню в этих играх.