Привет, меня зовут Оля Сартакова. Я работаю в Redmadrobot и преподаю дизайн мобильных приложений в Британке. Хочу рассказать, как работаю с текстами в интерфейсах.
Самый однозначный носитель смысла среди инструментов дизайнера — это текст. Есть ещё иконки и иллюстрации, но они, как иероглифическое письмо: ёмкие, компактные и не очень понятные. Их можно сравнить с жестами в устной речи. С их помощью можно передать эмоции, подбодрить или послать собеседника. Но, например, объяснить, что активировать банковскую карту сейчас не получится из-за сбоя на сервере, будет нелегко.
В начале работы над проектом никто лучше дизайнеров не разбирается в том, как мы запланировали реализовать пересечение задач бизнеса и потребностей пользователя. Поэтому никто лучше нас не опишет это словами.
1. Понять, кто и в какой ситуации будет пользоваться приложением
В большинстве случаев нам везёт с аудиторией: это люди, давно и хорошо знакомые с интерфейсами, поэтому им не нужно объяснять, что делать с полями ввода и чекбоксами. Но, например, пожилым людям потребуются дополнительные подсказки. А дошкольникам тексты лучше озвучивать и сопровождать иллюстрациями.
Важно учесть контекст использования. Приложения для водителей должны не отвлекать от дороги и быть предельно понятны даже утомленному пробками и детскими криками отцу семейства по пути на дачу вечером в пятницу.
На этом этапе мы определяемся со стилем коммуникации и тем, насколько подробные тексты понадобятся. Поговорите с потенциальными пользователями, всегда можно предположить, кто и как будет пользоваться приложением, но откуда вам знать, что в голове у этих людей?
После анализа результатов интервью можно придумать самого сложного персонажа в самой непростой ситуации и проектировать приложение для него.
Давайте разберём пример: проработаем сценарий оформления заказа для приложения доставки пиццы. Наш пользователь — 28-летний Василий. Характер прескверный, не женат. Он живёт во Фрязино, работает в Москве. Сегодня вечер пятницы. Василий после работы выпил немало пива с коллегами. Сейчас он возвращается домой на электричке, в которой не всегда хорошо ловит интернет, и хочет есть.
2. Выписать всё, что может пригодиться
Для этого нужно побеседовать с клиентом, побеседовать с пользователями, проанализировать конкурентов, пофантазировать самому.
С пиццей у меня получилось так.
Василий хочет, чтобы пицца приехала к нему домой именно тогда, когда он сам туда доберется. Он хочет, чтобы она была горячая, и чтобы ему положили побольше салфеток. Платить Василию удобнее всего через Apple Pay, потому что набирать номер карты лень.
Бизнес (пиццерия) заинтересован в том, чтобы Василий сделал заказ как можно быстрее и оплатил заранее.
Чтобы Василий сделал заказ быстрее, можно спросить у него только номер телефона, а детали потом уточнит оператор колл-центра. Но если Василий делает заказ в первый раз, а приложение не просит адрес, платить заранее он вряд ли захочет. Поэтому ввод адреса оставим, но сделаем его необязательным.
Если не спросить у Василия время доставки, курьер может привезти пиццу не вовремя и ему придётся ждать под дверью. Про время надо спросить.
Василий хочет оплатить пиццу через Apple Pay, но не все с ними солидарны. Во-первых, не у всех смартфоны поддерживают Apple / Google / Samsung Pay, а во-вторых, при первом заказе люди опасаются предоплат — вдруг вообще не привезут. Получается, что в приложении нужны, как минимум, четыре способа оплаты: Apple / Google / Samsung Pay, картой в приложении, картой курьеру и наличными.
Чтобы ускорить оформление заказа, можно поле со способом оплаты предзаполнить. Для постоянных пользователей все просто — можно сохранить последний выбранный способ. Если же мы о Василии ничего не знаем, предположение можно построить на данных о посетителях пиццерии.
Ресторану нужно будет связаться с клиентом, а чтобы быть вежливыми — спросить, как его зовут. Это лучше сделать в самом начале: во-первых, знакомиться лучше перед тем, как говорить про деньги, а во-вторых, по телефону можно узнать пользователя, восстановить историю его взаимоотношений с пиццерией и предзаполнить часть полей формы.
Но прежде чем раскрывать пользователю информацию об истории заказов, нужно убедиться, что этот номер принадлежит ему. Самый простой способ — отправить SMS c кодом подтверждения. Но даже если номер действительно его, нельзя показывать информацию о заказах старше полугода — за это время у номера мог смениться хозяин.
Итого, в форме оформления заказа нужны следующие поля:
- Имя и телефон клиента.
- Способ получения заказа: доставка или самовывоз (мы разберем только доставку, потому что Василию нужна именно она).
- Время доставки: чем скорее, тем лучше, или к указанному времени.
- Адрес доставки.
- Способ оплаты.
Так форма будет смотреться на экране. Для начала поделю оформление заказа на 2 шага. На первом проверю, знаком ли нам пользователь, на втором узнаю, как он хочет получить и оплатить заказ.
3. Убираем то, без чего можно обойтись
Лучше не перегружать экран и подбирать максимально лаконичные формулировки. Главное при сокращении — не потерять смысл.
В черновике меня смущают повторы «доставки», «при получении» и формулировка «Способ оплаты» (хоть это и не критично, но выглядит слишком формально). Переформулируем все три подзаголовка в одном стиле, уберем «при получении» из оплаты наличными — всё равно иначе деньги передать невозможно:
Теперь меня смущает только «Укажите адрес». Можно заменить его на подсказку о том, что именно придётся указать:
Я вынесла указание адреса доставки на отдельный экран, чтобы не перегружать текущий.
Чтобы курьер доставил пиццу, нужно узнать название города, улицы, номер дома и, если есть, квартиры или офиса. Найти подъезд и этаж курьер сможет и самостоятельно. Но на поиск и вычисление потребуется время, оно же — деньги.
Чтобы избежать ошибок при указании адреса, можно использовать справочник адресов Яндекса или Google. В этом случае можно вводить город, улицу и дом в одно поле — справочник не даст ошибиться с форматом данных, а подсказки ускорят ввод. Один минус — чем популярнее будет приложение, тем дороже обойдется использование справочника.
Форма получилась большая, но убрать из неё нечего. Что делать?
Один приём мы уже использовали — поделили её на 2 шага. Второй способ сработает при повторном заказе — можно запоминать введённые данные и показывать поля предзаполненными.
4. Заботимся и объясняем
Основной сценарий продуман, теперь нужно подумать о том, что может пойти не так? Лучшая отработка негативных сценариев — невозможность допустить ошибку. Например, если доставка ограничена по времени, не давайте пользователю выбрать дату и время, когда курьер не работает.
Превышен лимит неактивности → Просто верните человека на предыдущий шаг.
Неверный формат данных → Показывайте сразу правильную клавиатуру.
Если предотвратить ошибку невозможно, формулируйте оповещения на понятном человеку языке и объясняйте, что произошло, в чем причина и что сделать. Как правило заботливое сообщение об ошибке занимает больше места, чем «роботизированное», но люди не будут на нас в обиде.
Сервер не отвечает →
- Если сервер недоступен из-за того, что у пользователя пропало соединение с интернетом, так и говорим → Нет соединения с интернетом. Проверьте настройки сети.
- Если сервер недоступен по собственным мотивам, единственный вариант, продумать автоматическое решение проблемы и подсказать, как можно решить её прямо сейчас. → Нет связи с сервером. Не закрывайте приложение, и ваш заказ отправится автоматически, как только мы устраним неполадку. Или позвоните нам по телефону +7 (495) 999-99-99 — и мы оформим заказ.
Неверный номер телефона →
- Если не хватает цифры → Не хватает цифры
- Иногда пользователь сознательно «допускает ошибку». Например, не указывает номер телефона или пишет случайный набор цифр, потому что не хочет, чтобы ему лишний раз звонили. Постарайтесь найти в этом пользу для человека и расскажите о ней. → По такому номеру курьер не дозвонится, если не сможет вас найти.
5. Перечитываем
Когда экран готов, перечитываем текст с начала до конца. Хороший интерфейс будет звучать как диалог между заботливым оператором и пользователем. Если «диалог» не складывается — возвращаемся к предыдущим шагам.
6. Тестируем на людях
Когда мы довольны результатом, пора проверить интерфейс на целевой аудитории. Лучше всего собрать прототип с нажимаемыми кнопочками в InVision, Marvel или Flinto и дать нескольким людям из целевой аудитории задание пройти целевой сценарий — заказать пиццу с доставкой на дом в 20:00. На что нужно обратить внимание:
- Легко ли пользователям? Всё ли им понятно?
- Где у них возникают проблемы? Почему?
- Нравится ли им тон общения, который вы выбрали?
Что нельзя делать:
- подсказывать, куда нажать;
- выражать свои эмоции, когда у человека что-то не получается;
- задавать вопросы, пока он не закончил.
Дайте задачу, потом внимательно наблюдайте, как человек с ней справляется, а в конце задайте вопросы.
Если несколько человек спотыкаются на одних и тех же моментах или большинство раздражает стиль коммуникации, возвращаемся на первый шаг и ищем ошибку.
7. Определяем правила
Когда вы определились с тем, что сказать,нужно понять, как говорить с пользователем. Уместны ли шутки, нужны ли подсказки, как обращаться к Василию и как объяснить ему, почему пиццерия вдруг перестала принимать заказы на время футбольного матча.
Каким должен быть тон подсказок в интерфейсе, о чем стоит договориться на берегу и зачем приложению редакционная политика — отдельная история. Поэтому продолжение следует.