Статьи

Плохая грамматика делает плохой UX?

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

20140131-064821.jpg

Нет, не такая плохая грамматика.

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

выберите файл

Но для меня «Выбрать файл» звучит неестественно. Почему? Наверное, потому что это не грамматично.

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

Так почему не в ваших красиво обработанных интерфейсах?

Давайте вернемся к примеру выше. Будьте предупреждены: я собираюсь объяснить аспект грамматики в следующем параграфе. Сохранять спокойствие.

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

Робот UX

«Выбери файл, маленького человека»

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

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

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

Большой! Легко! Ну не всегда …

Нахождение баланса

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

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

saveandprint

Но текст придает больше значения опции «сохранить как pdf» — почему это не просто «сохранить», чтобы соответствовать метке из одного слова другого выбора?

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

Как насчет старой доброй грамматики? Такие конструкции, как «сохранить в формате PDF» и «сохранить в формате PDF», являются неграмотными — мы никогда не будем писать их в прозе. Мы можем сказать «Сохранить это в формате PDF» или «Сохранить в формате PDF». Но вы можете видеть, как, как только вы начнете идти по этому пути, вы можете быстро добавить ненужный раздув в текст интерфейса.

Вместо этого я бы пошел на другой конец спектра и сделал ярлык: сохранить (pdf).

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

Посмотрите, кто говорит

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

Итак, давайте посмотрим на розничный пример: книжный депозитарий.

bookdepository

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

  1. Войти / реестр

    Войти или зарегистрироваться ИЛИ Войти | регистр

  2. Поиск книг по ключевому слову / названию книги / автору / ISBN

    Поиск по названию книги, ключевому слову, автору или ISBN

  3. Найти книгу

    Поиск книг ИЛИ Поиск книг

  4. Выбор валюты

    Выберите валюту

  5. Перейти в корзину / оформить заказ

    Посмотреть вашу корзину ИЛИ Оформить заказ

Если вы действительно собираете всю свинью, вы можете также рассмотреть возможность «Отслеживать заказ», «Отслеживать заказ» или «Отслеживать ваш заказ».

Одной из основных проблем с надписями в этом заголовке является использование косой черты. Ярлык с надписью «Войти / Зарегистрироваться» не собирается появляться у сканирующего пользователя, который ищет типичный призыв к действию. Точно так же «Перейти к корзине / оформить заказ» просто сбивает с толку. Что это: корзина или касса? Почему бы просто не назвать это так?

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

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

Более четкие интерфейсы, более четкое общение

Это правда: иногда грамматика занудный, но умный друг дизайнера интерфейса!

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