Читать книгу "Этой кнопке нужен текст. O UX-писательстве коротко и понятно - Кирилл Егерев"

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

Стоп, что? Да, дизайн – это лишь видимая часть того, чем мы пользуемся. А пользовательский опыт – то, как мы это делаем. Например, нарисованная на экране кнопка – это в большей степени её дизайн. Форма, размер шрифта внутри неё, тень – всё это признаки видимого интерфейса, которые обычно описываются в дизайнерских гайдлайнах.

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

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

Сами посмотрите: ниже два совершенно одинаковых меню с одинаковым внешним видом – дизайном. Однако меню находятся в разных местах экрана – пользовательский опыт различается.

Чтобы дотянуться до меню на левом рисунке, нужно раза в два «растянуть» большой палец руки, в которой вы держите телефон, или задействовать вторую руку.

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

Всё это хорошо. Но всё же при чём тут слова?

Текст присутствует почти везде, где люди взаимодействуют с вашим продуктом. Даже больше того: когда пользователь сталкивается с чем-то непривычным или до этого ему неизвестным, именно внятное объяснение помогает ему не растеряться. И будь это объяснение текстовое или голосовое – не важно, лишь бы продукт говорил с человеком на понятном тому языке. Не значками или картинками, которые каждый новый пользователь может понять по-своему, а нормально сформулированными фразами.

Бывает, люди даже читают всё, что написано на экране: пункты меню, объясняющие фрагменты текста, заголовки, надписи на кнопках, всплывающие подсказки, примеры заполнения форм, предупреждения, сообщения об ошибках и многое другое. Чаще всего подобное происходит при взаимодействии с совершенно новыми или значительно обновлёнными продуктами. Тут особенно важно, как вы всё сформулируете.

И это касается не только интерфейса самого продукта. Например, если речь идёт о новой версии мобильного приложения, то пользовательский опыт может транслироваться наружу – в тексте «Что нового» в магазине приложений. Можно сообщить об изменениях дежурно, сухо и без подробностей:

Исправили ошибки, устранили недочёты.

Но какие именно ошибки и недочёты? Изменили ли вы то, что так беспокоило меня весь последний год? А вот я помню, был серьёзный недочёт. Не помню, какой именно. Но точно помню, что был. Сейчас запущу приложение и сразу вспомню. Интересно, его вы тоже устранили?

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

Помните, как приложение вылетало при редактировании профиля? Так вот, разработчики говорят, что устранили все возможные причины этого.

И дополнить общим:

Заодно мы поправили разные мелочи. Попробуйте сделать всё то, что раньше вызывало ошибки. Если заработает как надо – хорошо. А если нет – напишите нам о недочётах на почту саппорт@нашапочта.ру. Постараемся помочь.

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

Идём дальше. Если в приложении появилось что-то полезное, не только исчезли ошибки, то при первом запуске сразу после обновления вы можете показать пользователям экран с рассказом о новинках. Или два, три экрана – насколько у вас хватит фантазии, а у пользователей – терпения:

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

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