Последнее время на работе приходится много заниматься текстами для интерфейсов, поэтому мы с коллегами решили подтянуть матчасть и пошли учиться на курс «UX-писатель» в Нетологию. В этой статье расскажу, как там всё устроено, что полезного я сохранила в заметках и какие получились практические работы. А в конце — подборка материалов по UX-копирайтингу.

Сам курс состоит из 6 заранее записанных видеоуроков и 2 вебинаров. У нас был еще один бонусный вебинар от Иры Моториной про то, зачем нужно «отзумливать» проект и как это сделать по уму. Это что-то вроде компенсации от Нетологии за дезинформацию: компания забыла предупредить, что на нашем потоке вебинаров Иры не будет, а ведь большинство пришло именно ради них. Поэтому инсайт №1: не стоит идти в Нетологию на конкретных преподавателей 😉

Дальше пойдем прямо по учебному плану.

Специфика текстов для интерфейсов

Три принципа, на которых должен базироваться текст (по уменьшению значимости):

• уровень 1 — точность,
• уровень 2 — дружелюбность,
• уровень 3 — выразительность.

Так спикер объяснил место UX-писателя в продуктовой команде. Слайд из презентации

Задание: составить UX-мудборд. Для этого подобрать несколько приложений или сайтов, сделать скриншоты и разобрать плюсы и минусы. В итоге должен получиться мини-анализ конкурентов.

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

Таким получился мой UX-мудборд

Job Stories и Storyframes

Фичи не рождаются из ниоткуда, поэтому следующий этап работы над продуктом — Discovery. Это когда мы раскапываем контекст. У нас еще нет конкретных задач, лишь хотим выяснить:

• кто наша аудитория,
• для чего люди используют наш продукт,
• как они решают задачи,
• как мы им можем в этом помочь => какие фичи нужно делать.

Здесь не идет речь про текст, и это нормально: большую часть работы UX-писателя занимают исследования и тесты, а буквы — лишь вишенка на торте.

Job Stories

Это такие небольшие емкие истории о том, какая у человека проблема, как он хочет ее решить и что хочет получить в результате. Чтобы их собрать, нужно:

• использовать опыт реальных людей (форумы, релиз ноутс, чаты);
• попытаться понять мотивацию (использовать открытые вопросы);
• использовать несколько точек зрения — например, для приложения по страховке нужно поговорить как с теми, кто страхуется (=клиенты), так и с теми, кто страхует (=страховщики);
• учитывать контекст, когда человек использует продукт — например, каждый день или раз в месяц. Смотреть на ситуацию: молодые мамы 99% времени заняты ребенком, а у водителя во время езды свободна только одна рука.

Для такого исследования идеально поговорить с 5-8 людьми. Если не можем пообщаться с реальными клиентами, можно найти похожих людей: например, не обязательно идти к тем, кто работает именно в Яндекс.Такси — подойдет любой таксист.

Как выглядят Job Stories. Собрала одну общую схему на основе нескольких слайдов из презентации

Storyframes

Это диалог между продуктом и человеком от онбординга до финального действия — так легче представить, какие вопросы могут появиться у человека и как ему ответит продукт. На этом этапе у нас уже есть технические требования и требования бизнеса, поэтому можно перейти от болей к базовому проектированию и начать проработку хотелок продактов.

Попросту говоря, главная задача сторифреймов — собрать мысли в кучку и думать о продукте быстрее. В итоге получится:

• продумать сценарии и легко заметить нестыковки, если мы что-то не учли;
• представить, какие термины нужны и как будет говорить продукт;
• понять логику и продумать подсказки — например, что пять экранов назад мы говорили это, а значит, сейчас должны сказать вот то.

Сторифреймы бывают разными:

• просто перечисление фич — подойдет, когда работаешь один, но для 2-3 человек уже неудобно;
• сплошной диалог, как пьесса для театра;
• диалоги, сразу наглядно разбитые на нужные экраны со связями между ними. Такие сторифреймы предпочитает Ира Моторина — вот ее статья об этом.

Собирать сторифреймы удобно в Miro: там есть шаблон Wireframing, в котором можно настроить переходы и указать кнопки. Это помогает понять продуктовую логику и как будет выглядеть интерфейс.

Порядок работы над приложением: начинаем с джобсторисов → прорабатываем сторифреймы → переходим к прототипам, дизайну и буквам. Слайд из презентации

Задание: продумать джобсторисы и сторифреймы для проекта, который мы выбрали еще к прошлому заданию. Естественно, проектировать весь пользовательский сценарий не обязательно, главное — довести до какой-то законченной точки.

Джобсторисы, которые у меня получились для приложения доставки еды из ресторана

Мои сторифреймы для этого же приложения

Создаем продуктовые тексты сами

Хороший текст в интерфейсе:

• подсказывает, что делать;
• предостерегает от ошибок;
• успокаивает и мотивирует повзаимодействовать с продуктом;
• оставляет приятное послевкусие через заботу или шутки.

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

Главное правило в таком диалоге: кнопка — это реплика ПОЛЬЗОВАТЕЛЯ, поэтому обычно там ставится глагол. Еще кнопки должны подсказывать, что будет после нажатия.

Этот экран говорит нам: я хочу пополнить единую транспортную карту стрелка, вот мой номер карты и вот на какую сумму я хочу пополнить. Слайд из презентации

Задание: попрактиковаться в UX-текстах и написать самые распространенные типы текстов — первый экран формы регистрации, ошибку «Нет интернета», экран успеха, пуш-уведомление, поп-ап и запрос разрешения на уведомления.

Никаких макетов к заданию не было, поэтому можно было выполнять его как угодно. Я решила набросать схематичные прототипы — просто потому что сложно писать текст в вакууме.

Тексты для базовых экранов выдуманного приложения

Основы UX-дизайна

В дизайне должны соблюдаться базовые правила:

• визуальная иерархия за счет типографики, размеров, цветов, контрастности и расстояний;
• общие области — мы воспринимаем как группу элементы в пределах одной области и элементы, схожие по размеру, очертаниям, цвету или форме;
• близость — элементы, расположенные близко друг к другу, воспринимаются более связанными, чем те, что находятся на некотором расстоянии;
• узнаваемость иконок, навигации, призывов к действию и распространенных цветовых ассоциаций.

Часто даже при хорошем дизайне люди забывают:

• продумать все возможные случаи с контентом — когда его нет совсем, слишком мало, он ужасный или странный;
• проверить контент на разных устройствах — текст на мобильном телефоне, мониторе компьютера и телевизоре выглядит и воспринимается по-разному.

Гигиена текста в интерфейсе: основные правила, Z и F-паттерн. Слайды из презентации

Задание: продумать контент для своего проекта, пользуясь готовыми шаблонами экранов от Нетологии. Можно убирать блоки, которые там есть, или переставлять их местами, но в макете не должно быть «рыбного» текста.

Я решила не останавливаться только на тексте, поэтому изменила сам дизайн. Мне хотелось, чтобы экраны приложения для ресторана выглядели современными и минималистичными, но не слишком скучными.

В шаблонах все экраны были разного размера, но на этом этапе я не приводила их в единому виду. Тексты могут незначительно отличаться от предыдущего задания, потому что работа шла параллельно, а у преподавателей разные взгляды на идеальный контент

Основы UX-research

Тестировать тексты в интерфейсе нужно:

• перед написанием текста — чтобы определиться с tone of voice (например, обращаться к пользователям на ты или на вы, использовать термины или объяснять все простым языком);
• после логически завершенных блоков — например, написали онбординг и целиком его протестировали;
• когда вводим новую фичу — это поможет выяснить, нужна ли она и понимает ли пользователь, зачем мы ее добавили.

Для качественного исследования (напр., интервью) достаточно 6 человек, для количественного — 30 респондентов.

Какие исследования помогут UX-писателю:

• коридорное тестирование. Подходим к коллегам в коридоре и задаем не больше 5 вопросов. Минус в том, что человек не знает контекст и может ответить не то, что есть на самом деле;
• глубинное интервью. Спрашиваем клиентов о потребностях, но нельзя задавать вопросы о будущем. Минус в том, что ответы не помогут, если заданы не те вопросы и показана информация, вырванная из контекста;
• опросы. Можно использовать соцсети и сервисы вроде Google Forms и Monkey Survey. Главное — формулировать вопросы четко и однозначно;
• 5-секундный тест. Лучше всего подходит для первых экранов и форм захвата. Важно помнить, что на первое впечатление может повлиять не текст, а цвета или формы, неправильно или правильно расставленные акценты;
• close-тест. Убираем из текста в интерфейсе каждое 3 слово и просим вставить пропуски — чем ближе к оригиналу получился текст, тем лучше он написан;
• юзабилити-тест. Формулируем гипотезу и предлагаем респонденту пройти пользовательский сценарий: например, найти на странице информацию о скидках. Главное — не задавать наводящих вопросов и помнить, что пользователь не ошибается;
• А/В тестирование. Можно использовать инструменты Яндекс и Google «Оптимизация». Важно помнить, что пользователи показывают, что лучше в конкретный момент: например, мы выяснили, что синяя кнопка лучше зеленой — а в обычной жизни пользователь просто позвонил бы.

Вид исследования зависит от стадии разработки продукта. Слайд из презентации

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

Я решила эту задачу так. Когда я делала задание по дизайну, меня удивил странный шаблон карточки товара — она длинная, важную инфу мы будто бы скрываем от пользователя. Чтобы выяснить, смущает ли это кого-то, кроме меня, устроила 5-секундный тест: показала макет карточки своим друзьям и спросила о впечатлениях. Удачно сложилось, что мой проект знаком всем: так или иначе все участники пользовались доставками еды раньше.

Моя гипотеза подтвердилась: пользователям некомфортно скроллить карточку товара. Особенное недовольство вызвала цена — она оказалась на втором экране

Tone of Voice для цифровых продуктов

У каждого продукта есть свой голос — даже есть специально им никто не занимается. Он выражается в лексике, использовании юмора, характере, отношении к пользователю и событиям.

Собрать и вместе использовать все договоренности о тексте помогает редполитика или tone of voice. А еще такой документ нужен, чтобы:

• ускорить процессы, когда контентом занимается много людей;
• подчеркнуть индивидуальность продукта;
• транслировать ценности через текст и подачу;
• повысить доверие через постоянство и качество.

Если редполитика и tone of voice — по факту одно и то же, то у голоса и тона есть отличия: голос = личность, характер, топ = эмоциональная окраска речи, применение голоса в конкретной ситуации. При этом голос всегда одинаков, а тон может меняться: например, в ошибках и на страницах успеха обычный тон может быть неуместен.

Задание: определить место продукта на матрице тональности и написать несколько правил для будущей редполитики.

Решила, что мой продукт должен общаться легко и живо, но интеллигентно — как реальный официант или сомелье в ресторане

Анализ эффективности работы UX-писателя

Метрики помогают понять, насколько хорошо вы делаете свою работу, и помогают на одном языке общаться с продактами и руководителями.

Основные метрики для UX-писателя:

• конверсии — показывают вероятность события в воронке. Это основной показатель работы UX-писателя, потому что почти всегда можно выстроить цепочку между хотя бы двумя событиями;
• время на экране — не всегда больше значит лучше (например больше времени на инструкции → лучше разберется, но меньше на странице оформления заказа → быстрее оформит заказ);
• совершенные действия — например, сколько раз за последнюю неделю пользователи активировали новую функцию, которую компания вывела на рынок.
• лиды, триалы и продажи — например, сколько новых пользователей за последнюю неделю мы привлекли => почти как предыдущая метрика, только относится к привлечению новых клиентов и покупкам;
• показатель отказов (Bounce Rate) — показывает, какое количество пользователей закрыли страницу или всплывающее окно, так и не выполнив целевого действия. Всегда больше — хуже.

Когда проверять данные, зависит от того, насколько крупные изменения вы сделали: обновили текст в одном поп-апе — достаточно 4—5 чистых недель, что-то покрупнее — 2—3 чистых месяца. Чистые недели — это исключая те, когда изменения появились в продукте. Базовый период — 4 недели.

Как определиться со временем на сбор данных в зависимости от тяжести преступления, объема данных и ошибок. Слайд из презентации

Как работать с UX-редактором и какие задачи решает текст

Культура работы с UX-писателем:

• Привлекать редактора одновременно с дизайнером — на этапе проектирования. Если просто дать готовые макеты, в которых ничего нельзя трогать, редактор просто станет наборщиком текста и не сможет полноценно решать свою задачу.
• Фиксировать знания о проекте и дать доступ к ним всем участникам. Для этого продакт должен собрать в одном документе наши цели и описание функционала, ссылки на исследования и решения конкурентов, расписать весь путь пользователя и план проекта со сроками, указать контакты всех участников проекта.
• Всегда ставить формальной задачи. У редактора и дизайнера обычно несколько проектов параллельно, поэтому такая формальность поможет зафиксировать договоренности, закрепить ссылки на макеты и документы, отслеживать статус и просто понимать, чем занимается команда.
• Давать аргументированную обратную связь без вкусовщины. Следим, чтобы текст был человечным и соответствовал редполитике, а шутки никого не обижали. При этом на каждом этапе должно быть понятно, что нужно от пользователя, в каком формате это вводить и что будет дальше.
• Позволять каждому члену команды влиять на продукт. UX-писатель — еще один UX-мозг. Поэтому доверяем ему не только «буковки», а также прислушиваемся к мнению о том, как сделать пользовательский опыт лучше.

Задание: представить, что вы переросли копирайтинг и стали тимлидом. У вас две рабочие ситуации — и нужно предложить решение.

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

Как я решала гипотетические ситуации, которые могут возникнуть у тимлида

Дипломная работа

На лендинге курса обещают, что по итогам всех заданий соберется кейс, который можно положить в портфолио и показать будущему работодателю. По структуре диплом и правда похож на проект, если бы не одно «но» — это все выдумка. В реальном проекте миллион ограничений и условий, а здесь мы их выдумывали сами — или не выдумывали, если не хотелось 😀

Хотя не спорю, диплом получился классный: кому интересно, собрала его в гугл-док со всеми ссылками на работы.

Подборка материалов, которые рекомендовали преподаватели

Про работу в команде:

• Intercom’s Jonathon Colman on why content designers should do less
• Как UX-писателю работать в дизайн-команде — запись вебинара Иры Моториной
• Как UX-писателю работается в команде с дизайнерами — выступление Иры Моториной на какой-то конференции
• Как UX-писатель помогает улучшить продукт — кейс «Собаки Павлова»

Про Job Stories и CJM:

• Use Job Stories To Hook Users
• Конспект книги Роба Фитцпатрика «Спроси маму» — статья на VC
• Составляем Customer Journey Map: советы и инструменты — статья в блоге Нетологии
• Как Emotional Journey Map помогает конструировать Tone of Voice — статья Иры Моториной

Про проектирование текста:

• Как сторифреймы помогают проектировать приложения — статья Иры Моториной
• Storyframes before wireframes
• Сторифреймы. Зачем и как их составлять — еще одна статья Иры Моториной на эту тему
• Законы дизайна интерфейсов — законы и эффекты человеческого восприятия, которые прямо влияют на проектирование взаимодействия
• Лайфхаки для UX-писателя — выпуск подкаста «Редач» о том, как знание верстки и психологии помогает UX-писателям
• Как тестировать контент с пользователями — статья Александра Марфицина

Про текст, tone of voice и глоссарий:

• How to use voice and tone in UX writing
• Что такое голос бренда, зачем он нужен и как его найти — статья Александра Марфицина
• Things I learned designing the voice and tone for our company
• Create your own thesaurus
• How to choose your tone of voice
• Тексты для интерфейса: как пишут контент в Тинькофф Бизнес — конспект выступления Анны Кочетковой из Тинькофф Бизнеса на UX Марафоне
• Текст отбрасывает хвост — доклад Наташи Гермогентовой про эволюцию текста в интерфейсе
• Исследователи из Nielsen Norman рассказали, как люди читают текст в интернете и что изменилось за последние 15 лет — статья на VC

***
Мой вывод о курсе такой: он очень базовый и подойдет тем, кто ВООБЩЕ ничего не знает о UX-текстах. А вот есть какой-то опыт, вы читали рассылку Иры Моториной или учились в Школе редакторов — новой информации будет мало.

Самой полезной для меня была лекция про джобсторисы и сторифреймы — их я точно возьму в копилку рабочих приемов. И еще раз хочу отметить классную лекцию Леры Железовой из Сбербанка о том, как работать с UX-редактором: она очень классно разложила по полочкам принципы, которые раньше я чувствовала только интуитивно.

Ну и оставлю здесь удостоверение об окончании курса на память :)

Джеф Раскин известен как специалист по компьютерным интерфейсам и инициатор проекта Macintosh или Mac — персональных компьютеров Apple. Свой опыт он обобщает в книге «The Humane Interface», которая была издана в 2000 году.

По мнению Раскина, интерфейс считается человекоориентированным, если он отвечает нуждам человека и учитывает его слабости. В книге он говорит, как разрабатывать интерфейсы с учетом принципов когнетики и решить проблемы взаимодействия человека с компьютером.

***

Интерфейс — это то, как вы решаете задачу с помощью продукта. Т. е. это совершаемые вами действия и то, что вы получаете в ответ.

Основные идеи
Простое должно оставаться простым

Установить время на механических часах гораздо проще, чем на электронных. Поэтому их интерфейс лучше.

Какой сложной бы не была система, простые задачи должны оставаться простыми.

Задача — проектирование — разработка

Пользователи не задумываются над тем, как устроена машина, пока она справляется со своими задачами. Им не важен процессор и вся техническая начинка, имеет значение лишь удобство и результат. Но видят они только интерфейс — значит, для них это конечный продукт.

На первом этапе разработки нужно определить, что именно
должен сделать пользователь для получения результата и как система должна отвечать на каждое его действие. В ходе работы определение задачи скорее всего будет меняться.

Определив задачу, для которой предназначен продукт, сначала спроектируйте интерфейс, а потом приступайте к его реализации.

Человек концентрируется только на чем-то одном

Одно из самых важных ментальных ограничений человека — у нас только один локус внимания. Это значит, что из всех объектов или явлений окружающего мира, которые вы воспринимаете с помощью своих чувств или воображения, в каждый момент времени вы можете сконцентрироваться только на одном.

Пользователь, поглощенный своей задачей, не замечает уведомления, подсказки и другие попытки системы пообщаться с ним.

Единственное, чем мы можем помочь — это сделать так, чтобы пользователь не мог совершить ошибок или имел возможность сразу отменить результаты своего действия.

Хороший интерфейс работает независимо от степени поглощенности пользователя. Предупреждения о потенциальных ошибках бесполезны.

Нужно учитывать привычки

При постоянном использовании интерфейса у вас формируются определенные привычки. Любая привычка означает отказ от внимания к деталям. В этом смысле задача дизайнеров заключается в том, чтобы создавать интерфейсы, которые не позволяют привычкам вызывать проблемы у пользователей.

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

Любой запрос о подтверждении, требующий установленного ответа, вскоре становится бесполезным.

Обратной связи недостаточно

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

Лучше избегать режимов. Когда появятся привычки в пользовании интерфейсов, не нужно будет задумываться или планировать действие, поэтому внимание будет сосредоточено только на содержании работы.

Не всегда нужны лишние настройки

Большинство пользователей просто хотят выполнить свою работу. Их не волнует, какой шрифт принят по умолчанию и т.д.

Добавляя в программу настройки, мы обременяем пользователя новой задачей: скажем, помимо электронных таблиц, приходится изучать еще и опции по их настройке.

Время, которое тратится на изучение и выполнение пользовательских настроек, — потерянное с точки зрения текущей задачи.

Пользователь слепой

По отношению к тому, что находится вне нашего локуса внимания, мы все в самом прямом смысле слепые. Поэтому элементы интерфейса называют привычными, если ими может пользоваться «слепой» пользователь.

Нажимать кнопку или нажимать и удерживать?

Пользователь должен уделять время содержанию и работе с ним, а не управлению системой. Поэтому квазирежимы (когда нужно удерживать клавишу) должны использоваться для управленческих функций, тогда как для создания содержания должны применяться операции без задействования квазирежимов.

Правильный порядок действий: сначала выбирать объект, потом действие с ним

Модель «существительное-глагол»: сначала выбрать объект (выделить абзац), а потом указать действие (выбрать шрифт).

Модель «глагол- существительное»: сначала выбрать действие (изменить шрифт), потом — объект (абзац).

Подход «существительное-глагол» лучше. Преимущества:

• Уменьшение количества ошибок — команды выполняются сразу, пока еще находятся в локусе внимания пользователя.
• Скорость — не нужно переключать свое внимание с содержания (которое и вызвало необходимость выполнения операции) к самой команде и затем опять к содержанию, чтобы можно было выделить необходимый участок текста.
• Простота и обратимость — чтобы выбрать другой текст, не требуется нажимать кнопку отката или применять какой-либо другой способ отмены действия.

Применение методов «глагол-существительное» должно ограничиваться только выбором из палитр, если они предназначены для непосредственного использования.

Делать объекты состоятельными

Элементы управления считаются состоятельными (affordance), когда по внешнему виду элемента понятно, какая у него функция. Если будет ручка — пользователи будут ее крутить, если кнопка — нажимать.

То, какую состоятельность будет иметь элемент интерфейса, зависит от опыта и знаний пользователя, а также от контекста, в котором он этот элемент встречает. Каждый видимый элемент должен быть состоятельным.

Делать жесты монотонными

Монотонность — это вторая сторона отсутствия модальности. В интерфейсе, который не имеет режимов, данный жест пользователя может иметь один и только один результат: жест g всегда приводит к действию a.

Перед разработчиками интерфейсов стоит задача по поиску монотонного решения, чтобы обеспечить такие преимущества: легкость изучения, простоту внедрения, минимум документации и небольшой размер расходов на обслуживание. Суть монотонности — для вызова одной и той же команды не должно использоваться много жестов.

Дихотомия «новичок-эксперт» — миф

Фаза профессионального владения интерфейсом характеризуется бессознательным использованием его возможностей. Поэтому менять интерфейс на другой при достижении какого-то уровня — раздражать пользователя.

Простота и ясность функций и их видимость важны и для новичков, и для экспертов. Причем переход от одного статуса к другому не должен требовать переучивания.

Двойная «дискликсия»

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

Уменьшать задержки или делать их понятными

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

Если задержки неизбежны, в интерфейсе должна быть обратная связь, которая о них сообщает. Например, индикатор хода задачи (status bar), отражающий оставшееся время. Если неизвестно, сколько времени займет операция, так и скажите пользователю.

Хороший интерфейс выдает сообщение, что информацию от пользователя программа приняла и правильно распознала.

Унифицировать команды

Если сделать во всех приложениях одинаковые команды, можно устранить модальность.

Разработка интерфейсов должна быть основана на идее, что любые объекты, которые выглядят одинаково, одинаковы.

Каталог элементарных действий

Элементарные действия, выполняемые пользователем в различных комбинациях, порождают набор элементарных операций, которые применяются к содержанию и используются почти во всех интерфейсах. Перечислим, какие операции пользователи применяют к содержанию:

• Указание. Указывают на то или иное содержание.
• Выделение. Выделяют какое-то содержание.
• Активизация. С помощью «клика» активизируют содержание.
• Модификация или использование (с помощью команд):
• Генерация. Модификация из «пустого» в «непустое».
• Удаление. Модификация из «непустого» в «пустое».
• Перемещение. Вставка содержания в одно место и одновременное его удаление из другого.
• Трансформация. Преобразование в другой тип данных.
• Копирование. Содержание может быть отправлено или получено от внешнего устройства или скопировано в другую область внутри системы. Например, содержание распечатывают, отправляют по электронной почте, сохраняют на жестком диске, копируют в другой документ.

Подсветка (highlighting) означает, что с помощью каких-либо средств отображенному на экране объекту придается заметное отличие. Когда пользователь наводит курсор на какие-то объекты, они должны быть подсвечены.

Указание (indication) — это подсветка единичного объекта при перемещении курсора без каких-то других действий со стороны пользователя (например, без клика мыши). С помощью указания пользователь может в любой момент знать, на какие объекты он указывает с точки зрения системы.

Выделение (selecting) — это процесс, с помощью которого пользователь указывает, что один или несколько объектов имеют особый статус, который может быть воспринят системой. Как результат процесса получается выборка (selection).

Три недостатка выборок:

1. Команда для создания составных выборок невидимая.
2. Когда создаешь большую выборку, иногда случайно отпускаешь «Shift» и щелкаешь по следующему файлу, — вся выборка отменяется.
3. Механизм — «переключатель»: один и тот же жест отменяет и устанавливает выделение.

Решения:

1. Сделать экранную подсказку.
2. Установить специальную команду, с помощью которой текущая выборка определяется как объединение старого и текущего выделения. Благодаря такой команде пользователь сосредоточился на создании выборки, не заботясь о том, что было выбрано до этого.
3. Сделать разные команды для установки и удаления. Операторы Отменить и Повторить являются основополагающими, и их функция настолько важна, что в будущих системах для них должна быть предусмотрена специальная клавиша.

Когда процессом взаимодействия управляет человек, в фокусе обычно находится текущая выборка. Если же система отвечает на действие пользователя или внешней системы, в фокусе обычно находится результат действия.

Подстраивать команды под естественный язык

Синтаксис, который мы выбираем для написания команд, не должен исключать пробелы или символы новой строки. Любые ограничения, накладываемые на набор допустимых символов, используемых для набора команд, в будущем приведут к проблемам.

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

Не подвергать работу пользователя риску

Человекоориентированный интерфейс никогда не подвергает работу пользователя риску => ввод с клавиатуры не замещает выделенный текст и не отменяет выделение текущей выборки. Случайная потеря хотя бы одного символа может означать потерю части телефонного номера, которая не может быть восстановлена.

Удаление текста должно проходить явным образом по желанию пользователя и не быть побочным эффектом другого действия.

Побочный эффект — это следствие применения команды, при котором изменяется содержание или события, которые не находятся в локусе вашего внимания. В только что рассмотренном случае в локусе вашего внимания находится текст, который вставляется, а побочным эффектом является удаление. Устранение побочных эффектов должно быть одной из целей для разработчика человекоориентированпого интерфейса.

Раскин советует отказаться от функции перетаскивания. Меньшее число ошибок и проблем будет хорошей компенсацией для пользователей, которые привыкли перетаскивать текст.

Отказаться от имен файлов и иерархической структуры

Необходимость давать имена файлам увеличивает ментальную нагрузку на пользователя. Это одна из главных бедствий, которым страдают современные компьютерные системы. Между именем файла и самим файлом не должно быть различия.

Человеческий мозг способен более эффективным образом использовать быструю, полнотекстовую поисковую систему, поэтому любое слово или фраза из файла может служить ключом к нему. Содержание текстового файла — его самое лучшее имя.

Отказ от использования иерархической файловой структуры не означает отказ от структурирования сохраняемой информации. Ничто не мешает вам создавать оглавления и указатели — но тогда структура будет частью вашего содержания, а не интерфейса. Такая структура не будет устанавливаться разработчиками, у которых могут быть другие идеи, отличные от ваших.

Использовать каждый символ

Программа должна взаимодействовать с пользователем на основе наименьшей единицы ввода. Пишешь с клавиатуры — познаково, говоришь голосом — пословно и т.д.

Сделать универсальные команды

Команды, которые должны быть доступны для пользователя в любой момент:

• проверить орфографию в текущей выборке;
• использовать текущую выборку как арифметическое выражение и вычислить его;
• передать текущую выборку по электронной почте;
• передать текущую выборку по факсу;
• перейти по данному URL;
• выполнить текущую выборку как программу, написанную на языке Java или любом другом.

Не увлекаться пиктограммами

Пиктограммы делают интерфейс более привлекательным в визуальном отношении и, при определенных условиях, могут способствовать большей понятности. Но иногда, вместо того, чтобы объяснять, пиктограммы зачастую сами требуют объяснений. К тому же, смысл пиктограмм часто зависит от культуры.

Количество пиктограмм, которые видно одновременно, не должно превышать 12.

Пиктограммы должны:

• визуально отличаться друг от друга
• хорошо отражать соответствующее понятие
• иметь разумно большой размер (обычно больший, чем могла бы быть текстовая надпись).

Пиктограммы нарушают принцип видимости, потому что смысл пиктограмм остается невидимым. Используйте пиктограммы только тогда, когда исследования показывают, что они эффективнее. Не бойтесь использовать текст.

Исключить ошибки, а не предупреждать о них

Когда вы пытаетесь написать текст сообщения об ошибке, пожалуйста, остановитесь и переделайте интерфейс таким образом, чтобы условие, при котором это сообщение об ошибке вызывается, не возникало.

Если отказаться нельзя, то сделайте сообщение об ошибке на полупрозрачном фоне. Так, пользователь увидит его и продолжит работу на компьютере, глядя на экран сквозь выданное сообщение. Сообщение закроется само, когда пользователь выполнит действие (перемещение курсора действием не считается).

Если выдается сообщение, которое не требует ответа от пользователя, оно должно быть устранено.

Пусть потеет машина

Не предоставляйте пользователю тех средств управления, которые должны работать всегда или никогда.

Если пользователь в следующий момент времени может выполнить только одно действие, пусть его выполнит компьютер.

Критика — благо

Если покупатель тратит свое время на тщательный анализ вашего продукта и делает конструктивные предложения для его улучшения, относитесь к этому с вниманием. Это нельзя рассматривать как попытку сделать вам выговор или нанести оскорбление. Этим он демонстрирует лояльность и интерес к вашему продукту.

Упрощать аппаратное обеспечение

Кабели должны присоединяться и отсоединяться от компьютера независимо от того, включен он или нет. Если их нельзя заменить без выключения питания, они становятся модальными.
Кратко не значит понятно

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

Не следует путать простой внешний вид экрана с простотой использования интерфейса.

Принципы отображения информации по Э. Тафти

Визуальный дизайнер Эдвард Тафт (Edward Tufte, 1983, с. 105) разработал принципы отображения информации, среди которых первыми тремя являются следующие:

• данные следует показывать прежде всего остального;
• следует максимально увеличивать долю чернил, используемых для отображения данных;
• следует максимально уменьшать долю чернил, которые не используются для отображения данных.

Для того чтобы приложить эти принципы к устройствам с дисплеями, требуется всего лишь заменить в них слово чернила на слово пикселы. Серьезный, профессиональный пользователь желает, чтобы экраны были до отказа заполнены полезным содержанием. Экраны должны быть хорошо обозначены, снабжены простыми механизмами для осуществления поиска и получения информации, отражающей суть данного экрана. (В конце концов, раз уж мы сели за компьютер, мы должны извлечь из этого максимальную пользу.)

Законы интерфейса

Первый закон интерфейса

Компьютер не может причинить вред данным пользователя или своим бездействием допустить, чтобы данным был причинен вред.

Второй закон интерфейса

Компьютер не должен тратить впустую ваше время или вынуждать вас выполнять действия сверх необходимых.

Зачем создавать качественный интерфейс?

Тщательное проектирование и детальное определение технических и других требований не замедляют, а, наоборот, ускоряют процесс разработки. Создание качественного интерфейса полезно и с точки зрения долгосрочной перспективы, поскольку в результате приводит к:

• большей продуктивности работы пользователя;
• большему удобству для пользователя;
• большей ценности в глазах покупателя;
• уменьшению расходов на поддержку покупателей;
• ускорению и упрощению процесса внедрения;
• преимуществу перед конкурентами на рынке;
• лояльности к данной марке;
• упрощению инструкций и онлайновой помощи;
• более безопасным продуктам.

Идеальный интерфейс по мнению Раскина

Интерфейс с рабочим столом имеет довольно низкую эффективность, так как, находясь на его уровне, вы не можете выполнять свои задачи. В человекоориентированном интерфейсе, в котором нет ни рабочего стола, ни приложений, пользователь может в любой момент работать с необходимым ему содержимым.

Мы можем отказаться от использования файлов и файловых имен, оставив только одно пространство — пространство содержимого. В такой среде не нужно открывать или закрывать документы — вы просто уменьшаете масштаб системы до их размера и начинаете работать. Вам не нужно открывать приложения — вы просто копируете чистый документ. Игру не нужно запускать, вы просто масштабируетесь до нее.

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

Книга «Дизайн привычных вещей» впервые вышла в в 1988 году. В ней Дональд Норман — основатель компании Nielsen Norman Group и бывший вице-президент Apple — рассказал о том, как дизайн влияет на жизнь человека. Он привел простые примеры из жизни и описал, как плохой дизайн приводит к роковым ошибкам — авиакатастрофам и авариям на производстве. И дал советы, которые помогут все исправить.

Ниже будут цитаты из книги и мысли, которые я для себя отметила.

***

Фундаментальные принципы дизайна вещей

Наглядность функций

С первого взгляда на устройство можно определить его состояние и возможные будущие действия.

• все детали видны;
• назначение кнопок очевидно;
• действие соответствует результату;

Ясная концептуальная модель

Можно предсказать результат действий с вещью. Модель непротиворечива и понятна пользователю.

Три аспекта ментальных моделей. Пользователь получает все знания об устройстве только через образ системы, поэтому в идеале модель проектируемой системы совпадает с моделью пользователя

Хорошее соответствие

Можно определить взаимосвязь между действиями и результатом, кнопками и их функциями, действительным состоянием устройства и отражением этого состояния.

Элементы управления должны либо находиться на самом объекте, либо быть как-то связанными с ним. Их движение должно по аналогии повторять ожидаемое движение объекта.

Обратная связь

Пользователь получает полную и точную информацию о результате проделанных действий.

***

Процесс выполнения любого действия состоит из четырех этапов:
цель → действие (выполнение — оценка) → изменения в мире → проверка результата

Этапы действия

Этапы действия дают базовые требования к дизайну, чтобы избежать разрывов выполнения и оценки.

Технологический парадокс

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

Но это не оправдывает плохой дизайн.

Задача должна быть простой

Дизайнер должен принимать во внимание психологию человека и возможности его памяти:

• кратковременная память — рабочая, отражает настоящее. Предел — 5—7 единиц.
• долговременная память — для прошлого. Требует времени и усилий для запоминания. Это не запись событий, а их интерпретация.

Информация легко извлекается, если материал осмыслен и близок к тому, что уже известно.

Типы запоминания:

• механическое — информация случайная и не связана с другими фактами (алфавит).
• основанное на осмысленных связях — создает связи с известной информацией.
• основанное на объяснении — не нужно запоминать, можно просто понять.

Хорошее устройство уменьшает умственную нагрузку.

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

Как новичок разбирается с предметом

Столкнувшись с новым предметом, как узнать, что с ним делать?

• использовать прошлый опыт, т. е. внутренние знания о назначении предметов.
• использовать внешнюю информацию. Если дизайн дает нам подсказки, можно правильно интерпретировать подсказки.

Назначение предлагает возможности. Ограничители сужают выбор вариантов.

Человек старается объяснить себе все, что видит, основываясь на своем опыте, который может быть неприменим в этой ситуации. Задача дизайнера — сделать так, чтобы эти объяснения были верны.

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

В любой ситуации поведение пользователя определяется сочетанием внутренних знаний с внешней информацией и ограничителями внешнего мира.

Мы ошибаемся постоянно

Ошибки — неотъемлемая часть повседневной жизни. Хороший дизайн может свести к минимуму их количество и уменьшить последствия.

Есть два вида ошибок: заблуждения и оплошности.

Заблуждения

Результат сознательных размышлений. Обычно их причина — неправильный выбор целей.

Оплошности

Результат автоматических действий, которыми руководит подсознание. Обусловлены недостатком внимания.

• Заместительные ошибки — когда начинаешь делать одно, а в итоге делаешь что-то другое. У действий, похожих на начальном этапе.
• Описательные ошибки — обычно при неправильном выборе объекта действия, когда предметы рядом и похожи.
• Информационные ошибки — когда влияет информация извне.
• Ассоциативные ошибки — когда думал об одном, а сделал другое, влияют размышления и ассоциации.
• Ошибки памяти — когда забыл, что делал или куда шел.
  Модальные ошибки — когда нет видимых признаков, в каком режиме работает устройство.

Если нет обратной связи, оплошность выявить трудно.

Любое действие можно рассматривать на разных уровнях. Ошибка может быть на любом. Обычно мы начинаем исправлять ошибку с самого низкого уровня, постепенно поднимаясь вверх.

Все люди ошибаются

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

1. Понять причины ошибок и постараться свести их к минимуму.
2. Сделать возможной отмену предыдущего действия или уменьшить вероятность необратимого действия.
3. Облегчить обнаружение и исправление ошибок.
4. Изменить отношение к ошибкам.

Делайте так, чтобы ошибки всегда можно было заметить и исправить.

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

Можно использовать вынуждающие функции — форму физического ограничителя: ошибка на одном этапе действия делает невозможным следующий этап.

Они бывают:

• взаимоблокировка — вынуждает действовать в определенном порядке;
• фиксация — нельзя преждевременно остановить действие;
• блокировка — не дает зайти в опасную зону и предотвращает некоторые события.

Если все остальное терпит неудачу, устанавливайте стандарты

Стандартизируйте действия, результаты, расположение, изображения. делайте так, чтобы родственные действия приводили к одинаковым последствиям. Благодаря этому учить правила придется только один раз.

Стандартизация — вид культурных ограничителей. Для внедрения нужно прийти к общему мнению.

Дизайн должен быть рассчитан на потребителя

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

Дизайнеры — не обычные пользователи

Дизайнеры очень хорошо знают устройство, над которым работают. Пользователи же отлично знают задачу, которую им нужно выполнить с помощью устройства.

Дизайнер становится знатоком продукции, поэтому ее эксплуатация не может у него вызывать сложностей. Все знания у него в голове. Пользователю-новичку приходится полагаться на внешнюю информацию.

Не существует «среднего» человека

Любое решение обязательно будет кого-то не устраивать. Делайте гибкий дизайн: он хотя бы даст таким пользователям шанс.

Внимание избирательно

При появлении проблемы все внимание человека приковано к ней, а остальное вылетает из головы. Дизайнер должен учесть это и сделать упускаемые из виду факторы наглядными или менее необходимыми. Здесь и нужны вынуждающие функции.

Почему дизайнеры сбиваются с пути

Если бы дизайнеры руководствовались принципами эстетичности, жизнь бы стала красивой, но никак не удобной; если бы практичности — она стала бы удобной, но вряд ли красивой. Если за основу берется низкая стоимость и трудоемкость производства, конечный продукт вряд ли будет практичным, привлекательным и долговечным. Естественно, при разработке дизайна все эти аспекты должны быть учтены. Проблемы появляются тогда, когда один из них начинает доминировать.

Соблазны дизайнера

Ползучий функционализм

Стремление (часто беспричинное) расширить количество функций. Программа тогда перестает оставаться практичной и понятной.

Решения:

• оставить только необходимые функции;
• разделить наборы связанных функций (модуляция).

Поклонение ложным ценностям

Стремление к сложности

Компьютерные программы

Самые лучшие программы — те, которые отвлекают внимание пользователя от компьютера и всецело направляют его на решение проблемы.

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

При хорошем дизайне пользователь не замечает компьютер, потому что внимание нацелено на выполнение задачи.

Главная идея книги: используя любое устройство, пользователь должен знать а) что делать, б) что происходит с системой в данный момент.