Многоязычное проектирование UI


16.03.2021 Время чтения - 9 минут 537

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


Читайте нас в Telegram


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

Независимо от разработки продукта дизайн – это решение проблем. Псевдо-локализация в Netflix – это отличное чтиво о том, как Netflix подошел к разработке своего UI для нескольких языков.

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

Учимся на ошибках.

*студент, помощник механика по обслуживанию реактивного газотурбинного самолетного двигателя в звании сержанта

Сломанный UI – отправная точка

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

Из-за сломанного UI нам пришлось переосмыслить подход к макету, элементам и тексту в дизайне, чтобы оставить его согласованным для всех языков. Изменение размера шрифта только для того, чтобы приспособиться к новому языку, на самом деле не очень хороший подход. У нас не хватало времени и ресурсов, которые не допускали больших изменений в дизайне – эффект домино: когда вы изменяете одно, это влияет на другое. Этот инцидент привел в действие более масштабный план переоценки информационной архитектуры для будущих итераций.

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

Что важнее? Что приоритетнее? Почему?

Иерархия – определение приоритетов

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

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

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

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

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

Язык так же важен, как и визуальный стиль.

Определение иерархии может помочь внести ясность в дизайн

Деклаттеринг – важность контекста

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

Все это может сработать, но действительно ли кнопке “добавить в корзину” нужна иконка?

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

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

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

Контекст и ясность играют весомую роль.

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

Многие люди не знакомы со значком низкого давления в шинах на автомобилях (TPMS — Tire Pressure Management System). Эти значки обычно универсальны и используются всеми брендами во всех странах. Несмотря на то, что многие пользователи (водители) на 100% не уверены в значении значка, механик должен быть в состоянии понять проблему, взглянув на значок.

Значок низкого давления в шинах TPMS

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

Язык – различия в значении

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

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

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

  • Kuusi palaa = Шесть штук
  • Kuusi palaa = Шесть возвращений
  • Kuusi palaa = Ель в огне
  • Kuusi palaa = Ель возвращается
  • Kuusi palaa = Твоя луна возвращается

и т. д.

Что из этого?

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

Можно посмотреть, какие слова используют крупные игроки. Обычно им приходилось много работать, чтобы найти идеальный вариант. Это не означает «копирование как есть», а в терминах общего языка UI. Если вы решите вдруг скопировать «zazaam thou in my bin» слово в слово, то лучше не делайте этого – слишком персонализировано. «Add to Cart» до сих пор довольно универсально.

“Add to Cart” согласно быстрому переводу от Google на немецком звучало как “in den Warenkorb legen”, что было проверено носителями. Я провел быстрое исследование нескольких немецких ритейлеров, чтобы узнать, что они используют:

  • Zara Germany: “Hinzufügen”
  • Tommy Hilfiger Germany: “Artikel Hinzufügen”
  • Amazon Germany: “In den Einkaufswagen”
  • Ikea Germany: “In den Warenkorb”

Выбор Ikea был наиболее близок к переводу Google Translate. А какой из них использовали бы вы? На это решение обязательно повлияет отрасль, в которой в работаете.

Add to Cart», «Add to Basket», «Add» – Что использовать?

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

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

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

Язык-очень важная часть любого UI.

18 стон – это примерно 114 кг или 252 фунта

Спецификации – гибкость макета

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

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

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

Изменения, основанные на иерархии, контексте, деклаттеринге, языке и спецификациях, помогли решить многие проблемы, вызванные неправильным UI, но это не означало, что он был готов – работа продолжается.

Сталкивались ли вы с проблемами при проектировании для разных языков?

Оригинал.

Читайте также: Основные тенденции графического дизайна в 2021 году


Читайте нас в Telegram