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

О заголовках постов @elfimov.com/everything

Судя по всему, существует два подхода к заголовкам записей в блоге: подход Livejournal и подход RSS.

Изначально в Livejournal на заголовки ничего не завязано. Их можно писать, можно не писать. Просматриваешь отдельный пост — в TITLE выводится начало поста, если нет заголовка. Просматриваешь свой дневник или ленту друзей — посты показываются полностью, вместе с текстом, и надобности в заголовке особенной нет. Заголовки пишут немногие, и более привычно пробежать по диагонали пост, чтобы определиться интересен ли он. Интересно, что «профессиональные» блоггеры используют картинки в начале поста чтобы привлечь внимание — явное свидетельство что заголовки мало кого цепляют.

Фактически, заголовки постов используются только в архиве записей за определенный месяц и в некоторых темах оформления выводится summary постов на странице. Даже сервис blogs.yandex.ru спроектирован так, чтобы избегать заголовков — в топ записей выводятся цитаты из текста, а не заголовки.

В RSS-читалках, спроектированных программистами, заголовки используются очень широко. Обычно программа показывает список заголовков, и уже при просмотре одного из них отображается текст, обычно это не полный текст статьи, и для просмотра приходится переходить на сайт источника. В таких программах заголовки очень важны — без них отображение списка теряет смысл. Блоггеры, которых нацелены на RSS-читателей, очень серьезно относятся к заголовкам — это их хлеб.

RSS-сервисы, вроде Яндекс.Ленты или Google Reader, спроектированы думающими людьми. Поэтому посты отображаются так, как это принято в популярных блогохостингах — заголовок, потом полностью раскрытый текст (если он отдается RSS-источником). Тут заголовки — приятное дополнение.

Таким образом, писать или не писать заголовки — исключительно вопрос выбора аудитории. Если ваш блог находится в Livejournal или копируется туда автоматически — заголовки необязательны. Если у вас отдельностоящий блог, и аудитория пользуется традиционными RSS-читалками — заголовкам надо уделять серьезное внимание.

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

Сайты, приносящую реальную пользу людям — это хороший веб. Они сделаны для людей, их создатели думали о реальных потребностях людей, и живые люди видны за этими сайтами. Это делает интернет лучше, человечнее.

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

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

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

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

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

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

Примеров может быть очень много: одноклассники, мамба, тут и многочисленные клоны Facebook и LinkedIn. Когда создатели этих сервисов говорят, что они не просто скопировали оригинал, но адаптировали его к российскому рынку — они не имеют в виду, что сделали сайт удобнее для российских пользователей. В их понятии адаптация означает перестройку под популярные в рунете способы перегона посетителей в деньги. Это злые сайты, бесполезные сервисы и плохой веб.

Всегда будут люди, которые будут делать бизнес на грязном SEO, спаме и злых сервисах. Они делают веб плохим. Вопрос лишь в том, хотим ли мы участвовать в этом. Я думаю, каждый IT-специалист должен отдавать себе отчет в том, делает ли он веб лучше или хуже. И принимать осознанное решение о том, какие сайты он увидит в интернете завтра.

Артем Горбунов о слове «юзабилити»@artgorbunov.ru

Читаю что там написал Горбунов, читаю что написал Копылов, и не понимаю обоих. Вероятно, это означает что я далек от понимания юзабилити у обоих авторов.

Что для меня юзабилити? Юзабилити — это способ обеспечить соответствие продукта нуждам клиента и пользователей. Причем именно так — не только пользователей, но и клиента, потому что продукт находится на стыке их интересов.

Есть гениальные дизайнеры, гениальные программисты и гениальные менеджеры (наверное). Это профессионалы, которые понимают для чего они рисуют дизайн, пишут программы и руководят проектами. Хороший дизайнер узнает все о той области, для которой он рисует дизайн. Хороший программист вникнет во все бизнес-процессы, которые он автоматизирует. Хороший менеджер построит процесс так, чтобы было реализовано наиболее важное для клиентского бизнеса.

Проблема в том, что большинство людей в IT представляют собой средний уровень. Это не проблема индустрии, это совершенно нормальное явление — когда что-то делается на потоке, невозможно найти такое количество гениальных исполнителей. Большинство людей просто не понимают что и зачем они делают в IT. Средний дизайнер запросто сделает первую страницу поисковика на флеше и с огромными картинками. Средний программист напишет невероятно сложную систему для обмена смайликами. Чтобы обеспечить хоть какое-то среднее качество, по отрасли в целом, и придумали юзабилити.

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

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

Если нужен визуально богатый сайт, совершающий прорыв в своей области — надо обращаться к гениальным дизайнерам. Если нужен средний сайт, соответствующий представлениям пользователей — надо обращаться к юзабилити-специалистам. И те и другие — специалисты в своей области.

P.S. Я не знаю, насколько тут можно проводить сравнение, но давайте посмотрим на Яндекс.Почту и Gmail. Внешне все выглядит следующим образом. Яндекс.Почту делал Воронежский — гениальный дизайнер. Gmail делали юзабилити-специалисты.

Яндекс.Почта — традиционный почтовый сервис, над интерфейсом которого долго думали и вылизывали. Там красивые картинки, правильного размера кнопки и красиво сделаны фильтры «непрочтенные», «с файлами» и т.д. Красиво, но ничего особенного.

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

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

Дополнил доклад по социальным сетям источниками.

Это вторая часть доклада «Юзабилити социальных сетей», прочитанного на конференции User Experience 2007. Первую часть доклада готовил Владимир Климентьев, она выложена в формате статьи на вебпланете (Социальные сети: от реальности к веб-сервису@webplanet.ru).

Сначала о названии. Вы можете спросить «где же тут обещанное юзабилити?». У монеты есть две стороны: проектирование пользовательских интерфейсов и юзабилити-тестирование. И то и другое отталкивается от анализа задач пользователя. Выдвигаются гипотезы о том, как пользователь будет взаимодействовать с системой. В соответствии с гипотезами проектируется интерфейс, затем эти гипотезы проверяются во время юзабилити-тестирования. Поэтому эти два вида деятельности тесно связаны. Без задач пользователя невозможно проектирование интерфейса: например, «поделиться новостью с друзьями» — вполне себе задача пользователя, и понятно как для неё проектировать. В то время как «запостить текст в сообщество» — такой задачи пользователя быть не может, и как для этого проектировать — совершенно непонятно. Должен ли у поста быть заголовок? Нужны ли теги? Будет ли указываться настроение? Из задачи пользователя это не ясно.

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

Само понятие социальной сети — дело тонкое, поэтому я буду считать социальной сетью то, что назвал социальной сетью. Подробнее об определении — в статье Владимира Климентьева.

Определимся с тем, какие компоненты необходимы для функционирования социальной сети. Итак, Социальная сеть =
Самоидентификация пользователей + Связи между пользователями + Межличностные коммуникации + Предметная область + Рейтинги?

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

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

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

Предметная область. Это собственно то, вокруг чего построен конкретный сервис социальной сети. Могут быть блоги, вакансии/резюме, фотографии, музыка — да что угодно. Предметная область имеет особое значение в досоциальный период развития сети, когда пользователей на сайте еще немного и предметная область остается единственным привлекающим фактором.

Рейтинги. Рейтинги всегда есть. Люди всегда заинтересованы в том, чтобы померяться разного рода рейтингами, это естественная потребность, которую можно использовать для построения авторитета пользователя и повышения доверия между пользователями. Даже если вы сами не спроектировали рейтинг как часть своего сервиса — это сделают другие люди, как, например, Яндекс для Livejournal и прочих блогохостингов.

Проектирование социальной сети принципиально отличается от проектирования обычных сайтов тем, что на первый план выходит взаимодействие типа человек-человек, вместо человек-компьютер. Перед тем как рисовать экраны и именовать разделы, надо определиться с тем, как люди будут взаимодействовать между собой на вашем сервисе. Из проектирования интерфейсов в этом, кажется, может быть полезна т.н. диаграмма Swim Lane@en.wikipedia.org — на ней отображаются все процессы и все роли, и то как действие переходит между различными ролями пользователей. Всегда, проектируя интерфейс сайта, где есть социальное взаимодействие, надо видеть второго человека, сидящего по другую сторону интернета.

Рассмотрим стадии развития социальной сети.

Предсоциальный период. У любого сервиса (если только он не построен на основе другого, уже работающего сайта) есть такой этап развития, начальный, когда социального взаимодействия еще нет, поскольку пользователей слишком мало. 10 человек — явно мало, чтобы считаться социальной сетью. 100 человек — может быть. 1000 человек — наверное, уже достаточно. Вот до преодоления этого барьера на первый план выходит предметная область, функциональность, вокруг которой построен сервис. В Livejournal можно просто вести блог. В flickr можно закачивать фотографии и давать ссылки на них. В LinkedIn можно заполнить визитную карточку и использовать как резюме. Это помогает накопить первоначальную базу пользователей.

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

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

Для более активного наращивания базы пользователей можно предпринимать следующие шаги:

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

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

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

Также, как не странно, на качество контекта влияет то, насколько просто и быстро человек может внести свой контент. Если человек приходит в новое для себя сообщество, ничего о нем не зная, и видит кнопку «создать новую тему» прямо на первой странице, то качество контента будет не очень, с большой степенью вероятности. Чем больше времени человек проводит на сайте, изучая существующие правила и контент, тем более вероятно что его вклад будет соответствовать ожиданиям сообщества. Примером может послужить сайт torrents.ru — для выкладывания своего файла надо пройти непростую процедуру, и делают это только очень мотивированные люди. Но система рейтингов на сайте построена так, что выкладывать свои файл выгодно, и люди идут на это. Тем самым повышая качество контента.

В рекомендациях по формированию сообществ можно выделить ряд паттернов, best practices.

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

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

Заполнение по запросу. Это сейчас начали реализовывать на moikrug.ru — вместо пустых блоков в профайле пользователя отображаются кнопки, с помощью которых другие пользователи могут попросить заполнить пробелы — указать место работы, интересы, школу, университет. Считается, что бездушные призывы сайта заполнить анкету еще на 5% не так стимулируют, как запросы от живых, реальных людей. Не знаю насколько это работает, привожу как есть.

Планирование активности. Чтобы у пользователя очень быстро не настал момент, когда он не знает что ему дальше делать на сайте, необходимо заранее планировать деятельность пользователя — сформировать основной сценарий, по которой он будет идти. Пользователь может пойти каким-то другим, альтернативным путем. Но основной сценарий необходимо продумать для того, чтобы правильно построить цепочку шагов по использованию сервиса и избежать досадных промахов в построении интерфейса.Пользователь зарегистрировался на сайте, что дальше? Поискал своих друзей. Что дальше? Заполнил место работы, поискал коллег, добавил в контакты. Что дальше? Начал переписку, написал несколько личных сообщений. Что дальше? Организовали пьянку. Что дальше? Выложили фотографии с пьянки, создали обсуждение. И т.д. Пользователей нужно вести, подсказывать дальнейшие действия, а не просто оставлять один на один с функциональностью сайта. Это может показаться навязчивым в реализации, но можно вести пользователя аккуратно, не подсказывать сто раз одно и то же, не давать неуместные в данном контексте советы, не быть назойливым. Это высший пилотаж проектирования взаимодействия — давать незаметные, но полезные подсказки в нужное время.

Напоследок, некоторые наблюдения о том, каким должен быть успешный сервис. Главное — не количество фич, не огромная всеохватывающая функциональность, а четкое позиционирование сервиса. Знакомиться — на mamba.ru, искать работу — на moikrug.ru, встречаться с одноклассниками — на odnoklassniki.ru, выкладывать фотографии — на flickr, и т.д. Человек должен с первого же взгляда на сервис понимать в чем этот сервис лучший. Если человек попал на сайт — пускай он имеет возможность воспользоваться им сразу же. Чем быстрее он увидит реальную пользу от сервиса — тем с большей вероятностью он к нему вернется.

Лучшие сервисы моделируют те аспекты человеческой деятельности, которые существовали и прежде. Они помогают людям делать то, что люди и так делали. И делают это лучше других сервисов. Вместо того, чтобы заставить людей заниматься какой-то новой деятельностью, которой нет аналога, чем пытаться изменить способ взаимодействия людей — лучше моделировать его, и делать проще. Все самые популярные сервисы не делают ничего революционного. Они просто берут то, чем люди занимались и до них, и делают это лучше, проще и понятнее. Чем и привлекают к себе. Gmail функционирует как почтовый сервис, моделируя уже существующую деятельность, но организует процесс более естественным для человека образом. То же с Flickr, то же с Google. Livejournal создавался просто как средство поддерживать связь с друзьями, и это тоже работает.

Спасибо что дочитали до этого места. Хочу напомнить, что все вышесказанное — обобщение сетевого опыта с помощью здравого смысла. Необходимо учитывать контекст, свою особую ситуацию, а не следовать примерам слепо. Контекст — ключевое слово в юзабилити.

Источники:

1. Common Pitfalls of Building Social Web Applications and How to Avoid Them @bokardo.com
2. Community Building isn’t about Features @bokardo.com
3. A Social Revolution by Modeling Human Behavior @bokardo.com
4. It's Not Just Usability @joelonsoftware.com
5. Социальные работники @sf-online.ru
6. Деловые социальные сети и рекомендательные письма @nundesign.com
7. Социальные сети и поведение на рынке труда @sj.obliq.ru
8. «Социальная сеть»: от «френд-листа» к «рабочей группе» @internet.ru
9. Social Networks And Group Formation @boxesandarrows.com
10. «Умная толпа: Новая социальная революция», Говард Рейнгольд (@ozon.ru, @bolero.ru, @findbook.ru)
11. «Design for Community: The Art of Connecting Real People in Virtual Places», Derek Powazek

Я буду рад услышать ваши комментарии и отзывы.

Презентация от моего доклада «Проектирование социальных сетей» на конференции User Experience 2007:
michael.elfimov.com/userexp/userexp-presentation.ppt (100 Кбайт)

Вроде всем понравилось. Завтра выложу в виде картинок с комментариями, сейчас уж очень спать хочется.

P.S. Выложил текстовую версию доклада.

В использовании прототипов для проектирования есть правда и неправда.

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

Неправда заключается в том, что согласование с заказчиком — это не то же, что демонстрация юзеру. После согласования с заказчиком получается, например, что пункт «О проекте» — это очень важный пункт меню, который непременно должен быть на первом месте в меню и обязательно на главной странице. С точки зрения пользователя у меня этот момент вызывает сомнение. Поскольку как пользователь я совершенно уверен, что на странице «О проекте» будет какая-нибудь маркетинго-стимулирующая галиматья. Очень редко когда можно встретить грамотную страницу «О проекте», и то её содержание обычно на страницу никак не набирается — максимум пара предложений: зачем сайт/проект и чем он отличается от прочих.

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

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

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

Но я не уверен в окончательной правильности своего мнения, и думаю что предложение заказчика тоже имеет смысл. Твою мать, я в нерешительности. Несмотря на то, что решение уже принято и сайт уже делается, меня не оставляет мысль, что я прогнулся под мнение заказчика, вместо того чтобы отстоять удобство — напоминаю, гипотетическое! (ибо я проектировщик, а не пользователь)

Почему-то тестовые задания по юзабилити часто не юзабельны. Все ведь знают (или должны знать) определение юзабилити, в котором три раза упоминается слово «определенные»: определенные пользователи решают определенные задачи в определенном контексте. При этом тестовое задание обычно выглядит так: вот вам формочка (сайт, страница, приложение), как бы вы его улучшили? По прочтении таких тестовых заданий начинаешь понимать юзабилистов как некоторых волшебников, пришедших в этот мир со светлой целью сделать мир лучше. Как и положено волшебникам, юзабилисты не пользуются никакой дополнительной информацией, им достаточно взмахнуть волшебной палочкой, чтобы все проблемы разрешились, и формочка стала лучше.

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

Как реагировать на такие тестовые задания?

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

Можно сделать некоторые предложения общего характера, приемлемые для данного вида интерфейсов — существуют check lists для веб-интерфейсов, для десктопных приложений, есть открытые и доступные всем стандарты, хорошие правила. Однако, эти правила плохи тем, что имеют широкую направленность, и некоторые правила для данного конкретного интерфейса могут быть вовсе неприменимы, а в некоторых случаях вы просто не найдете правил и стандартов, подходящих для вашего интерфейса.

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

Для работодателей также будет полезно знать: если в ответ на предложения «улучшить интерфейс» человек выдает кучу ценных предложения типа «давайте покрасим кнопочки в синий цвет», то этого скорее дизайнер, чем специалист по юзабилити, или, того хуже, программист («давайте все переделаем на Java» или «табличная верстка давно уже не применяется»).

Usability in the Movies — Top 10 Bloopers @useit.com by Jakob Nielsen

Якоб Нильсен всё-таки страшный зануда. То, что люди постоянно показывают в фильмах 3D или голосовые интерфейс, говорит не только о зрелищности такого подхода. И то, что человек с ноутбуком может подключиться к инопланетному кораблю и запустить туда вирус - это не просто “тупые киношники”.

Люди (включая режиссеров, сценаристов и зрителей) хотят, чтобы они могли сказать компьютеру “найди этот чертов файл”, закачать за две секунды в наладонник трехмерную модель (и открыть её там!) и передавать файлы с мака на PC и обратно безо всяких проблем.

Я знаю, что мой телефон может показывать видео, я знаю что на компьютере у меня есть файл в формате AVI, закодированный определенным кодеком, и знаю что в компьютере и телефоне есть WiFi и Bluetooth, и даже знаю, что если я попытаюсь передать через Bluetooth видеофайл, то я умру, прежде чем файл зальется. Поэтому я открываю специальную программу, конвертирую видео в правильный формат, вынимаю из телефона флешку, вставляю в кардридер, заливаю туда файл, вынимаю флешку (не забыв кликнуть “извлечь флешку”), вставляю флешку в телефон, ищу проигрыватель видеофайлов в меню и наконец открываю видео - если, конечно, у меня еще не сел аккумулятор. Это неправильно. Я знаю, что у меня в телефоне операционка Symbian 9.1, и это плохо, что я это знаю.

У меня есть другое видение современных технологий. Я не должен знать названия операционных систем. Не должен задумываться над тем, в каком формате и разрешении у меня видеофайл. Я должен тыкнуть в файл, сказать “положи это в телефон” и нажать на телефоне кнопку “проиграть видео”. Откашляться, произнести “поговорить с Олей”, и компьютер должен сам знать как это делается!

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

Существуют распространенные рекомендации о том, как заменить стандартное сообщение HTTP-сервера «404 Not Found» на что-то более дружелюбное, например, написать что-то типа «404 Не найдено». Осмысленность такого решения будто бы в том, что посетители сайтов до смерти пугаются сообщений на английском, а вот если то же самое написать по-русски – пользователи тут же всё поймут и будут счастливы. Попробуем предложить пару более элегантных решений. Заодно я затрону тему обработки переходов на сайт по ссылке (а так обычно и переходят на сайт, верно?). Статья не только для программистов, просто разумным людям тоже будет интересно.

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

Типичные решения:

• Сообщение «Страница не найдена, потому что либо вы ошиблись, либо сервер кривой, либо пятна на солнце». Это говорит посетителю только об одном – нужной ему информации тут нет, и страницу можно закрыть. Посетитель потерян для вашего сайта. Почему бы вместо этого не предложить ему что-то подходящее?
• Сообщение «Страница не найдена» и карта сайта. Уже лучше, потому что человек видит возможные пути выхода из ситуации, получает некоторую информацию о сайте и может сделать предположение о том, где содержится нужная ему информация. Однако, посетитель не знает в какой раздел смотреть, не видит конкретных вариантов, и, в зависимости от мотивации, может не захотеть копаться в разделах сайта. Почему бы вам не поискать информацию в разделах сайта самому и предложить посетителю найденные варианты?
• Сообщение «Страница не найдена» и ссылка на главную страницу сайта. Предложение перейти на главную страницу по степени раздражения и неэффективности находится рядом с картой сайта. Посетителю не нужен ваш сайт, ему нужна информация, товар, файл. Предложите ему это, исходя из ссылки, по которой посетитель пришел к вам!

Почему так получилось, что страница не найдена и что с этим делать? Рассмотрим возможные ситуации.

Посетитель пытается перейти к удаленному документу, файлу, картинке
Вероятно, когда-то такой документ был на сайте, но с тех пор много воды утекло, и теперь его нет, как нет никакой возможности его предоставить. В этом случае, при сознательном удалении с сайта документа, вы можете предложить пользователю альтернативные способы получить нужную ему информацию – порекомендовать ссылку на другой сайт, или предложить перейти на поисковый сайт с уже сформированным запросом (заголовок утраченного документа или ключевые слова). Для этого достаточно следить за удаляемыми документами и вести простой список – ссылка, по которой находился удаленный документ, тип документа и его заголовок или ключевые слова. Отлавливая 404, вы просматриваете список, и если требуемая ссылка в нем есть – информируете посетителя. Если на вашем сайте читабельные ссылки (вроде /shop/foto/canon/d300.html), то ключевые слова можно попробовать извлечь прямо из ссылки.

Посетитель пытается перейти к странице, утраченной в связи с реорганизацией сайта
Много битых ссылок легко и непринужденно получается при смене движка сайта. В этом случае контент сайта обычно остается тем же, так что вы можете создать специальный обработчик ошибок, извлекающий из желаемой ссылки важные параметры (ID документа, товара, раздела, дата сообщения из архива, имя пользователя) и автоматически перенаправляете к нужному документу в новой системе навигации. Сообщение об этом пользователю можно показывать, а можно не показывать – если пользователь неопытный, то и не надо заставлять его думать над фразами вроде «перенаправление», «страница была перенесена» и т.д., а если опытный – ему это тем более нафиг не надо, он и сам поймет.

Посетитель пытается перейти к удаленному документу по ссылке с поисковика
Посетитель мог ввести поисковый запрос «купить Nokia N95 прямо сейчас» или «голые девушки секс на пляже» на яндексе, а вы как-раз удалили описание телефона с сайта или переместили его в другой раздел, а может быть удалили пачку эротических рассказов. В этом случае у вас есть поисковый запрос (подсказка: referer http-header), введенный посетителем на поисковике. Если у вас на сайте есть своя поисковая система, вы можете выдать список страниц, подходящих под поисковый запрос. Если поисковой системы нет, но вы знаете, что некоторые ключевые слова вам интересны – проверяйте их наличие в поисковом запросе и показывайте соответствующие ссылки. Например, если у вас интернет-магазин мобильных телефонов – проверяйте названия брендов и моделей в запросе.

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

Посетитель хочет неведомого
Может быть так, что вы совсем не знаете что привело к вам посетителя. Даже в этом случае вы можете сделать доброе дело и указать на конкретную причину ошибки, благо у вас есть источник перехода (подсказка: referer http-header). Не заставляйте посетителя теряться в догадках о причине происшедшего, если вы можете определить причину сами.

Если по заголовку referer видно, что к вам пришли по ссылке с сайта www.xxx.ru – сообщите пользователю, что ссылка на сайте www.xxx.ru устарела и предложите вернуться и написать письмо администратору сайта www.xxx.ru. Подскажите, что надо сообщить администратору – дату и время ошибки (чтобы их можно было найти в логе), адрес страницы на вашем сайте, адрес страницы на www.xxx.ru. Чаще всего почтовый ящик администратора выглядит как webmaster@xxx.ru или root@xxx.ru – предложите эти варианты пользователю.

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

Если посетитель получил 404, введя адрес своими руками или перейдя по закладке браузера – сообщите ему о необходимости внимательнее набирать адрес или обновить неактуальную закладку. Опять таки, дайте возможность связаться с вами прямо с «ошибочной» страницы, если вы занимаетесь продажей чего-то и каждый клиент у вас на счету – предложите ввести контактную информацию и оставить сообщение.

Подытоживая, можно сказать, что не для всех сайтов так уж важно правильно обрабатывать ошибку 404 и переходы с поисковиков. Юзабилити говорит об определенных пользователях, решающих определенные задачи в определенном контексте. Задача разработчика сайта – правильно определить аудиторию сайта, понять для чего и как сайт будет использоваться, и только после этого принять решение. Какой процент ваших посетителей попадает на страницу 404? По какой причине это происходит? Если ваши посетители важны вам, есть ли у вас инструмент для мониторинга частоты и причин ошибок на сайте? Ответы на эти вопросы помогут вам принять верную стратегию «работы над ошибками», и я надеюсь что моя статья вам в этом помогла.

Ссылки по теме:

• Совершенная 404-ая страница. Ян Ллойд @webmascon.com. Примеры кода на JS и на PHP.
• Маленькие штучки для блога (Обработка опечаток в URL) micromarketing
• Работаем над ошибками @artlebedev.ru. Плохие советы о содержании страницы 404, но хорошие советы о её оформлении.