Этой кнопке нужен текст - [4]
UX-писатель работает с дизайнерами, проектировщиками и исследователями с нуля – когда есть только концепция продукта и ещё нет внешнего вида, интерфейса. Такой специалист хоть и пишет, но это далеко не вся его работа – он сам немного дизайнер, исследователь, проектировщик и даже психолог. Он не просто «наваливает» текст в жёстко заданные рамки, а определяет эти рамки. Попутно указывает на сложности, которые могут возникнуть у пользователей, и расширяет «узкие горлышки».
UX-писатель выстраивает взаимодействие пользователя с продуктом в виде логично связанного диалога. Он постоянно улучшает качество этого диалога, сглаживает шероховатости и помогает людям проходить полезные сценарии – вот основные задачи такого специалиста.
Как читать эту книгу
Как многие нехудожественные издания, эту книгу можно читать почти в любой последовательности и даже не целиком.
Если вам надо только подсмотреть возможные формулировки интерфейсных элементов, то открывайте сразу третью часть. Там же больше всего картинок. В последних главах я на конкретных примерах показываю, как писать текст для кнопок, пунктов навигационных и контекстных меню, чекбоксов, переключателей, а также простой статичный текст.
Если вам нужно «только один хороший интерфейс написать», то будет достаточно третьей части. Полистайте её. После напишете всё максимально нейтрально по шаблону и сдадите проект, а дальше будь что будет.
Если вам захочется в самом деле понять, почему исходные примеры в третьей части плохие, зачем их переписывать и какими правилами можно руководствоваться в работе, начните читать книгу со второй части. В ней всего четыре главы, и все про принципы, которые я обычно применяю. Это они, те принципы, заставляют меня и многих других UX-писателей писать определённым образом. Во второй части я отвечаю только на один вопрос: «Как?»
В первой части, где я постарался найти ответы на максимум вопросов, больше всего слов и, по мнению некоторых, меньше дела. В ней есть советы и для UX-писателей по работе в команде, и для руководителей, которым бывает трудно понять людей относительно новой профессии. Первые несколько глав я говорю об обычных трудностях в команде и способах их решения.
Если не спешить и не пропустить начало, то можно даже понять, как формировались мои рабочие принципы. Те, о которых я рассказал во второй части. А после можно не следовать моим или ещё чьим-то правилам, а дополнить их, изменить, доработать, создать собственные и аргументированно заявить о своём превосходстве.
Что пропускать, а что нет – решать вам. Вы, а не я, сейчас читаете эти строки, имеете определённые потребности и располагаете каким-то временем. Но я рекомендую вам прочесть эту книгу от начала и до конца. Люди, которых я просил прочесть её до публикации, сказали мне, что она хорошая.
Часть I
Глава 1
Кто прочитает всё это?
В начале работы над продуктом мы уже примерно понимаем его аудиторию – знаем всех, кто станет им пользоваться в первую очередь. Мы представляем себе определённые группы людей – им сколько-то лет, у них схожие привычки и доход, свой распорядок дня и ещё масса объединяющих группу параметров. Все наши будущие пользователи имеют выдуманные нами потребности, которые «закроет» наш продукт. С этим знанием у нас и появилась идея создать нечто новое.
Ну, или мы лишь примерно представляем себе, что нужно людям. Так тоже можно в самом начале. Мы примерно понимаем, что именно должны сделать, чтобы заполучить свою долю рынка, и этого уже достаточно.
Составив список потребностей, мы принимаемся их исследовать. На этом этапе мы задаём все самые важные вопросы и понимаем, действительно ли стоит продолжать работу над задуманным. Мы выстраиваем процесс именно так, потому что точно знаем, что это дешевле, чем работать вслепую и осознать нежизнеспособность продукта лишь на финальной стадии его создания – когда всё уже готово и потрачено много ресурсов.
Моделируя разные ситуации, мы тестируем гипотезы и выясняем, что действительно нужно включить в первую версию продукта, а на что не стоит тратить времени, что можно оставить на потом. Выясняем, чем мы «зацепим» людей. Исследуем, скрупулёзно документируем, сопоставляем и выбираем лучший из возможных путей.
Завершаем этап проектирования пользовательского опыта и начинаем «накидывать» реальный внешний вид продукта. Допустим, мы задумали выпустить мобильное приложение. У него появляются свои цвета и формы. Логика, о которой раньше мы только думали и которую закладывали в прототипы, обретает чёткие очертания.
Наступает тот момент, когда проект уже должен показать себя, – пора его представить людям. И тут мы понимаем, что не можем собрать приличную версию. Большинство текстовых блоков, сообщений об ошибках, подсказок и кнопок заполнено обычными «рыбными» текстами:
Хорошо, предположим, тексты не совсем «рыбные» – не дизайнерские заглушки на латыни. И они даже нормально работали в прототипах на фокус-группах. Только вот их стыдно показать людям – реальным пользователям, которые получат продукт не бесплатно, а им придётся за него заплатить. Или заплатить за какие-то расширенные возможности. Или потратить время на просмотр рекламы. Даже зарегистрироваться – уже напряг. Так или иначе, их вход будет сложнее, чем у людей, которые участвовали в ваших экспериментах и получили за это деньги. И вот тут нужен особенный подход.
