Экран для незнакомцев
Приложение Banjang Note, над которым я сейчас работаю, предназначено не только для людей, принадлежащих к определённой организации. Его целевая аудитория — подённые рабочие и бригадиры, работающие на строительных объектах полупроводниковых предприятий. Это люди, которые набирают работников непосредственно на объекте и ищут работу, когда хотят выйти на неё. Они относятся к довольно незнакомой мне сфере, с которой я практически не сталкивался. Поэтому с самого начала разработки этого приложения я испытывал определённую неуверенность.
Создавая программное обеспечение для специалистов, можно проектировать экраны, исходя из предположения, что пользователи уже понимают контекст своей работы. Но непосредственно перенести это предположение на Banjang Note было сложно. Вместо того чтобы заранее делать выводы о возрасте пользователей или уровне владения смартфоном, нужно внимательнее посмотреть, какие элементы могут показаться им непривычными при первом знакомстве с экраном. Проектирование экранов без предположения, что пользователи уже знают, что делать, отличается сильнее, чем может показаться. Ведь при этом меняется сам набор вещей, которые нужно учитывать при создании экрана.
Тревога от мысли: а поймут ли они?
Поэтому всякий раз, создавая экран, я испытываю лёгкую тревогу. Сразу ли пользователи поймут, что произойдёт после нажатия этой кнопки? Не растеряются ли они и поймут ли, что делать дальше после прочтения этого текста? Не покажется ли им это слово непривычным? Я постоянно задаю себе подобные вопросы.
Например, я потратил много времени на выбор даже одного-единственного текста-подсказки в поле ввода. Я обдумывал, не стоит ли использовать разные инструкции в зависимости от типа поля: «Введите ~» для текстовых полей, «Выберите ~» для полей выбора и «Введите только цифры» для полей, принимающих только числа. С точки зрения пользователя это может показаться мелочью, но я считал, что именно здесь проходит граница между ситуацией, когда человек сразу понимает, что вводить в поле, и ситуацией, когда он этого не понимает. Использовать одно слово «Введите» повсюду было бы удобнее, но я подумал, что пользователи могут попытаться ввести текст в поле, принимающее только цифры, и столкнуться с ошибкой.
Особенно при проектировании UI я каждый раз заново обдумывал, можно ли без изменений применять привычные дизайнерские соглашения — например, исходить из того, что пользователи интуитивно поймут назначение элемента, если у него есть иконка, или что людям знаком такой уровень взаимодействия, поскольку сегодня им пользуются все. Эти интуитивные представления естественным образом формируются благодаря ежедневному использованию смартфонов и различных приложений, но они не обязательно совпадают с представлениями целевых пользователей.
На самом деле эта тревога не была чем-то плохим. Напротив, каждый раз при создании экрана она заставляла меня снова посмотреть на него с точки зрения пользователя. Я напоминал себе, что пользователи гораздо лучше меня разбираются в работе и сценариях экранов, с которыми связано это приложение, а незнакомцем в этой сфере являюсь именно я. В результате я естественным образом начал отказываться от предположения, что пользователи сами собой поймут такие вещи. Так я нашёл направление: писать полезно и понятным образом, естественно подводя пользователей к следующему действию. Я хотел с помощью текста направлять их так, чтобы при взгляде на экран им не приходилось останавливаться или самостоятельно решать, что делать дальше.
Но полученная мной обратная связь была прямо противоположной
И тут возникла проблема. Мне рекомендовали использовать максимально краткие формулировки для названий кнопок. Я хотел писать понятно и пояснительно, но от меня требовались короткие и однозначные формулировки. Например, сначала я писал названия кнопок в тоне мягкого побуждения к следующему действию, используя формулировку «Перейти ко входу». Поскольку нажатие кнопки не выполняло вход непосредственно, а переводило пользователя к процессу входа, мне казалось более уместным использовать формулировку, передающую смысл перехода, например «Перейти к ~», а не существительное «Вход».
Но мне предложили сократить её до чего-то вроде «Войти». Сначала я беспокоился, что слишком короткая формулировка будет казаться чересчур сухой и холодной или что пользователи не поймут, выполнит ли нажатие немедленный вход или переведёт их на страницу входа. Эта обратная связь указывала в направлении, отличном от задуманной мной понятности. Я считал, что быть полезным — значит добавить достаточно пояснений, но тогда ещё не понимал, что в контексте кнопки это может дать обратный эффект.
Похожую обратную связь я получил и по поводу главного экрана. В верхней части я добавил приветствие вроде «Здравствуйте, пользователь~ Берегите себя и сегодня!», но мне сказали, что такое сообщение не нужно. Более того, я считал его естественным элементом экрана, поскольку подобные приветствия часто встречаются во многих приложениях. Обращение к пользователю по имени и приветствие могут создать ощущение, что приложение его узнаёт, а также чувство близости — словно один человек разговаривает с другим. Вероятно, поэтому такие приветствия часто используют в начале работы с сервисом: чтобы смягчить тон и сделать приложение менее непривычным.
Но для пользователей Banjang Note такое приветствие могло выглядеть украшением, не связанным с целью использования приложения. Обычно люди открывают Banjang Note, когда ищут место работы на этот день, проверяют статус заявки или срочно пытаются найти работников. Если разместить приветствие перед этой информацией, пользователю придётся сделать ещё один шаг, прежде чем он доберётся до действительно нужных сведений. Эта обратная связь заставила меня пересмотреть мысль о том, что текст, призванный создать ощущение близости, может, наоборот, на шаг отдалить пользователя от его цели.
Оглядываясь назад, я понимаю, что причины в обоих случаях — с названиями кнопок и с приветствием — были похожими. Кнопка — это элемент, который пользователь должен сразу распознать и нажать за короткое время, пока просматривает экран. Если предложение внутри кнопки становится длинным, его чтение занимает больше времени. Чем дольше взгляд задерживается на нём, тем выше вероятность, что пользователь начнёт сомневаться: «А точно ли можно нажать эту кнопку?» То же относится и к приветствиям: каждый раз, добавляя сообщение, не являющееся необходимым для экрана, вы увеличиваете путь пользователя к информации, которую он на самом деле ищет. Только после этой обратной связи я по-настоящему понял, что полезность не всегда означает добавление ещё одной строки текста.
Поэтому я нашёл компромисс
В итоге я пришёл к выводу, что кнопки должны быть краткими, а там, где требуются пояснения, нужно давать ясные и действительно полезные инструкции. Кнопке достаточно коротко и понятно сообщить пользователю, какое действие он сейчас выполняет. Например: «Подтвердить», «Удалить» или «Далее». Без лишних слов пользователь должен понимать смысл, как только его взгляд останавливается на кнопке. Я смирился с тем, что в данном контексте попытка смягчить формулировку или объяснить ситуацию может, наоборот, мешать.
Вместо этого в областях, где нужны пояснения, — например, на экранах онбординга, в справочных текстах и пустых состояниях — я писал максимально просто и тепло. Например, на пустом экране, где ещё нет данных, я сочетал сообщение, объясняющее ситуацию, вроде «Нет активных объявлений о работе. Зарегистрируйте объявление сейчас!», с кнопкой действия. Это подсказывало пользователю, что делать дальше, и избавляло его от необходимости самостоятельно принимать решение. Поскольку здесь у пользователей есть время на чтение, я решил, что именно в таких местах лучше быть достаточно подробным и полезным.
После такого разделения ролей мне удалось найти баланс: кнопки стали понятными, а экран в целом сохранил полезность. Я понял, что не стоит подгонять каждый фрагмент текста под единый тон — лучше менять тон в зависимости от роли, которую каждый элемент играет на экране.
Мои принципы UX-райтинга, сформированные благодаря этому опыту
После этого опыта я сформулировал несколько принципов, которыми пользуюсь при написании текстов.
1. Форма полезности зависит от контекста. Элемент, требующий немедленного решения, например кнопка, и место, где пользователь может спокойно прочитать текст, например онбординг или инструкция, должны выражать полезность по-разному. В первом случае полезны краткость и ясность, во втором — достаточное количество пояснений. Вместо того чтобы навязывать всему экрану один и тот же тон, я понял, что его адаптация под ситуацию — это тоже способ учитывать пользователя.
2. Цель — избавить пользователей от необходимости «думать». Полезный текст — это текст, перед которым пользователю не приходится останавливаться и раздумывать. Дело не в том, чтобы добавить много пояснений, а в том, чтобы пользователю не нужно было самостоятельно догадываться, что делать дальше. Я понял, что полезность следует оценивать не по длине предложения, а по степени замешательства, которое оно вызывает у пользователя.
3. Не приравнивайте привычные вам интуитивные представления к представлениям пользователя. Как дизайнер, ежедневно сталкиваясь с множеством приложений, вы начинаете считать очевидным, что пользователи тоже всё это знают. Но такое ощущение основано на вашем собственном опыте, а не на опыте целевых пользователей. Чем меньше вы знакомы с определённой группой пользователей, тем чаще нужно заново ставить под сомнение то, что кажется вам очевидным.
4. Сокращайте повторы и бессмысленные тексты. Стремясь писать понятно и полезно, вы при повторном чтении можете обнаружить, что дважды говорите об одном и том же. Достаточные пояснения и повторение одной мысли — не одно и то же, но во время написания эту разницу не всегда легко заметить. То же относится к текстам, которые лишь добавляют тон — например, к приветствию, не связанному с целью экрана. Оно может смягчить атмосферу, но если пользователи могут понять и использовать экран без него, нет причин его добавлять. После написания всех текстов я понял, что нужно выработать привычку читать их вслух и проверять, не повторяет ли последнее предложение то, что уже было сказано в предыдущем, а также не создаст ли удаление текста проблем для пользователей при работе с экраном.
5. Различайте повседневные термины и термины, которым нужно учиться. Выбирая слова для текста, я сначала стараюсь определить, используют ли пользователи это слово в повседневной жизни или оно встречается только в данном приложении либо сфере работы и может показаться непривычным при первом знакомстве. В последнем случае я предпочитал не использовать слово на экране как есть, а объяснять его простыми словами или добавлять краткое пояснение при первом контакте — например, в онбординге или всплывающей подсказке. И наоборот, я понял, что излишнее пояснение слов, уже знакомых пользователям, лишь делает предложение длиннее и неуклюжее.
Ещё я понял, что одно название кнопки может повлиять на трудозатраты при разработке и стабильность макета. Испытав это на собственном опыте, я осознал, что текст — не вопрос личных предпочтений дизайнера, а результат сотрудничества и согласования с разработчиками и издателями. Я также понял, что растерянность, которую испытал, впервые получив обратную связь «Пожалуйста, пишите кратко», на самом деле не была следствием столкновения разных предпочтений. Она отражала разницу в подходах: одну и ту же цель нужно по-разному интерпретировать в зависимости от контекста. Вместо того чтобы защищаться от обратной связи, я научился сначала понимать её контекст и причины.
В конечном счёте UX-райтинг заключался в том, чтобы убрать себя из уравнения
Когда названия кнопок становятся длиннее, у разработчиков сразу появляется больше исключительных случаев, а у издателей возникают проблемы вроде переносов строк или нарушения размеров кнопок. Поняв, что предложение, удлинённое из моего желания писать «полезно», может повлиять на работу других специалистов, я осознал: просьба делать названия кнопок краткими — не вопрос вкуса. Это скорее минимальное правило, которому необходимо следовать на экранах, над которыми совместно работают специалисты разных направлений.
Оглядываясь назад, я понимаю, что моё желание хорошо писать тексты для UX началось с ощущения давления: я должен сделать так, чтобы пользователи всё поняли. Но на самом деле требовалось не писать полезно по-своему, а развить чувство, позволяющее различать подходящий тон для каждого экрана и элемента. Нужно было признать, что у кнопок есть роль кнопок, а у пояснительного текста — роль пояснительного текста. Критерием для определения этих ролей должны быть не мои личные предпочтения, а реальные потребности пользователей на данном экране.
Eykim