структура экрана
- структура большинства экранов и сообщений — заголовок, боди и кнопка
- элементы экранов и сообщений должны быть понятны сами по себе. если человек увидел экран, вышел и снова вернулся спустя время, ему не нужен предыдущий экран, чтобы понять, что происходит
- идеальный экран работает только по заголовку и кнопке, даже без боди.
- все элементы пишем просто, без метафор, причастий и деепричастий, не используем модальные глаголы
интерфейс — это всегда диалог между продуктом-заголовком и человеком-кнопкой. заголовок и кнопка связаны между собой: кнопки содержат только действия на экране, а экран описывает все действия из кнопок
заголовок
- заголовок — суть экрана. он должен содержать самое главное — статус происходящего пользователь должен с одного взгляда на заголовок понимать, о чём идёт речь, без подглядывания в подзаголовок
- заголовок объясняет, в чём проблема, или предлагает решение. выбирая, что важнее сейчас показать — действие или статус, отталкивайтесь от конкретной задачи и флоу
меньше текста — больше смысла, пишем ёмко и понятно, до 2 строк
глагол пишем в повелительном наклонении «сделайте что-то» — если без этого действия процесс не продолжить
задаём вопрос «сделать что-то?» только в антимиссклике — когда надо убедиться, что человек уверен в своём решении
не пишем междометия и эмоциональные фразочки типа «упс», переходим сразу к делу, не интригуем неизвестностью — бережём время и внимание человека
используем переменные, если уверены, что сможем их корректно подтянуть с бэка. номер в заголовке пишем, если хотим, чтобы пользователь его перепроверил
боди
это подзаголовок. главное в боди то, что его не читают))
боди помогает понять ситуацию, но его редко читают до конца
боди помогает понять ситуацию, но его редко читают до конца
чем короче, тем лучше — но не забываем о смысле
текст должен перекликаться с кнопками и описывать каждую из них
стремимся к одному абзацу, длинные предложения делим на короткие
сущности
- сущности — это элементы, на которые можно разложить дизайн продукта. например, если мы проектируем раздел поддержки, то сразу можем представить, что там обязательно должно быть, какие герои и сущности там обитают — заявка в поддержку, поиск по заявкам, поле ввода, лейблы и так далее
- чем меньше сущностей, тем легче пользователю читать и понимать
- у сущности один смысл, одно обоснование и одно поведение всегда и везде на пользовательском пути
- у дизайнера сущности выглядят одинаково, у редактора — называются
поиск, ввод и выбор: лейбл, плейсхолдер, подсказки
это помощники пользователя, когда нужно выбрать один вариант из нескольких, ввести какие-то данные или написать комментарий. они не дублируют дизайн, а сразу прямо говорят человеку, что ему нужно сделать. люди не любят лишний раз думать и принимать решение
есть несколько смыслов, которые можно показать в поисковом плейсхолдере
- объяснить, что здесь можно что-то ввести, например: «найти»
- объяснить, где именно будет проходить поиск, например, «поиск по услугам»
- объяснить, что можно искать, например «название или ИНН»
- показать реальный запрос, например, для роуминга «летим в Китай»
- показать предиктивный поиск, например, «начните вводить название песни»
кнопки
кнопка — самый важный элемент вовлечения человека в диалог с продуктом
- называем кнопку ёмко и понятно, в идеале — до 15 символов, но можно и больше. главное, чтобы текст не уходил в сокращение с многоточием
- в кнопке говорим только о сущностях с экрана
- чаще всего в кнопке пишем глагол — тогда текст должен стать продолжением фразы пользователя «я хочу...»
- в основной кнопке primary честно пишем целевое действие, даже если оно не нравится бизнесу
в дополнительной кнопке secondary пишем второй вариант действий или откат назад
подключаем услугу, меняем тариф, тратим деньги — пишем кнопку с ценой. если у услуги есть бесплатный триал, а затем включается цена, то в боди обязательно пишем подробные условия, а в кнопке — «попробовать за 0 ₽»
знаем, куда поведём — делаем навигацию, нет — пишем «закрыть». для отказов «пока не буду» или «ещё подумаю»
если у действия пользователя есть фатальные последствия — используем кнопку «всё равно что-то сделать»
если впереди 1 шаг — делаем навигацию к действию, впереди 2 шага — называем кнопку «продолжить», впереди много шагов — называем кнопку «дальше»
пустые состояния
- пустые состояния — это когда на экране точно ничего нет. но может
что делать, чтобы здесь что-то появилось: здесь пока пусто, но ты можешь что-то сделать
- не нужно путать человека и рекламировать другие фишки. конкретно рассказываем, что нужно сделать именно для того, чтобы то действие, которое привело к пустому состоянию, в следующий раз привело к непустому
- обязательно должна быть кнопка действия
- в лоб не шутим, но можем написать что-то милое
модалки «вы точно уверены, что уверены?»
- экраны подтверждений используются против миссклика при подключении услуг, при изменении тарифа и других действий, имеющих платные или бесплатные последствия для человека
- в заголовке используем вопросительный знак, в кнопках вариант из кнопки подтверждения и кнопки со смыслом отмены «пока не буду». заголовок не просит подтвердить действие, а задаёт конкретный вопрос «подключить услугу?», «изменить тариф?»
- в заголовке нет фраз типа «вы уверены, что хотите». сразу к делу. не «вы уверены, что хотите подключить услугу?», а «подключить услугу?»
- в заголовке не должно быть отрицания. не «не применять изменения?», а «оставить всё как было?»
- если услуга платная, при кнопке подтверждения должна быть указана цена
- если экран отключения — пытаемся понять, что привело к желанию отключить. можно предложить альтернативную услугу, рассказать как сделать её дешевле и тд
ошибки
- ошибка — это когда человек не получил то, что ждал. не больше и не меньше
- текст ошибки обязательно должен рассказать, что случилось и что нужно сделать человеку. кнопки на этих экранах обязательно ведут на то действие, которое нужно для исправления (кроме ошибок бэка или тех ошибок, когда мы никак не можем повлиять на ошибку — человек заблокирован, у него пропал интернет и тд)
- такие экраны пишутся с глаголами — сделайте то-то и тд.
- если ошибка технического характера, технотрёпом людям голову не морочим, объясняем как можем и на человеческом языке.
- ошибки при заполнении анкет пишутся красным цветом и преимущественно глагольно. и конкретно. например, если человек не заполнил поле, не надо ему писать ошибку «заполните поле». если возможно, поясняем, зачем нужно это поле. эти ошибки пишутся в 1-2 строки. не превращаем ошибку в ребус. если человек ошибся в дате, так ему и говорим — этот диапазон не подойдёт, выбери вот из этих дат
- заголовок ошибки — сама проблема. описание — что нужно сделать. кнопка — действие для решения ситуации
- стараемся писать позитивно. не «тариф недоступен корпоративным клиентам», а «этот тариф доступен только физическим лицам»
- не используем технический жаргон