Видео с конференции UX Russia 2010

Организаторы выложили видео с конференции. Притом вмонтировали в видео и презентацию. Мелковато, но зато в контексте.

Мой доклад «Методы быстрой авторизации» вызвал резонанс, многим понравилось. А я сейчас посмотрел на себя со стороны и мне не нравится — болтал много лишнего, говорил путано. Но, буду меняться. Смотрите, если интересно (переход на другую страницу):

Если что, то есть презентация в pdf.

К чести организаторов они выложили ВИДЕО ВСЕХ ДОКЛАДОВ конференции! Это очень и очень круто, они молодцы, что не зажмотились.

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

Сколько я смогу заработать на юзабилити?

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

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

Немного истории

Генри Форд был гениальным инженером и бизнесменом. На его заводах производился первый по-настоящему массовый и народный автомобиль Ford T. За 19 лет было произведено более 15 миллионов (!) автомобилей. Этот автомобиль был дешев, прост и очень надежен, на сохранившихся до наших дней экземплярах все еще рабочая подвеска.

Был ли этот автомобиль ориентирован на удобство пользователя? Однозначно нет! У него были плохие неудобные тормоза, его примитивная подвеска не была устойчива в поворотах, из-за отсутствия бензонасоса он глох на горках, он был травмоопасен, скрипуч, а комфорт в нем отсутствовал как класс. Но таковы были все автомобили того времени. Форд опережал их по технологичности, надежности и цене. Конкурентов у него долго не было.

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

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

Повторение истории в веб-индустрии

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

Заботились ли все эти люди об удобстве пользователя? Естественно, нет! Потому что нужно было удовлетворить базовые потребности — надежность системы, скорость и цену разработки и поддержки, кросс-платформенность и т.д.

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

Так насколько это прибыльно?

И вот теперь бизнес чаще и чаще задает вопрос «сколько мне принесет дополнительных денег это ваше юзабилити».

Я хочу ответить на этот вопрос.

Если вы спрашиваете это, значит вы точно не в первом эшелоне. Значит вы уже в роли догоняющих. А если вы все еще лидер своей отрасли, то значит вы повторяете судьбу Генри Форда и конкуренты, которые кажутся швалью, могут скоро откусить вам хвост.

Поэтому нужно ставить вопрос совсем иначе: «сколько я потеряю в ближайшие 5 лет, если сегодня не начну вкладывать деньги в юзабилити».

User Experience Russia 2010: впечатления

Конференция User Experience Russia образца 2010 года прошла очень хорошо. Хочу поделиться впечатлениями буквально в двух словах.

Доклады были интересными, как у хэдлайнеров в первый день, так и у простых смертных во второй.

• В первый день понравился больше всех Билл Бакстон из Майкрософт, который открыл мне глаза на то, что нужно оглядываться назад на технологии и девайся 20-летней давности. Теперь я понимаю, зачем Студии Артемия Лебедева нужен музей старья.

• Очень вствил доклад Андрея Себранта из Яндекса, который оформил мои смутные ощущения о мониторинге проекта в графики и формулы.

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

• Порадовал Алексей Сергеев из Мэил.ру даже скорее не докладом, а тем, что кто-то наконец сделал шаг к социализации почты. Тема не новая и не ими придуманная, но в продакшине я подобного пока не встречал.

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

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

Я поищу видео с моим выступлением и выложу его в блоге.

Радуйтесь, когда вас ненавидят

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

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

И тут я неожиданно понял, что когда тебя ненавидят пользователи — это круто!

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

Прав был Влад Головач в своей книге, утверждая, что любой интерфейс плох (в смысле, что любой интерфейс есть куда улучшать). А если плох, значит его будут ругать. Жестко и часто нецензурно.

Вот такая своеобразная любовь пользователей. Читайте фидбэк, дружите с саппортом и будет вам счастье!

Что случается, когда маркетологи пишут код

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

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

С точностью до запятой

Делали мы как-то веб-сервис, на котором была очень длинная форма. Заказчик был ну очень щепетилен в плане юридической составляющей. И они по сути нарисовали форму сами и...

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

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

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

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

Объявление: объявление находится ниже

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

В результате поля с логином и паролем существенно съехали вниз и... были не видны не многих мониторах, особенно на лэптопах.

Сроки поджимали, спорить было затруднительно и проект вышел с такой фичей. И только позже я узнал причину, почему заказчик решил так поступить. Дело в том, что пользователю на телефон в виде SMS высылалась ссылка на эту страницу. А высылалась она под видом «узнай поподробнее».

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

Вот мы и подошли к нашему секретному выводу.

Большой секрет

Заказчик должен ставить перед разработчиком общую задачу, а не углубляться в частности. Разработчик на то и подряжен, что он лучше знает КАК сделать, а заказчик на то и заказчик, что лучше знает ЧТО сделать.

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

Грустно, но эту прописную истину, которая описана в куче книг, не понимают очень многие.

Краткая шпаргалка для заказчика, что такое «хорошо», а что такое «плохо»:

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

Только самое нужное

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

Рассмотрим принцип «сообщать только самое нужное» на примере сайта «Мобильный перевод» компании МОБИ.Деньги, который я проектировал и внедрял. Суть этого сервиса — позволить владельцам телефонов Билайн обналичивать средства с их мобильного счёта.

С места — в карьер

Главная страница сайта выглядит так:

Что тут есть (необходимое):

1. Два коротких вводных предложения, отражающие суть услуги.
2. Форма перевода, которая одновременно является поясняющей иллюстрацией.
3. Ссылки на доп. информацию: где получить перевод, размер комиссии, текст публичной оферты, помощь.

Чего тут нет (лишнее):

1. Длинных маркетинговых текстов.
2. Предложения зарегистрироваться.
3. Мусорной графики.

Подпишитесь под договорчиком, пожалуйста

Когда пользователь заполнил первую форму, он перейдет на страницу подтверждения платежа. Т.к. телефон является источника перевода, то одноразовый пароль мы автоматически высылаем через смс (регистрация отсутствует как класс):

Что тут есть:

1. Время подумать, если ввели неверные данные и информация, чтобы проверить правильность перевода.
2. Возможность получить пароль повторно (ссылка появится позже около поля ввода), если автоматически высланная смс по каким-то причинам не пришла.

Чего тут нет:

1. Необходимости заказывать пароль.
2. Необходимости придумывать пароль (он одноразовый и генерируется автоматически).

Собственно, всё!

Всё, перевод совершен:

Что тут есть:

1. Информация о том, где и кому получить перевод.
2. Возможность распечатать электронный чек.
3. Информация о том, как повторить этот перевод с помощью телефона.

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

Чего тут нет:

1. Предложения перейти в историю платежей (почему-то во многих платежных системах это предлагается) — мы и так уже в истории платежей.
2. Предложения поменять пароль.

Каков итог?

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

Советы напоследок:

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

Ограничивать нельзя позволить

Хочу прочитать некоторый ликбез по построению полей на форме ввода, а также рассмотреть некоторые ошибки.

Ликбез (повторяем пройденное в детском саду)

Сверху — пример простой формы (фрагмент). Она хорошо отражает два главных принципа:

1. Поле должно быть достаточной длины, чтобы поместился контент — это самое важно, аксиома. Недостаток длины полей ведет к ошибкам ввода. Но это и так все знают.

2. Поле должно по возможности быть не длиннее, чем нужно. Если поле содержит точно определенное количество символов, то логично сделать его именно такой длины (не забыть про разные шрифты, браузеры и некоторый запас). Это не обязательное требование, но желательное. Конечно, бывает некрасиво, когда длина полей скачет или просто не хочется заморачиваться. Но уж точно 1-2 символа не должны вводиться в длиннющее поле. Хороший вариант — завести css-классы для длинного, короткого и среднего полей.

Переходим в старшие классы или горе от ума

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

Оба этих требования ошибочны, что я и объяснил заказчику. Хотел также поделиться доводами с вами.

Ни цента больше

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

Понаехали тут

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

Посмотрите на форму сверху. В первом поле хоть мы и рекомендуем вводить 10 цифр телефона слитно, но прощаем и пробелы и дефисы и даже лишнюю восьмерку в начале. А почему нет? Что нам сложно отбросить лишние символы что ли!

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

Рекомендации по обработке ошибок в полях формы

1. Не блокируйте ввод символов в поля.
2. По нажатию на кнопку отправки формы выдавайте сообщения об ошибке без перезагрузки страницы. Показывайте сообщение рядом с проблемным полем. Ставьте курсор в проблемное поле.
3. Если ошибку можно отследить сразу, без отправки формы, выдавайте сообщение об ошибке набора, при этом не блокируйте набор и не переводите фокус ввода.