Наша компания производит продукты для бизнеса заказчиков — это называется B2B сегмент. Проектировщикам интерфейса работать в этом бизнесе тяжело. Вопрос в том, как относиться к этим сложностям.
Когда два больших бизнеса решают свои задачи, до конечных пользователей часто никому нет дела. Юзабелист в такой ситуации чувствует себя идиотом. Кроме того, многие наши продукты существуют давно и имеют тяжелое наследие устаревших технологий, поэтому даже если удается что-то нарисовать хорошо, запрограммировать это как правило нереально.
Конечно, всегда можно пожаловаться на тяжелую дизайнерскую судьбину или даже хлопнуть дверью, но есть и другой путь. Сегодня я хочу рассказать историю о переводчике Уильяме Камероне Таунсенде.
История одного проекта
Кам Таунсенд родился в Калифорнии в 1896 г. в период больших экономических трудностей и детство мальчика омрачалось бедностью. После окончания школы он поступил в Западный колледж, к окончанию которого твердо настроился на миссионерское служение. Кам обратился в организацию «Библейский дом Лос-Анджелеса» и вскоре был назначен в Гватемалу в качестве библейского коммивояжера.
Распространение Библий в Центральной Америке оказалось делом нелегким. Кам работал в отдаленных районах, где около двухсот тысяч какчикельских индейцев не могли читать испанские Библии, которые он продавал, потому что их язык не имел письменности. Однажды один индеец раздраженно спросил его: «Послушай, если твой Бог такой умный, почему Он не выучит наш язык?»
Кама застиг врасплох столь прямой вопрос, и именно этот случай привел к тому, что последующие тринадцать лет он посвятил какчикельским индейцам. Его первоочередной задачей стало основательное изучение их языка, чтобы дать ему письменную форму, а затем перевести на их язык Писание. Без предварительной лингвистической подготовки Кам немедленно столкнулся с огромными трудностями. В языке индейцев существовало четыре различных звука «к», которые он едва мог отличить друг от друга, а глагольные формы запутали бы любую светлую голову.
Задача казалась невыполнимой, пока Кам не встретился с американским археологом, который посоветовал ему не пытаться втиснуть язык индейцев в привычные формы, а постараться найти ту логическую модель, которой подчиняется этот язык. Совет, данный Каму, изменил направление изучения нового языка, что постепенно привело к оформлению концепции лингвистической учебной программы. А через десять лет напряженнейшего труда, в 1929 г., Кам закончил Новый Завет на какчикельском языке.
Руководители миссии не понимали его глубокой озабоченности положением дел в области переводов христианской литературы на другие языки, что часто приводило к возникновению напряженности, а впоследствии и к его увольнению из рядов этой миссии.
А причем тут дизайнеры
И хотя история совсем не о дизайне, нам есть чему из нее поучиться:
Кама никто не просил сворачивать горы, но он сделал то, что считал правильным;
у него не было необходимых ресурсов и сильно недоставало опыта;
задача была «невыполнимой», поэтому ею никто не занимался;
когда он все же сделал невозможное, руководство этого не оценило.
Тем не менее, Кам стал одним из самых значимых переводчиков XX века. Рассказанная мною история — это лишь начала его богатой биографии. Он стал вдохновителем целого движения переводов Библии на малые языки. По сути, он изменил мир.
Возможно, у тебя нет 10 лет на изменение ситуации с интерфейсом в твоей компании, но только от тебя зависит, сделаешь ли ты невозможное и станешь великим или обидишься и пойдешь искать другую работу.
Текст окружает нас всюду. Он информирует нас, предостерегает от ошибок, даже угрожает. Текст — основное средство взаимодействия с пользователем, как в реальном, так и в виртуальном мире. И как любой интерфейс созданный человеком, текст часто бывает плохим.
Вот, к примеру, такой шедевр я обнаружил в админке моего интернет-провайдера:
Я много раз перечитывал это сообщение, я делал это внимательно (ведь речь идет о моих деньгах), но смысл каждый раз ускользал от меня.
Или вот еще пример, буквально на днях обнаружил в гостинице во время командировки:
Я снова и снова перечитывал послание, и каждый раз чувство полного понимания сменялось фрустрацией — я так и не разобрался, если положить этот листочек на кровать, белье сменят или «неправильно поймут».
Каждый из нас может привести множество подобных примеров. Так что давайте поговорим о том, как подобного избежать в интерфейсах, которые создаете вы.
УВЛ
Артём Горбунов изобрел универсальный метод улучшения интерфейсов под названием УВЛ (убери все лишнее). Он прекрасно работает с интерфейсными текстами. Давайте рассмотри его на двух показанных выше примерах.
В случае с моим провайдером текста не должно быть вовсе — мне безразлично как там что работает с погашениями, важно лишь видеть сколько и когда нужно заплатить, чтобы не отключили интернет (а это показывается цифрами, а не буквами).
В случае с гостиницей нужно написать так: Если вы хотите поменять постельное белье, положите этот листок на кровать. Внимательный читатель возразит, что я опустил тему про охрану окружающей среды. Я отвечу по-одесски: «я вас умоляю, какая окружающая среда в этом городе».
Баскетбол на месте
Когда я учился в средней школе, на уроках физкультуры мы иногда играли в баскетбол. Никто играть не умел и главной ошибкой было то, что каждый, получив мяч, никому не отдавал пас. Тренер показал нам метод, который я запомнил на всю жизнь. Он заставил нас играть в баскетбол, где запрещено вести мяч (ударять его об пол), единственный способ играть — часто делать пас и постоянно открываться партнерам.
Я предлагаю использовать этот метод тем, кому необходимо научиться писать хорошие интерфейсные тексты. Попробуйте сделать интерфейс полностью понятным, совсем не используя текст.
Конечно, часто подобное невозможно, но ведь и в баскетбол не играют без ведения меча, это лишь тренировка. Добейтесь максимума без текста и лишь потом добавляйте пояснения. Помните, интуитивно понятный интерфейс — это тот, который не нужно читать.
Если же вы хотите проверить на понятность уже созданный веб-интерфейс, пропустите его через Гугл переводчик и получите страницы скажем на португальском языке. После этого отправляйтесь проводить юзабилити-тестирование.
Бревно в своем глазу
Ну и конечно же, все вышесказанное можно отнести к этой статье. Ее можно сильно сократить, не потеряв сути. Например так:
Не пишите поясняющие тексты в интерфейсе, а если это невозможно, пишите их коротко и однозначно.
Последние годы многие из IT-компаний в России столкнулись с острой нехваткой юзабилити-специалистов. За последние пять лет производители софта в основной своей массе дозрели до мысли, что для успеха на рынке им недостаточно выпустить продукт с некоторым функционалом, а нужно еще, чтобы он был удобным и красивым. Эта тенденция с одной стороны подогревается развитым рынком (нужный потребителю функционал есть у многих, поэтому выбирают уже «сердцем»), а с другой — китайские и индийские разработчики душат демпингом, лишая российских разработчиков софта такого важного преимущество как цена.
И вот, дозрев, многие компании стали искать не просто «дизайнера, который может нарисовать иконки», а серьезных и опытных юзабилити-специалистов. И тут оказывается, что их крайне мало.
Как ты, мил друг, зовешься?
Самое смешное, что толком не понятно, кого искать. Ну, как это человек называется? Юзабилист? UX Designer? А по-русски как, UX-проектировщик? Или, может быть, Interaction Designer — опять не по-нашему... Дизайнер интерфейсов? Хотя нет, это наверное больше по иконкам.
Но если без ясности в названии еще как-то можно обойтись, то без ясности в профессиональных навыках уже нельзя. И тут опять нет единого мнения среди работодателей. Вот некоторые навыки, которые ожидаются от подобных специалистов:
проектирование пользовательского интерфейса;
прототипирование;
юзабилити-исследования;
визуальный дизайн, веб-дизайн;
иконографика;
анализ пользовательских предпочтений, аналитика рынка;
бизнес-аналитика;
общение с заказчиком;
веб-верстка и js-кодинг;
и т.д.
Что из этих навыков важнее, а чем можно пренебречь? Каждый работодатель решает этот вопрос исходя из сложившейся ситуации. Но все равно встает перед мучительным вопросом: нужен скорее «рисовальщик» или «аналитик от UX»?
Так что я получу в итоге?
Дальновидный работодатель/заказчик сразу задается этим вопросом. А недальновидный бывает сильно удивлен, когда вместо ожидаемых им набора нарисованных экранов, получает аналитические отчеты.
— Где нарисованный интерфейс? — спрашивает руководитель проекта.
— Вы понимаете, я UX-специалист, я проектирую пользовательское взаимодействие, анализирую поведенческие реакции, я еще в самом начале процесса, — пытается оправдаться новый сотрудник нанятый два месяца назад на должность «дизайнер».
— Это все прекрасно, но ты работаешь уже два месяца, а я не могу дать разработчикам экраны в разработку.
— Ну вот же, я нарисовал, это называется Wireframes.
— Это не экраны, это черные квадратики и полосочки, я не могу отдать это верстальщику и программисту, — вскипает начальник.
— Детальный дизайн должен прорабатывать другой специалист, а не UX Designer.
— Но ты же дизайнер?
— Да, но понимаете, я занимаюсь несколько другим...
В результате оказывается, что нужно нанимать еще дизайнера, а на него денег уже нет. Вся аналитика и расписные персонажи выкинуты в мусор, потому что дедлайн и кодить нужно.
Так кто же нужен и где его найти?
Я ищу и нанимаю на работу дизайнеров интерфейсов более пяти лет, а последние два года занимаюсь внедрением UX практик в большие IT¬-компании. В результате у меня сформировалось определенное мнение и определенный подход, который состоит из двух принципов:
1) UX-специалист должен быть универсалом. Он должен и проектировать пользовательское взаимодействие, и заниматься аналитикой, и создавать Wireframes, и рисовать чистовой дизайн. Юзабелисты, которые не могут сделать «красиво» не нужны. Тонны аналитики и подробно расписанные пользовательские персонажи мало полезны, если нет итоговых экранов от этого же человека. В идею «один делает логику и wireframes , а другой рисует дизайн» я не верю, обычно выходит полная лажа. UX-специалист, проектирующий интерфейс, не обязан быть супер графиком (проработку графических тем, текстур и модных иконок можно отдать профильным дизайнерам), но он должен уметь делать аккуратно, красиво, чтобы это, при желании, можно было отдать в разработку без привлечения дизайнера.
2) Бери дизайнера и учи. Найти хорошего юзабелиста, да еще и с навыками дизайнера очень сложно. Поэтому мы практикуем найм дизайнеров у которых есть некоторый опыт работы с интерфейсами и большое желание двигаться в этом направлении. Мы учим их, как проектировать интерфейсы, как проводить юзабилити-тестирование. Наш опыт говорит, что научить дизайнера заниматься аналитикой, думать о пользователях, проводить юзабилити-исследования — легко. А вот научить аналитика «рисовать дизайн» — практически невозможно. Бывают исключения, но в основном это правило подтверждается.
Почем универсалы и почему дизайнеры?
Я уверен, что многие коллеги по цеху забросают меня камнями. Уверен, что есть миллион доводов о разделении труда, о том, что нельзя путать UX и графический дизайн, что хорошая аналитика важнее рисования экранов. Доводы это хорошо, но лично я не теоретик, мне нужно в этом году подготовить около 20 UX-специалистов для работы над реальными проектами.
Я хочу привести лишь один довод в защиту моей практики универсальных UX-дизайнеров. Этот довод — незрелый рынок.
У 90% производителей софта (в том числе и веб) пользовательский интерфейс (UI) и пользовательское взаимодействие (UX) настолько плохие, что им не до жиру. Интерфейсный дизайнер средней руки может колоссально улучшить большинство производимых в России интерфейсов. Мы пока не доросли до Америки, где в университетском курсе для юзабелистов половина предметов начинаются со слова «психология». Нам пока рано взращивать узкоспециализированных специалистов.
Нам нужны UX универсалы. Много. Поэтому мы в Digital Design обучаем дизайнеров и поэтому с этого года мы открыли поток по проектированию интерфейсов в нашей Школе разработчика. Сейчас у нас стажируются 13 студентов, но это уже тема отдельной статьи.
Выкладываю видео с теоретической частью мастер-класса «Электроника для собак» «Проектирование пользовательского интерфейса (для начинающих)».
Видео будет полезно для широкого круга лиц, интересующихся юзабилити — аналитиков, разработчиком, ПМ-ов. Для профессиональных проектировщиков думаю это будет скучно.
Организаторы выложили видео с конференции. Притом вмонтировали в видео и презентацию. Мелковато, но зато в контексте.
Мой доклад «Методы быстрой авторизации» вызвал резонанс, многим понравилось. А я сейчас посмотрел на себя со стороны и мне не нравится — болтал много лишнего, говорил путано. Но, буду меняться. Смотрите, если интересно (переход на другую страницу):
Пользователь почти всегда заходит к вам на сайт мимоходом. Ваш интерфейс для него — лишь один из 20 табов в браузере. Поэтому, если вы хотите ему что-то продать, интерфейс должен быть простым и однозначным. Всегда помните о принципе — сообщать ровно столько информации, сколько нужно в данный момент времени, не больше!
Рассмотрим принцип «сообщать только самое нужное» на примере сайта «Мобильный перевод» компании МОБИ.Деньги, который я проектировал и внедрял. Суть этого сервиса — позволить владельцам телефонов Билайн обналичивать средства с их мобильного счёта.
С места — в карьер
Главная страница сайта выглядит так:
Что тут есть (необходимое):
Два коротких вводных предложения, отражающие суть услуги.
Форма перевода, которая одновременно является поясняющей иллюстрацией.
Ссылки на доп. информацию: где получить перевод, размер комиссии, текст публичной оферты, помощь.
Чего тут нет (лишнее):
Длинных маркетинговых текстов.
Предложения зарегистрироваться.
Мусорной графики.
Подпишитесь под договорчиком, пожалуйста
Когда пользователь заполнил первую форму, он перейдет на страницу подтверждения платежа. Т.к. телефон является источника перевода, то одноразовый пароль мы автоматически высылаем через смс (регистрация отсутствует как класс):
Что тут есть:
Время подумать, если ввели неверные данные и информация, чтобы проверить правильность перевода.
Возможность получить пароль повторно (ссылка появится позже около поля ввода), если автоматически высланная смс по каким-то причинам не пришла.
Чего тут нет:
Необходимости заказывать пароль.
Необходимости придумывать пароль (он одноразовый и генерируется автоматически).
Собственно, всё!
Всё, перевод совершен:
Что тут есть:
Информация о том, где и кому получить перевод.
Возможность распечатать электронный чек.
Информация о том, как повторить этот перевод с помощью телефона.
На самом деле, на этой странице информации больше, чем необходимо пользователю. Поэтому по настоящему важную информацию мы поместили наверх и обвели желтой яркой плашкой.
Чего тут нет:
Предложения перейти в историю платежей (почему-то во многих платежных системах это предлагается) — мы и так уже в истории платежей.
Предложения поменять пароль.
Каков итог?
С момента первого посещения сайта до совершения успешного перевода прошло около минуты. Сравните это со временем, которое вам потребуется, чтобы совершить такой же перевод на другом сайте или в офф-лайне.
Советы напоследок:
Не парьте пользователей маркетинговыми булшитами.
Сообщайте лишь самое необходимое, но давайте возможность узнать все подробно.
Уважайте цели пользователей — они пришли за услугой, а не за тем, чтобы прочитать ваш гениальный текст и придумать очередной пароль.
Хочу прочитать некоторый ликбез по построению полей на форме ввода, а также рассмотреть некоторые ошибки.
Ликбез (повторяем пройденное в детском саду)
Сверху — пример простой формы (фрагмент). Она хорошо отражает два главных принципа:
Поле должно быть достаточной длины, чтобы поместился контент — это самое важно, аксиома. Недостаток длины полей ведет к ошибкам ввода. Но это и так все знают.
Поле должно по возможности быть не длиннее, чем нужно. Если поле содержит точно определенное количество символов, то логично сделать его именно такой длины (не забыть про разные шрифты, браузеры и некоторый запас). Это не обязательное требование, но желательное. Конечно, бывает некрасиво, когда длина полей скачет или просто не хочется заморачиваться. Но уж точно 1-2 символа не должны вводиться в длиннющее поле. Хороший вариант — завести css-классы для длинного, короткого и среднего полей.
Переходим в старшие классы или горе от ума
Когда я сделал эту простую форму для перевода денег на определенный банковский счёт, заказчик попросил сделать две вещи — не давать вводить больше символов, чем разрешено и не давать вводить буквы и другие символы в поле для номера.
Оба этих требования ошибочны, что я и объяснил заказчику. Хотел также поделиться доводами с вами.
Ни цента больше
Блокирование ввода символов после достижения допустимой длины — это грубая ошибка. Представьте, пользователь вводит сложный 20-значный номер счёта, в середине вводит лишнюю цифру, не замечает этого, доходит до конца и... последняя цифра не вводится. Он в остервенении бьет по клавиатуре — ничего не происходит, символ не набирается. Все, гэйм овер. Лучше дать пользователю возможность ввести 21 цифру, а потом сообщить ему об ошибке, пусть найдет лишнюю цифру сознательно.
Понаехали тут
Блокирование ввода любых символов, кроме цифр в поле номера — не такая грубая, но все же ошибка. Лично я, когда нажимаю на клавишу и не вижу никакой реакции, пугаюсь и думаю, что компьютер завис. Есть возможность решить проблему недопустимых символов более мягко.
Посмотрите на форму сверху. В первом поле хоть мы и рекомендуем вводить 10 цифр телефона слитно, но прощаем и пробелы и дефисы и даже лишнюю восьмерку в начале. А почему нет? Что нам сложно отбросить лишние символы что ли!
А вот во втором поле не допускаются русские символы. Хорошо, сообщим об этом пользователю через красный хинт, расположенный под полем. Не заметил — после нажатия на кнопку, мы переведем курсор в проблемное поле, и рядом с ним выдадим более заметное сообщение. Естественно, все это сделаем без перезагрузки страницы, 21-й век на дворе.
Рекомендации по обработке ошибок в полях формы
Не блокируйте ввод символов в поля.
По нажатию на кнопку отправки формы выдавайте сообщения об ошибке без перезагрузки страницы. Показывайте сообщение рядом с проблемным полем. Ставьте курсор в проблемное поле.
Если ошибку можно отследить сразу, без отправки формы, выдавайте сообщение об ошибке набора, при этом не блокируйте набор и не переводите фокус ввода.
О том, что активный пункт меню на сайте должен быть выделенным, знает каждый школьник. Но и в такой простой вещи есть свои нюансы, о которых многие веб-разработчики предпочитают забывать.
Т.к. все вещи, которые я здесь опишу, я применяю с самого моего сайтостроительного детства, то мне кажется, что нет вообще смысла писать эту статью, они очевидны. С другой стороны, мне приходится постоянно разъяснять эти истины с нуля программистам и дизайнерам, из чего можно заключить, что не так уж они и очевидны.
В данной статье речь пойдет именно о меню. Т.е. об иерархичной структуре с единственным отношением (один пункт меню — одна страница). Множественные отношения — теги — под данное рассуждение не попадают.
Активный пункт меню
Предположим, что у вас есть сайт с меню из тех пунктов:
Активный пункт меню должен выделяться. Это поможет пользователю помнить (или понять, если он пришел по ссылке сразу на внутреннюю страницу), в каком именно месте сайта он находится. В нашем примере, когда пользователь щелкнет по пункту «Новости», то меню станет таким:
Графически выделен — другой цвет фона и полужирное начертание шрифта;
Не залинкован — ссылка убрана, т.к. нет смысла давать ссылку на текущий URL.
Субактивный пункт меню
Предположим, что в разделе «Новости» у нас много ссылок на вложенные страницы с новостями. Если зайти на эти вложенные страницы, то как должен выглядеть пункт меню? С одной стороны, он продолжает быть активным, т.к. мы все еще в разделе новостей. С другой — вроде бы мы уже не прямо в нем находимся.
Состояние пункта меню в данном случае я называю субактивным:
Субактивный пункт сочетает в себе черты активного и пассивного пунктов:
Графически выделен другим цветом фона — это черта активного пункта;
Залинкован и не выделен полоужирным — это черты пассивного пункта.
В результате, пользователь, попав на внутреннюю страницу новости, с одной стороны поймет, что он находится в разделе «Новости», с другой — сможет перейти в корень раздела.
Ошибки в построении меню
Описанные выше принципы просты для понимания, разработки и использования. По сути, это те мелочи, о которых пользователю даже думать не нужно, типа вращения колесика на мышке.
Но и в данном простом вопросе встречаются ошибки:
Пункты меню вообще не выделяются — это как ни странно встречается;
Субактивный пункт выглядит также, как активный — если при этом он залинкован, то ошибка не страшная, но если он не залинкован (такое встречается), то это уже проблема;
Активный пункт выделен, но залинкова сам на себя — очень распространенная ошибка, впрочем нестрашная;
Активный пункт присутствует, а субактивный выглядит как пассивный (никак не выделен) — очень распространенная и довольно серьезная ошибка, часто встречается на больших корпоративных сайтах, где она приводит к серьезным проблемам в навигации.
Где это НЕприменимо
Меню бывают разные. Но все же описанный выше подход довольно универсален и подоходит для большинства случаев. Даже в сложном меню с табами и подпунктами разных видов принцип пассивный-активный-субактивный дает хорошие результаты и сильно улучшает навигацию.
Могу припомнить только две ситуации, где данный принцип неприменим:
Выпадающее меню — в этом случае рекомендую для компенсации применять хлебные крошки;
Пункт меню пропадает на странице назначения. Представьте, что кликнув по пункту «Новости», вы попадете на сайт с другим оформлением и совершенно другим меню. Такое бывает, впрочем, злоупотреблять этим не стоит.
Выводы и картинка
Разработчик, помни, выделение активного и субактивного пунктов меню улучшает навигацию, понижает артериальное давление и улучшает пищеварение!
Я решил, что в каждом посте буду вставлять хотя бы одну картинку. Т.к. в процессе написания статьи я облошелся без картинок, то размещу ее тут. Как говорит старая дизайнерская поговорка, если не знаешь, что нарисовать, нарисуй яблоко. А что, яблоко — это же важная часть нашего с вами меню!
