Предлагаю читателям «Хабрахабра» перевод замечательной статьи «Nine Nasty UX Truths» за авторством Antoine Valot. В интернетах есть множество материалов по теории UX, но советы ниже являются результатом тяжелой работы автора, что-то вроде шишек, набитых в процессе. Antoine признается, что облажался бессчётное количество раз за последние 20 лет, и описанные истины — это лишь некоторые из способов избежать провалов. Не повторяйте ошибок, наслаждайтесь.
Вообще-то это не сложно, даже в половину не так трудно, как вы думаете.
Пользователи не понимают вашего цветокодирования. Зеленый значит «хороший» для вас, но для кого-нибудь другого на другом экране это может значит «нечитаемое» или «гусиное дерьмо» или «Сайгон? Что? Я до сих пор в Сайгоне?». Каждый человек видит цвет исключительно по-своему, если вообще видит. Он любит одни цвета, и ненавидит другие. И это в значительной степени непредсказуемо. Вы не сможете угадать.
Цвет не является вербальным или рациональным. Он контекстен и эмоционален. Цвет — сильный инструмент, но сам по себе он не имеет смысла.
Единственное что вы можете сделать с цветами это:
Любой цвет: элемент имеет цвет
Другой цвет: элемент отличается от другого элемента
Серый: что-то сломано
Красный: дизайнер ненавидит вас и хочет разозлить
Пользователей не заботит, что значат ваши иконки на кнопках, или что на них написано. Вы можете изменять их каждый день, и никто не будет жаловаться.
Измените позицию элементов, и пользователи насадят вашу голову на пику.
Люди используют их моторную память при использовании приложений. Перемещение элементов интерфейса ощущается как изощрённый метод пыток. Если вы хотите знать, что такое чистая нефильтрованная горящая ненависть, идите и поменяйте несколько элементов местами.
Вы, скорее всего, не читаете это предложение. Если читаете, то вероятно, не читали эту статью целиком с первого раза. Вы пробежались от заголовков к цитатам и может быть пропустили пару пунктов перед тем как прочитать этот абзац. Так что это правда. И тем не менее, почему же мы пишем пояснительный текст? Почему мы позволяем себе длинные параграфы в наших интерфейсах? Почему мы делаем вид, что руководство пользователя и часто задаваемые вопросы являются правильным решением для проблем юзабилити?
Потому что мы ленивые, вот почему! Слишком ленивы, чтобы читать, и слишком ленивы, чтобы не писать.
Не гордитесь вашим интерфейсом навигации, или информационной архитектурой. Если важной частью вашего интерфейса является навигация, вы уже на пути к провалу.
Ваша задача – помочь пользователю достичь своей цели. Навигация по приложению НЕ цель пользователя. Если вы сделали свою работу правильно, ваше приложение будет делать только одну вещь и будет делать это хорошо, находясь все это время на одном экране. Но вы не в состоянии решить что-либо за пользователя или вовсе устранить выбор, и вы оставляете выбор на откуп пользователю пользователю.
Дизайн – это принятие тяжёлых решений, для того, чтобы избавить от принятия решения пользователя.
Да, хорошо, навигация необходима для большинства приложений, большинства сайтов, и пользователь, в конце концов, привык пользоваться навигацией. Мы должны пойти на некоторые компромиссы. Я безусловно согласен. И почти всегда иду на этот компромисс и внедряю навигацию. Тем не менее, мне стыдно и вам должно быть.
Не все части приложения одинаково важны. Есть некоторые вещи, которые вы должны сделать в первую очередь, некоторые вещи про которые не стоит забывать, и некоторые, которые можно полностью проигнорировать.
Моей первой UX-работой еще до того, как концепция UX была сформулирована, была Информационный Архитектор. Это до сих пор наиболее важная работа, которая есть на любом проекте. Вещи имеют имена и должны быть названы. Определение имен и глаголов является наиболее важной частью UX.
Контент является решением. Если вы не проектируете контент, вы проектируете проблемы.
Каждый раз, когда вы создаете каркасы с Lorem Ipsum, вы оскорбляете своих пользователей и злоупотребляете доверием вашего клиента. А также саботируете сами себя.
Loremipsitis – это плохо, поверьте, я видел фото.
Когда вы не в состоянии бороться с фактическим содержанием, но сосредоточены на проектировании каркасов, которые будут независимы от содержания, вы на самом деле создаете барьер между пользователем и их целью. Прекратите немедленно. Спроектируйте контент и вы, скорее всего, справитесь с задачей автоматически.
Делайте карту сайта и навигацию в последнюю очередь. Вообще-то, не делайте их вовсе. Начните с самых важных объектов на экране: с того, который помогает пользователю достичь своей цели. Все излишки времени и бюджет должен быть направлен на то, чтобы сделать этот экран идеальным. Зацикливайтесь на каждой детали. Тратьте все время для полирования каждого пикселя. Не отказывайте себе в удовольствии наслаждаться каждой минутой разработки.
Когда наступит дедлайн или закончится бюджет на разработку, ваш клиент/босс будет очень злым, будет кричать на вас, что вы не сделали все остальное фуфло, которые они хотели втиснуть в пользователя. Будьте немым, извиняйтесь и заработайте репутацию того, кто никогда не закончит ничего…
Проваливайте план, чтобы не проектировать ненужные части.
Будем надеяться, что весь ненужный мусор будет откладываться до следующей версии, а пользователь будет наслаждаться чистым продуктом, пока вас не уволят, и тот, кто вас заменит, испортит этот идеал. На рынке нет недостатка в UX-дизайнерах, которые делают то, что им говорят, и то, что от них ожидают. Вот почему так много некачественных продуктов. Не будьте одним из них.
Юзер тесты — это что-то невероятное, это хорошо известный факт. Не важно, насколько невероятно вы умны, и насколько хорош ваш интерфейс. Десять минут юзер-теста на ранних стадиях проекта может уберечь вас от неудачи в конце пути.
Юзер-тесты рулят. Если вы не делаете их — вы идиот.
Тем не менее, юзер-тесты не освобождают вас от необходимости быть умным, работать, потеть над каждой мелочью и пройти через сумасшедший, извилистый, причудливо аморфный процесс проектирования. Вы по-прежнему должны быть гением. И это особенно верно, когда вы разрабатываете инновационное решение или продукты.
Когда дело доходит до инноваций, пользователи могут быть злыми, недалекими, близорукими, тщеславными, глупыми и т.д. И с этим приходится мириться.
Юзер-тесты новых идей отстой. Если вы делаете их — вы идиот.
Когда у вас есть прекрасная новая идея, она начинает свою жизнь с хрупкого зародыша, едва дышащего. Она нуждается в воспитании и нежной заботе, чтобы превратиться в полностью сформированную инновацию, которая сможет стоять крепко на своих двух ногах и выдержать неосторожное обращение с корыстными пользователями. Юзер-тестирование новой идеи как акулотестирование нового ягненка. Это заканчивается плохо, как для идеи, так и для ягненка. Так что не позволяйте вашей идеи идти к непосвященным… но только пока она не будет готова.
Как узнать о том, что идея готова? Когда вы работали над ней достаточно долго, вы начинаете видеть существенные недостатки: проблемы, которые состоят в том, как идея работает в общем, а не в том, как это все совместить с уже существующими. Когда идея начинает работать близко к тому, как вы задумали, что сами начинаете думать об альтернативах – пора проверять.
Вы можете думать, что ошибка кодеров — не ваша вина. Справедливо, но все-таки это ваша ответственность. Так же, как отправка сообщения, которое никогда не будет получено, дизайн, который не будет понят – пустая трата времени. Вы должны понимать свою аудиторию, а ваша аудитория – программисты. Они странные животные, но в конце концов вы тоже.
Если вы хорошо заботитесь о дев отделе, разработчики сделают вас богатым и знаменитым.
Научитесь уже кодить, вообще-то уже пора, но пока вы этого не сделали, вот что нужно знать о программистах:
Разработчики не исследуют хорошо разработанные приложения и сайты, чтобы узнать, как они создавались. Они тратят свое время на обучение с помощью демоверсий и руководств, которые написаны другими кодерами, пытаясь объяснить сложные понятия кодирования, используя надуманные и смешные примеры.
Учебники по программированию учат худшим UX-практикам.
Они не думают о реальном применении этих примеров. Они не думаю о UX этих примеров. Их не заботит, приведут ли эти примеры к положительным результатам в своих вымышленных сценариях.
Тысячи разработчиков изучают свое ремесло, слепо реализуя чрезмерно простые, плохо разработанные, глупые сценарии. Они разрабатывают свои приложения с помощью нескольких неуклюжих форм и сотен часов безумных руководств. Так что, возможно, вы должны быть немного более конкретными с вашими спецификациями?
Программистам приходится беспокоится о вещах, о которых не подумает ни один нормальный человек. Вы можете поместить поле «Фамилия» в ваш дизайн, но у программиста возникнет сотня тревог:
• Что делать, если у человека нет фамилии?
• Что делать, если фамилия выражается в виде математического уравнения?
• Что делать, если фамилия длиннее 255 символов?
• Что делать, если фамилия содержит символы табуляции, несколько абзацев, неразрывные пробелы, смайлики, круглые скобки, запятые, одинарные и двойные кавычки?
• Что делать, если фамилия изменяется со временем?
Для любого нормального человека, эти вопросы являются абсурдными, но для программистов — нет. Для дизайнера это значит, что он должен держаться рядом с программистами, понять их как можно лучше, чтобы предвидеть подобные тревоги, и удержать их от полной невменяемости.
Четыре истины о дизайне
Вообще-то это не сложно, даже в половину не так трудно, как вы думаете.
1. Цвет не имеет смысла
Пользователи не понимают вашего цветокодирования. Зеленый значит «хороший» для вас, но для кого-нибудь другого на другом экране это может значит «нечитаемое» или «гусиное дерьмо» или «Сайгон? Что? Я до сих пор в Сайгоне?». Каждый человек видит цвет исключительно по-своему, если вообще видит. Он любит одни цвета, и ненавидит другие. И это в значительной степени непредсказуемо. Вы не сможете угадать.
Цвет не является вербальным или рациональным. Он контекстен и эмоционален. Цвет — сильный инструмент, но сам по себе он не имеет смысла.
Единственное что вы можете сделать с цветами это:
Любой цвет: элемент имеет цвет
Другой цвет: элемент отличается от другого элемента
Серый: что-то сломано
Красный: дизайнер ненавидит вас и хочет разозлить
2. Наибольшее значение имеет позиция
Пользователей не заботит, что значат ваши иконки на кнопках, или что на них написано. Вы можете изменять их каждый день, и никто не будет жаловаться.
Измените позицию элементов, и пользователи насадят вашу голову на пику.
Люди используют их моторную память при использовании приложений. Перемещение элементов интерфейса ощущается как изощрённый метод пыток. Если вы хотите знать, что такое чистая нефильтрованная горящая ненависть, идите и поменяйте несколько элементов местами.
3. Никто не читает
Вы, скорее всего, не читаете это предложение. Если читаете, то вероятно, не читали эту статью целиком с первого раза. Вы пробежались от заголовков к цитатам и может быть пропустили пару пунктов перед тем как прочитать этот абзац. Так что это правда. И тем не менее, почему же мы пишем пояснительный текст? Почему мы позволяем себе длинные параграфы в наших интерфейсах? Почему мы делаем вид, что руководство пользователя и часто задаваемые вопросы являются правильным решением для проблем юзабилити?
Потому что мы ленивые, вот почему! Слишком ленивы, чтобы читать, и слишком ленивы, чтобы не писать.
4. Навигация — это провал
Не гордитесь вашим интерфейсом навигации, или информационной архитектурой. Если важной частью вашего интерфейса является навигация, вы уже на пути к провалу.
Ваша задача – помочь пользователю достичь своей цели. Навигация по приложению НЕ цель пользователя. Если вы сделали свою работу правильно, ваше приложение будет делать только одну вещь и будет делать это хорошо, находясь все это время на одном экране. Но вы не в состоянии решить что-либо за пользователя или вовсе устранить выбор, и вы оставляете выбор на откуп пользователю пользователю.
Дизайн – это принятие тяжёлых решений, для того, чтобы избавить от принятия решения пользователя.
Да, хорошо, навигация необходима для большинства приложений, большинства сайтов, и пользователь, в конце концов, привык пользоваться навигацией. Мы должны пойти на некоторые компромиссы. Я безусловно согласен. И почти всегда иду на этот компромисс и внедряю навигацию. Тем не менее, мне стыдно и вам должно быть.
Три истины о процессе
Не все части приложения одинаково важны. Есть некоторые вещи, которые вы должны сделать в первую очередь, некоторые вещи про которые не стоит забывать, и некоторые, которые можно полностью проигнорировать.
5. Контент – хорошо, UI – плохо
Моей первой UX-работой еще до того, как концепция UX была сформулирована, была Информационный Архитектор. Это до сих пор наиболее важная работа, которая есть на любом проекте. Вещи имеют имена и должны быть названы. Определение имен и глаголов является наиболее важной частью UX.
Контент является решением. Если вы не проектируете контент, вы проектируете проблемы.
Каждый раз, когда вы создаете каркасы с Lorem Ipsum, вы оскорбляете своих пользователей и злоупотребляете доверием вашего клиента. А также саботируете сами себя.
Loremipsitis – это плохо, поверьте, я видел фото.
Когда вы не в состоянии бороться с фактическим содержанием, но сосредоточены на проектировании каркасов, которые будут независимы от содержания, вы на самом деле создаете барьер между пользователем и их целью. Прекратите немедленно. Спроектируйте контент и вы, скорее всего, справитесь с задачей автоматически.
6. Прокрастинация – это хорошо
Делайте карту сайта и навигацию в последнюю очередь. Вообще-то, не делайте их вовсе. Начните с самых важных объектов на экране: с того, который помогает пользователю достичь своей цели. Все излишки времени и бюджет должен быть направлен на то, чтобы сделать этот экран идеальным. Зацикливайтесь на каждой детали. Тратьте все время для полирования каждого пикселя. Не отказывайте себе в удовольствии наслаждаться каждой минутой разработки.
Когда наступит дедлайн или закончится бюджет на разработку, ваш клиент/босс будет очень злым, будет кричать на вас, что вы не сделали все остальное фуфло, которые они хотели втиснуть в пользователя. Будьте немым, извиняйтесь и заработайте репутацию того, кто никогда не закончит ничего…
Проваливайте план, чтобы не проектировать ненужные части.
Будем надеяться, что весь ненужный мусор будет откладываться до следующей версии, а пользователь будет наслаждаться чистым продуктом, пока вас не уволят, и тот, кто вас заменит, испортит этот идеал. На рынке нет недостатка в UX-дизайнерах, которые делают то, что им говорят, и то, что от них ожидают. Вот почему так много некачественных продуктов. Не будьте одним из них.
7. Юзер-тесты убивают детей
Юзер тесты — это что-то невероятное, это хорошо известный факт. Не важно, насколько невероятно вы умны, и насколько хорош ваш интерфейс. Десять минут юзер-теста на ранних стадиях проекта может уберечь вас от неудачи в конце пути.
Юзер-тесты рулят. Если вы не делаете их — вы идиот.
Тем не менее, юзер-тесты не освобождают вас от необходимости быть умным, работать, потеть над каждой мелочью и пройти через сумасшедший, извилистый, причудливо аморфный процесс проектирования. Вы по-прежнему должны быть гением. И это особенно верно, когда вы разрабатываете инновационное решение или продукты.
Когда дело доходит до инноваций, пользователи могут быть злыми, недалекими, близорукими, тщеславными, глупыми и т.д. И с этим приходится мириться.
Юзер-тесты новых идей отстой. Если вы делаете их — вы идиот.
Когда у вас есть прекрасная новая идея, она начинает свою жизнь с хрупкого зародыша, едва дышащего. Она нуждается в воспитании и нежной заботе, чтобы превратиться в полностью сформированную инновацию, которая сможет стоять крепко на своих двух ногах и выдержать неосторожное обращение с корыстными пользователями. Юзер-тестирование новой идеи как акулотестирование нового ягненка. Это заканчивается плохо, как для идеи, так и для ягненка. Так что не позволяйте вашей идеи идти к непосвященным… но только пока она не будет готова.
Как узнать о том, что идея готова? Когда вы работали над ней достаточно долго, вы начинаете видеть существенные недостатки: проблемы, которые состоят в том, как идея работает в общем, а не в том, как это все совместить с уже существующими. Когда идея начинает работать близко к тому, как вы задумали, что сами начинаете думать об альтернативах – пора проверять.
Две истины о программистах
Вы можете думать, что ошибка кодеров — не ваша вина. Справедливо, но все-таки это ваша ответственность. Так же, как отправка сообщения, которое никогда не будет получено, дизайн, который не будет понят – пустая трата времени. Вы должны понимать свою аудиторию, а ваша аудитория – программисты. Они странные животные, но в конце концов вы тоже.
Если вы хорошо заботитесь о дев отделе, разработчики сделают вас богатым и знаменитым.
Научитесь уже кодить, вообще-то уже пора, но пока вы этого не сделали, вот что нужно знать о программистах:
8. Программисты учатся на ужасных примерах
Разработчики не исследуют хорошо разработанные приложения и сайты, чтобы узнать, как они создавались. Они тратят свое время на обучение с помощью демоверсий и руководств, которые написаны другими кодерами, пытаясь объяснить сложные понятия кодирования, используя надуманные и смешные примеры.
Учебники по программированию учат худшим UX-практикам.
Они не думают о реальном применении этих примеров. Они не думаю о UX этих примеров. Их не заботит, приведут ли эти примеры к положительным результатам в своих вымышленных сценариях.
Тысячи разработчиков изучают свое ремесло, слепо реализуя чрезмерно простые, плохо разработанные, глупые сценарии. Они разрабатывают свои приложения с помощью нескольких неуклюжих форм и сотен часов безумных руководств. Так что, возможно, вы должны быть немного более конкретными с вашими спецификациями?
9. Программисты любят нелепость
Программистам приходится беспокоится о вещах, о которых не подумает ни один нормальный человек. Вы можете поместить поле «Фамилия» в ваш дизайн, но у программиста возникнет сотня тревог:
• Что делать, если у человека нет фамилии?
• Что делать, если фамилия выражается в виде математического уравнения?
• Что делать, если фамилия длиннее 255 символов?
• Что делать, если фамилия содержит символы табуляции, несколько абзацев, неразрывные пробелы, смайлики, круглые скобки, запятые, одинарные и двойные кавычки?
• Что делать, если фамилия изменяется со временем?
Для любого нормального человека, эти вопросы являются абсурдными, но для программистов — нет. Для дизайнера это значит, что он должен держаться рядом с программистами, понять их как можно лучше, чтобы предвидеть подобные тревоги, и удержать их от полной невменяемости.
